On Sat, Dec 01, 2007 at 11:34:47PM +0100, Rask Ingemann Lambertsen wrote:
> Index: configure.ac
> ===
> --- configure.ac (revision 130442)
> +++ configure.ac (working copy)
> AC_SUBST(CONFIGURE_GDB_TK)
> AC_SUBST(GDB_TK)
>
On Mon, Dec 03, 2007 at 04:07:35PM +, Richard Sandiford wrote:
> And I haven't yet looked at why the tests are failing. I was just noting
> that they did. It looks from PR21185 that Rask was seeing the same thing
> on mipsisa64-elf, and TBH, I was so unsurprised that they were failing that
>
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Anyway, given that there have been objections to the patch generally,
>> I realise that the pre-approval is void.
>
> I think there's no controversy over the libstdc++ change, so let's put
> that in. If nothing else, it makes
Rask Ingemann Lambertsen wrote:
>So, here is the patch to implement the config.cache file trick: Create a
> config.cache file with all the right link test answers for newlib just
> before running configure, in both Makefile.tpl and config-ml.in. This allows
> sparc-unknown-elf to build libstdc
Richard Sandiford wrote:
> Anyway, given that there have been objections to the patch generally,
> I realise that the pre-approval is void.
I think there's no controversy over the libstdc++ change, so let's put
that in. If nothing else, it makes the libstdc++ configury more
self-consistent; if w
On Sat, Dec 01, 2007 at 02:37:38PM +0100, Andreas Schwab wrote:
>
> Only variables subject to AC_SUBST are available in the generated
> Makefile. There is extra_host_args which includes --with-newlib, but
> this is only passed to configure scripts in host directories (via
> host_configargs), not
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote:
>>
>>I'll post a patch to implement the --cache-file trick just as soon as I
>> figure out why the $with_newlib variable is lost sometime before configuring
>> libg
On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote:
>
>I'll post a patch to implement the --cache-file trick just as soon as I
> figure out why the $with_newlib variable is lost sometime before configuring
> libgfortran, because it seems to basicly work apart from that. T
On Sat, Dec 01, 2007 at 09:48:20AM +, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> >
> >That's the --cache-file option, except for clobbering the file. I'll see
> > if I can arrange for the toplevel Makefile to copy a pre-made config.cache
> > into targe
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> 2006-04-18 DJ Delorie <[EMAIL PROTECTED]>
>>
>> * configure.in (m32c): Build libstdc++-v3. Pass flags to
>> reference libgloss so that libssp can be built in a combined
>> tree.
>> * configure: Regenerat
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> On Fri, Nov 30, 2007 at 10:25:34AM -0800, Mark Mitchell wrote:
>> Rask Ingemann Lambertsen wrote:
>>
>> >>>I have a feeling it would be more robust to simulate the link tests
>> >>> inside the autoconf/libtool macros themselves as opposed
On Fri, Nov 30, 2007 at 03:21:32AM +0100, Rask Ingemann Lambertsen wrote:
> On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
>
> > Even though current mainline can build libgfortran, all tests fail for
> > simulator testing, and I'm not sure whether you could get it work for
> >
On Fri, Nov 30, 2007 at 10:25:34AM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >>>I have a feeling it would be more robust to simulate the link tests
> >>> inside the autoconf/libtool macros themselves as opposed to explicitly
> >>> avoiding them in each and every configu
On Thu, Nov 29, 2007 at 08:16:22PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >> Perhaps we should turn target-libgfortran off by default for mips*-elf*.
> >
> >No. There is a point in excercising the compiler: Testing. In most cases,
> > you don't find problems with th
> I would prefer to revert DJ's change, for the same reason as the
> other changes under discussion, so that we're consistent across
> architectures.
I don't care as long as a combined tree still builds.
Richard Sandiford wrote:
> 2006-04-18 DJ Delorie <[EMAIL PROTECTED]>
>
> * configure.in (m32c): Build libstdc++-v3. Pass flags to
> reference libgloss so that libssp can be built in a combined
> tree.
> * configure: Regenerate.
> Mark, DJ? Do you agree it's OK to drop
Rask Ingemann Lambertsen wrote:
>> The issue isn't just Newlib; it's the "BSP" (crt0, system-call
>> implementations, etc.) that you might have in your individual system.
>> Some BSPs add considerable functionality beyond that provided by Newlib
>> itself, and we don't want libstdc++ to detect and
On Wed, Nov 28, 2007 at 03:21:08PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >Here's a detail I'm missing. If you configure --with-newlib (or get it
> > implicitly) and then link with something else when using the toolchain, then
> > the answers will be wrong, but I don
On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
> libstdc++-v3/
> 2007-xx-xx Mark Mitchell <[EMAIL PROTECTED]>
>
> * configure.ac: Don't check AC_LIBTOOL_DLOPEN if using newlib.
> * configure: Regenerate.
>
> Index: libstdc++-v3/configure.ac
>
On Fri, Nov 30, 2007 at 08:44:59AM +, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
> >> It sounds like we've agreed that, if we want
> >> to support libgfortran on targets like mips*-elf*,
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
>> Even though current mainline can build libgfortran, all tests fail for
>> simulator testing, and I'm not sure whether you could get it work for
>> bare-metal boards or not.
Rask Ingemann Lambertsen wrote:
>> Perhaps we should turn target-libgfortran off by default for mips*-elf*.
>
>No. There is a point in excercising the compiler: Testing. In most cases,
> you don't find problems with the compiler until you try to compile something.
When building the compiler
On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
> Even though current mainline can build libgfortran, all tests fail for
> simulator testing, and I'm not sure whether you could get it work for
> bare-metal boards or not.
It works on arm-unknown-elf, v850-unknown-elf and frv
> I would like to give the libstdc++ maintainers a chance to comment on
> the libstdc++ patch above and Rask and other maintainers a chance to
> comment on the libgloss reversion. I'll pre-approve the patch if no
> objections in 48 hours.
This looks fine to me.
-benjamin
Richard Sandiford wrote:
[I've added the libstdc++ list to this mail. If the libstdc++
maintainers need more context, I'll be happy to provide pointers, as I'm
sure will others CC'd above.]
>> if test "x${with_newlib}" != "xyes"; then
>> AC_LIBTOOL_DLOPEN
>> fi
> Reverting the libgloss
Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think there's a solution. In particular, on
> libstdc++-v3/configure.ac, we do:
>
> AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
>
> The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
> libtool. The libtool documentation says:
>
>
Rask Ingemann Lambertsen wrote:
>Here's a detail I'm missing. If you configure --with-newlib (or get it
> implicitly) and then link with something else when using the toolchain, then
> the answers will be wrong, but I don't see how that's any worse than
> assuming a set of hard coded link test
On Wed, Nov 28, 2007 at 08:15:56AM -0800, Mark Mitchell wrote:
>
> If I'm understanding correctly:
>
> * You, Benjamin, and I think the previous behavior was best.
>
> * Bernd is flexible, as long as it works.
>
> * Rask prefers the new behavior because he thinks it will be more robust.
>
> Ras
Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think there's a solution. In particular, on
> libstdc++-v3/configure.ac, we do:
>
> AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
>
> The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
> libtool. The libtool documentation says:
>
>
Richard Sandiford wrote:
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade.
I see. Thanks for explaining; that puts to rest my vain hope that there
was some simple thing we could d
On Wed, Nov 28, 2007 at 08:10:18AM +, Richard Sandiford wrote:
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade. (Although as Rask points out, linking never actually
> failed fo
On Wed, Nov 28, 2007 at 08:10:18AM +, Richard Sandiford wrote:
>
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade. (Although as Rask points out, linking never actually
> failed
Mark Mitchell wrote:
> Understood. Out of curiousity, do you eventually build a bfin-uclinux
> compiler, once you've built uClibc, or do you just use the bfin-elf
> compiler on uClinux?
We build up several versions of uClibc with bfin-elf, and then we build
two additional separate toolchains: bfi
Joseph S. Myers wrote:
> * They only build static libstdc++.
>
> * --with-newlib is used, either explicitly or implicitly if newlib is
> built in a combined tree. (I do not know if it works with --with-newlib
> is not used and it's not a combined tree.)
>
> * configure.ac then checks for --wi
Mark Mitchell <[EMAIL PROTECTED]> writes:
>>> I really think that we ought to compare with what happens with MIPS or
>>> Power and figure out what's different. Are you by any chance
>>> configuring a native compiler, rather than a cross?
>>
>> No native compilers - I don't think the linux nommu m
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> > If only static libraries are being built, it may be possible to build them
> > without linking, and in such cases it may be possible to define a generic
> > set of libc symbols considered to be present, as libstdc++-v3/configure.ac
> > does with newlib.
Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
>
>> Yes, that makes sense to me. Bare metal systems are of course somewhat
>> different. What do you think about that?
>
> I think it's well established that at least some bare-metal systems
> default to not linking with any p
> (Dependencies on native or not are a bad idea. It's much better
> always to do the same thing for a GNU/Linux target - or any other
> target that can also be native - than to do things differently
> depending on whether the same target is native or cross.)
Agreed.
When we have a staged build
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> Yes, that makes sense to me. Bare metal systems are of course somewhat
> different. What do you think about that?
I think it's well established that at least some bare-metal systems
default to not linking with any particular start-files (etc.).
> >
Bernd Schmidt wrote:
> If you wish to approve Jie's original patch, I'm not stopping you.
Do you have a pointer? Otherwise, I'll poke around and find it. I
don't have a preconceived notion here, and I'm not trying to kick up a
big fuss; I'm just trying to understand the situation better.
> Wha
Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
>
>> In any case, I think this is something that ought to be decided as a
>> global policy for GCC and its run-time libraries, not something that
>> differs between ports. In particular, if run-time libraries are allowed
>> to dep
On Tue, 27 Nov 2007, Benjamin Kosnik wrote:
> > if there is a rule that
> > libstdc++ configure shouldn't try to link anything, it doesn't appear
> > to be well enforced.
>
> The rule is that libstdc++ shouldn't do link tests unless it knows it
> is native. Not "libstdc++ configure shouldn't try
On Tue, 27 Nov 2007, Bernd Schmidt wrote:
> We have two uses for the bfin-elf compiler - building standalone
> applications, and bootstrapping uClibc for
> bfin-uclinux/bfin-linux-uclibc. For the latter, we need -mfdpic and
> -mid-shared-library multilibs, to at least get a libgcc. This always
>
> if there is a rule that
> libstdc++ configure shouldn't try to link anything, it doesn't appear
> to be well enforced.
The rule is that libstdc++ shouldn't do link tests unless it knows it
is native. Not "libstdc++ configure shouldn't try to link anything."
This means that there is a huge bias
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports. In particular, if run-time libraries are allowed
> to depend on linking in their configu
Mark Mitchell wrote:
> Bernd Schmidt wrote:
>
>> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
>>
>> which leads to
>> checking for shl_load... configure: error: Link tests are not allowed
>> after GCC_NO_EXECUTABLES.
Bernd Schmidt wrote:
> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
>
> which leads to
> checking for shl_load... configure: error: Link tests are not allowed
> after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-tar
Mark Mitchell wrote:
> Note that libstdc++/configure.ac carefully avoids linking except for
> $GLIBCXX_IS_NATIVE. It's a design property that you should not need to
> link. Where in libstdc++ is it requiring linking?
Jie started the thread back in September, and posted the following call
trace:
Bernd Schmidt wrote:
>> Most targets just do the usual dance of building compilers and libraries
>> interleaved appropriately. For example, we build ARM uClinux compilers
>> without ever building an ARM ELF compiler. Why can't you do that for
>> Blackfin?
>
> It sounds more complicated than wha
Mark Mitchell wrote:
>> We have two uses for the bfin-elf compiler - building standalone
>> applications, and bootstrapping uClibc for
>> bfin-uclinux/bfin-linux-uclibc.
>
> Most targets just do the usual dance of building compilers and libraries
> interleaved appropriately. For example, we buil
Bernd Schmidt wrote:
>>> But why isn't that a problem with the target libraries or the way in
>>> which GCC is being configured? Why don't we have that problem for MIPS
>>> or Power, given that they don't link with a target board by default either?
>
> That's not something I can answer, being un
Mark Mitchell wrote:
>> Bernd Schmidt wrote:
>>
If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
error? Why accept it, but make it imply the simulator?
>>> Because all the target libraries fail to build if the configure tests
>>> don't link.
>>
>> But why isn't that
Bernd Schmidt wrote:
>> If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
>> error? Why accept it, but make it imply the simulator?
>
> Because all the target libraries fail to build if the configure tests
> don't link.
But why isn't that a problem with the target libraries or
Mark Mitchell wrote:
> Bernd Schmidt wrote:
>
>> I've committed the following to take care of this. Neither -mfdpic nor
>> -mid-shared-library are actually useful with bfin-elf toolchains, but by
>> making them imply -msim, we can at least get these kinds of configure
>> test executables to link.
Bernd Schmidt wrote:
> I've committed the following to take care of this. Neither -mfdpic nor
> -mid-shared-library are actually useful with bfin-elf toolchains, but by
> making them imply -msim, we can at least get these kinds of configure
> test executables to link.
My impression was that we'd
Jie Zhang wrote:
> Bernd Schmidt wrote:
>> Jie Zhang wrote:
>>> Bernd Schmidt wrote:
Jie Zhang wrote:
> But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are
avoided.
>>> Oops, I meant gcc_no_lin
Rask Ingemann Lambertsen wrote:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
crt532.o: No such file: No such file or directory
I sorted that out by using your config/bfin/elf.h, but there's something
weird. The first time configure runs, it will complain about
GCC_NO_EXECUTABLES b
On Tue, Sep 18, 2007 at 06:09:18PM +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote:
> > Rask Ingemann Lambertsen wrote:
> > >The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
> > >
> > I have not pushed out our recent newlib/libgl
On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote:
> Rask Ingemann Lambertsen wrote:
> >The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
> >
> I have not pushed out our recent newlib/libgloss changes to upstream
> yet. Currently you could get latest blackfin port newlib/
Bernd Schmidt wrote:
Jie Zhang wrote:
bfin-elf-gcc -mfdpic failed to link a simple test case because code is
put into L1 instruction sram and data is put into L1 data sram, but
Blackfin immediate offset load instruction cannot access GOT since the
gap between instruction sram and data sram is
Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Stupid double negatives. Okay, so then y
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are
avoided.
Oops, I meant gcc_no_link = yes.
Stupid double negativ
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
> libstdc++ tries to avoid link tests when configured with newlib. But I
> saw this when working on bfin port gcc:
>From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open linker script file bf532.ld: No such f
Rask Ingemann Lambertsen wrote:
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open linke
Daniel Jacobowitz wrote:
On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote:
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I m
On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote:
> Jie Zhang wrote:
> > Bernd Schmidt wrote:
> >> Jie Zhang wrote:
> >>> But by design if gcc_no_link = no, link tests should be avoided.
> >>
> >> ??? I would have thought gcc_no_link = yes means link tests are avoided.
> >>
> > Oops, I
Jie Zhang wrote:
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Stupid double negatives. Okay, so then your problem is that
g
Bernd Schmidt wrote:
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Oops, I meant gcc_no_link = yes.
Jie
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz
Bernd Schmidt wrote:
Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths int
Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediat
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl
72 matches
Mail list logo
