Link tests after GCC_NO_EXECUTABLES

Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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_load... configure: error: Link tests are not allowed 
after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory 
`/home/jie/blackfin-sources/build43/gcc_build-4.3'
make: *** [all] Error 2

I got this when building bfin-elf-gcc with patched gcc and newlib in the
same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after
GCC_NO_EXECUTABLES. The call path is

"libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
_LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

How about the patch below, which uses LT_SYS_DLOPEN_SELF only when not
cross compiling.


Jie


	* libtool.m4 (_LT_LANG_C_CONFIG): Only use LT_SYS_DLOPEN_SELF
	when not cross compiling.

Index: libtool.m4
===================================================================
--- libtool.m4  (revision 128569)
+++ libtool.m4  (working copy)
@@ -5117,7 +5117,9 @@
    _LT_LINKER_SHLIBS($1)
    _LT_SYS_DYNAMIC_LINKER($1)
    _LT_LINKER_HARDCODE_LIBPATH($1)
-  LT_SYS_DLOPEN_SELF
+  if test "$cross_compiling" = no; then
+    LT_SYS_DLOPEN_SELF
+  fi
    _LT_CMD_STRIPLIB

    # Report which library types will actually be built

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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... immediate
> checking for shl_load... configure: error: Link tests are not allowed 
> after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory 
> `/home/jie/blackfin-sources/build43/gcc_build-4.3'
> make: *** [all] Error 2
> 
> I got this when building bfin-elf-gcc with patched gcc and newlib in the
> same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after
> GCC_NO_EXECUTABLES. The call path is
> 
> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

I saw something similar, but managed to make it go away.  I don't 
remember how exactly (this kind of issue seems to happen to me all the 
time, for different reasons each time), but I think the actual problem 
was that you need to ensure that gcc_no_link doesn't get set.  That's a 
test somewhat earlier in configure.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 into programs... immediate
>> checking for shl_load... configure: error: Link tests are not allowed 
>> after GCC_NO_EXECUTABLES.
>> make[1]: *** [configure-target-libstdc++-v3] Error 1
>> make[1]: Leaving directory 
>> `/home/jie/blackfin-sources/build43/gcc_build-4.3'
>> make: *** [all] Error 2
>>
>> I got this when building bfin-elf-gcc with patched gcc and newlib in the
>> same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after
>> GCC_NO_EXECUTABLES. The call path is
>>
>> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
> 
> I saw something similar, but managed to make it go away.  I don't 
> remember how exactly (this kind of issue seems to happen to me all the 
> time, for different reasons each time), but I think the actual problem 
> was that you need to ensure that gcc_no_link doesn't get set.  That's a 
> test somewhat earlier in configure.
> 
But by design if gcc_no_link = no, link tests should be avoided.

Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 
gcc_no_link=yes.  Find out why it's setting that.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Daniel Jacobowitz]

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 meant gcc_no_link = yes.
> 
> Stupid double negatives.  Okay, so then your problem is that gcc_no_link=yes.  
> Find out why it's setting that.

It always does for newlib.  The libtool tests are relatively recent
(from some recent autotools upgrade).

I believe this particular error comes from using --enable-shared on a
newlib target.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 meant gcc_no_link = yes.
>> Stupid double negatives.  Okay, so then your problem is that gcc_no_link=yes.  
>> Find out why it's setting that.
> 
> It always does for newlib.  The libtool tests are relatively recent
> (from some recent autotools upgrade).
> 
Yes, It was added by

http://sourceware.org/ml/binutils/2007-05/msg00247.html


Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 your problem is that 
> gcc_no_link=yes.  Find out why it's setting that.
> 
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 too large. Using -msim as 
default will pass this test case and build gcc without problem but I 
would like bfin-elf-gcc target hardware board by default. Use -fPIC as 
default is not good, since -fpic is enough for any real applications. So 
I would like to avoid link test for shl_load when GCC_NO_EXECUTABLES.


Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 negatives.  Okay, so then your problem is that 
>> gcc_no_link=yes.  Find out why it's setting that.
>>
> 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 too large. Using -msim as 
> default will pass this test case and build gcc without problem but I 
> would like bfin-elf-gcc target hardware board by default.

Any chance we could target it in such a way as to not put everything in 
L1 by default?  I think it's stupid to have configure tests failing for 
such a reason.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 too large. Using -msim 
>> as default will pass this test case and build gcc without problem but 
>> I would like bfin-elf-gcc target hardware board by default.
> 
> Any chance we could target it in such a way as to not put everything in 
> L1 by default?  I think it's stupid to have configure tests failing for 
> such a reason.
> 
But then we need add sdram initialization code into crt files, which is 
usually provided by applications when needed.


Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

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 negatives.  Okay, so then your problem is that
>> gcc_no_link=yes.  Find out why it's setting that.
>>
> 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 too large. Using -msim as
> default will pass this test case and build gcc without problem but I
> would like bfin-elf-gcc target hardware board by default. Use -fPIC as
> default is not good, since -fpic is enough for any real applications. So
> I would like to avoid link test for shl_load when GCC_NO_EXECUTABLES.

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
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

[-- Attachment #2: fix-bfin-elf.diff --]
[-- Type: text/x-patch, Size: 2198 bytes --]

Index: ChangeLog
===================================================================
--- ChangeLog	(revision 130463)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2007-11-27  Bernd Schmidt  <bernd.schmidt@analog.com>
+
+	* config/bfin/elf.h (SUBTARGET_DRIVER_SELF_SPECS): New macro.
+	* doc/invoke.texi (Blackfin Options): Document the effects.
+
 2007-11-27  Ben Elliston  <bje@au.ibm.com>
 
 	* config/rs6000/sysv4.opt (m32): Add Negative(m64).
Index: config/bfin/elf.h
===================================================================
--- config/bfin/elf.h	(revision 130463)
+++ config/bfin/elf.h	(working copy)
@@ -30,4 +30,8 @@ asm ("P3 = [SP + 20];\n\tcall " USER_LAB
 asm (TEXT_SECTION_ASM_OP);
 #endif
 
+#undef SUBTARGET_DRIVER_SELF_SPECS
+#define SUBTARGET_DRIVER_SELF_SPECS \
+     "%{mfdpic:-msim} %{mid-shared-library:-msim}"
+
 #define NO_IMPLICIT_EXTERN_C
Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 130463)
+++ doc/invoke.texi	(working copy)
@@ -8668,6 +8668,8 @@ provided by libgloss to be linked in if 
 Specifies that the program will be run on the simulator.  This causes
 the simulator BSP provided by libgloss to be linked in.  This option
 has effect only for @samp{bfin-elf} toolchain.
+Certain other options, such as @option{-mid-shared-library} and
+@option{-mfdpic}, imply @option{-msim}.
 
 @item -momit-leaf-frame-pointer
 @opindex momit-leaf-frame-pointer
@@ -8717,6 +8719,7 @@ uClinux kernel.
 Generate code that supports shared libraries via the library ID method.
 This allows for execute in place and shared libraries in an environment
 without virtual memory management.  This option implies @option{-fPIC}.
+With a @samp{bfin-elf} target, this option implies @option{-msim}.
 
 @item -mno-id-shared-library
 @opindex mno-id-shared-library
@@ -9642,6 +9645,7 @@ implies @option{-fPIE}.  With @option{-f
 assumes GOT entries and small data are within a 12-bit range from the
 GOT base address; with @option{-fPIC} or @option{-fPIE}, GOT offsets
 are computed with 32 bits.
+With a @samp{bfin-elf} target, this option implies @option{-msim}.
 
 @item -minline-plt
 @opindex minline-plt

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 developed the consensus that generic ELF
ports should not have a default board.  (IIRC, Power and MIPS are like
that; if you don't say -msim explicitly, you get a link error.)

If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
error?  Why accept it, but make it imply the simulator?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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.
> 
> My impression was that we'd developed the consensus that generic ELF
> ports should not have a default board.  (IIRC, Power and MIPS are like
> that; if you don't say -msim explicitly, you get a link error.)
> 
> 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.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 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?

I'm not trying to be rhetorical.  I just want to understand what's going
on here because it sounded to me from your patch like we were making the
compiler accept options that don't make sense in order to work around
some problem -- and maybe that problem is what should really be solved.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 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 unfamiliar with both targets.
Maybe they don't build/need a default multilib for "no particular target"?

>> I'm not trying to be rhetorical.  I just want to understand what's going
>> on here because it sounded to me from your patch like we were making the
>> compiler accept options that don't make sense in order to work around
>> some problem -- and maybe that problem is what should really be solved.

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
worked since what is now "-msim" was default behaviour, but it started
to fail the libstdc++ configury once Jie changed that to use
target-specific linker scripts.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 unfamiliar with both targets.
> Maybe they don't build/need a default multilib for "no particular target"?

I'm pretty certain that both do have a default multilib for a lowest
common denominator CPU, and that you have to provide explicit options to
link with it.

> 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 build ARM uClinux compilers
without ever building an ARM ELF compiler.  Why can't you do that for
Blackfin?

> For the latter, we need -mfdpic and
> -mid-shared-library multilibs, to at least get a libgcc.  This always
> worked since what is now "-msim" was default behaviour, but it started
> to fail the libstdc++ configury once Jie changed that to use
> target-specific linker scripts.

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?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 build ARM uClinux compilers
> without ever building an ARM ELF compiler.  Why can't you do that for
> Blackfin?

It sounds more complicated than what we do.  We just build bfin-elf,
build uClibc with it, and build up the bfin-*linux* compilers.  Just
three simple steps.  What do you do for ARM uClinux?

> 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 memory manager would
be very happy about running gcc.  Running the testsuite is bad enough.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 what we do.  We just build bfin-elf,
> build uClibc with it, and build up the bfin-*linux* compilers.  Just
> three simple steps.  What do you do for ARM uClinux?

I'm not sure of the exact details.  It could be that your way is
simpler.  Perhaps on other systems the ABIs don't quite match, or
something.  In any case, I think that's immaterial.

>> 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 memory manager would
> be very happy about running gcc.  Running the testsuite is bad enough.

Yeah, I didn't think so, but I was trying to think about what could be
different.  I've CC'd Richard Sandiford, as I discussed some of the MIPS
stuff with him at one point.

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?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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:

"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-target-libstdc++-v3] Error 1

Jie had a patch for that, but I decided to fix it by just making things
link, since I've seen other occurrences of this problem over the years.
 It just seems more robust not to require the configure scripts to avoid
linking.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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-target-libstdc++-v3] Error 1

Thanks.  Perhaps the difference here is that <dlfcn.h> isn't available
for MIPS/Power ELF, but is available in your configuration because
you're building with uClibc as your C library?  If so, I think there are
ways that we can solve this problem that don't involve adding -msim.  (I
haven't looked at Jie's approach, so I can't comment on that.)

> Jie had a patch for that, but I decided to fix it by just making things
> link, since I've seen other occurrences of this problem over the years.
>  It just seems more robust not to require the configure scripts to avoid
> linking.

I disagree.  Since the preferred bare-metal setup is that linking not
work without -msim (or a -T option), we don't want configure tests that
detect any properties that might depend on what happens when you link.
We want to make sure that detected properties are a property only of the
parts that a user isn't going to change.

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 configure tests, that's something everyone
should know.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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.
>> make[1]: *** [configure-target-libstdc++-v3] Error 1
> 
> Thanks.  Perhaps the difference here is that <dlfcn.h> isn't available
> for MIPS/Power ELF, but is available in your configuration because
> you're building with uClibc as your C library?

We're talking bfin-elf here, so that'd be newlib.  I have no great
desire to meddle in the affairs of libtool, and I'd like to again make
the point that this isn't the first time I've seen the "Link tests are
not allowed after GCC_NO_EXECUTABLES" message; if there is a rule that
libstdc++ configure shouldn't try to link anything, it doesn't appear to
be well enforced.

There's another reason why the patch is helpful: the uClibc build system
tries to guess an OUTPUT_FORMAT for the linker from the output of
  bfin-elf-gcc -mfdpic -Wl,--verbose
which currently fails because without -msim, the linker is trying to
pull in the wrong objects.  I suppose that could be changed too, or I
could try to investigate other ways of building up all the toolchains
that don't require -mfdpic multilibs for bfin-elf.

> 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 configure tests, that's something everyone
> should know.

If you wish to approve Jie's original patch, I'm not stopping you.  I'll
then revert my patch if I can get some fix into the uClibc repository,
but I reserve the right to reapply it in the future if libstdc++ breaks
my build again.

What I'm trying to do here is to ensure that gcc-4.3 will work out of
the box as a compiler for our uClinux distribution.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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.

> What I'm trying to do here is to ensure that gcc-4.3 will work out of
> the box as a compiler for our uClinux distribution.

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?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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: bfin-uclinux and bfin-linux-uclibc.
 The former produces flat binaries (a very simple binary format), while
the latter produces ELF FD-PIC binaries (using the -mfdpic), which
behave essentially like normal ELF binaries and support shared libraries
and dynamic loading.  In the past we used to allow -mfdpic with the
bfin-uclinux toolchain, but the gcc build system didn't cope too well
and we couldn't get it to build shared libraries for one set of
multilibs and not for the other, so we split things up.

We also need a bfin-elf toolchain, and while bare hardware applications
can't use -mfdpic or -mid-shared-library, in the past it hasn't hurt to
provide these multilibs, and it allows us to build up uClibc quite easily.

I guess I could try to build up C-only versions of bfin-uclinux and
bfin-linux-uclibc first and use them for building uClibc, although I'm
certain to get complaints about how the build script suddenly takes so
much longer, and it all seems somewhat more complicated than necessary.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

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 configure tests, that's something everyone
> should know.

For GNU/Linux, we decided some time ago that libstdc++ configuration would 
require link tests in order to identify the precise functions available in 
that particular multilib's libc version and configuration (depending, for 
example, on how uClibc is configured).  It is, after all, the case that 
you cannot create a proper libstdc++ shared library on a glibc system 
without linking it against a shared glibc so that it is bound to the right 
symbol versions in that glibc (static libraries do not generally remain 
compatible across glibc upgrades where symbols the static libraries use 
get new versions), and so you must already have a C library you can link 
against in order for libstdc++ to build, so you may as well use that 
library at configure time.  Some other targets similarly do many link 
checks in libstdc++-v3/crossconfig.m4.

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
joseph@codesourcery.com

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 depend on linking in their configure tests, that's something everyone
>> should know.
> 
> For GNU/Linux, we decided some time ago that libstdc++ configuration would 
> require link tests in order to identify the precise functions available in 
> that particular multilib's libc version and configuration (depending, for 
> example, on how uClibc is configured).

Yes, that makes sense to me.  Bare metal systems are of course somewhat
different.  What do you think about that?

> 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.

Do you understand how MIPS/Power works?  I'd really like to know what
the difference is.  It might be an easy difference to resolve, or there
might be something more fundamental, but before we do anything I'd like
to know why one works and the other doesn't.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

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.).

> > 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.
> 
> Do you understand how MIPS/Power works?  I'd really like to know what
> the difference is.  It might be an easy difference to resolve, or there
> might be something more fundamental, but before we do anything I'd like
> to know why one works and the other doesn't.

* 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 --with-newlib and handles it specially by 
hardcoding information about the functions present.

* With --disable-shared, GLIBCXX_ENABLE_SYMVERS disables symbol versioning 
instead of trying to do certain link tests it would do if shared libraries 
are being built; it also does so if unable to link.

* Each other configure test that might wish to link also needs special 
handling or to be appropriately conditional.

* Such special handling is also needed in other target libraries that 
support bare-metal systems (some libraries such as libgomp and libmudflap 
may well not do so at all).


So make sure the build is using --disable-shared if you can't link; if 
that still doesn't help, some configure test somewhere may need disabling, 
either if unable to link, or if not building shared libraries, or some 
other condition.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 particular start-files (etc.).

Sorry, I meant to be asking: "for bare-metal, do you think we should
permit the library configure scripts to perform link tests (as we do for
GNU/Linux), or should we require that they perform no link tests?"

>> Do you understand how MIPS/Power works?  I'd really like to know what
>> the difference is.  It might be an easy difference to resolve, or there
>> might be something more fundamental, but before we do anything I'd like
>> to know why one works and the other doesn't.

Thanks for answering this.  Bernd, I'd be interested in whether any of
that helps.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

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 --with-newlib and handles it specially by 
> hardcoding information about the functions present.
> 
> * With --disable-shared, GLIBCXX_ENABLE_SYMVERS disables symbol versioning 
> instead of trying to do certain link tests it would do if shared libraries 
> are being built; it also does so if unable to link.

> So make sure the build is using --disable-shared if you can't link; if 
> that still doesn't help, some configure test somewhere may need disabling, 
> either if unable to link, or if not building shared libraries, or some 
> other condition.

We're doing all that.  I think Richard gave the correct answer elsewhere
in the thread: it doesn't actually work without hacks on MIPS either.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

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.
>
> Do you understand how MIPS/Power works?  I'd really like to know what
> the difference is.  It might be an easy difference to resolve, or there
> might be something more fundamental, but before we do anything I'd like
> to know why one works and the other doesn't.

I don't, but IIRC one thing that was necessary at one time for
CRIS (cris-elf; supposedly bare-metal newlib) was to a bit
hackishly copy the libgloss startup files to the newlib build
directory where they were expected as per
<http://sourceware.org/ml/newlib/2005/msg00089.html>.

You'll get a "X is not implemented and will always fail" warning
from linking with the non-working default stub functions when
not linking in any board-support package, so IMHO there are no
false pretenses about having built a correct program.

Not a proposed solution, just a datapoint of the hackery that's
pragmatically and historically been needed.  I think at the
time, I just noticed that a toolchain that built (might have
been ppc, might have been mips) happened to have a stub crt0.o
in a place that corresponded to search paths (newlib rather than
libgloss) when linking.

brgds, H-P

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> 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 memory manager would
>> be very happy about running gcc.  Running the testsuite is bad enough.
>
> Yeah, I didn't think so, but I was trying to think about what could be
> different.  I've CC'd Richard Sandiford, as I discussed some of the MIPS
> stuff with him at one point.

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 for "int main () { return 0; }" without a -T option for MIPS;
it just gave a warning that __start was undefined and that the entry
point was being set to some built-in value.  I think both Dan and I
thought it should be an error instead, but that didn't fly...)

However, with the libtool upgrade, the shl_load test failed for MIPS
in the same way as it did for Bernd on Blackfin.  Rask got around this
by adding a "-T" option for the simulator board in top-level configure.
I still object to this approach for the reasons we discussed before,
but I didn't have time to come up with an alternative of my own,
so I didn't make a fuss.  It did at least get an unpatched libstdc++-v3
building again.

If Jie has a patch that gets us around the shl_load failure, I'd be glad
for us to go that route, and go back to not using the -T simulator options,
if that's possible.  Especially if we can do it before 4.3 is out, since
4.3 will then keep to the precedent set by earlier releases, and not set
a new precedent of its own.

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Wed, Nov 28, 2007 at 08:10:18AM +0000, 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 for "int main () { return 0; }" without a -T option for MIPS;
> it just gave a warning that __start was undefined and that the entry
> point was being set to some built-in value.  I think both Dan and I
> thought it should be an error instead, but that didn't fly...)

This is the error message (which we still get):
warning: cannot find entry symbol _start; defaulting to 0000000000400040

> However, with the libtool upgrade, the shl_load test failed for MIPS
> in the same way as it did for Bernd on Blackfin.  Rask got around this
> by adding a "-T" option for the simulator board in top-level configure.

   Not quite; I arranged for configure to add -L and -B options pointing
into the newlib, libgloss and libgloss/cpu directories when configuring
subdirectories, and it happens only if you build newlib. If you get a link
error with the default -T option, there's still no dice. sparc-unknown-elf
is an example of such a target, but most *-elf targets build out of the box
as long as they can find their newlib and libgloss bits.

> I still object to this approach for the reasons we discussed before,
> but I didn't have time to come up with an alternative of my own,
> so I didn't make a fuss.  It did at least get an unpatched libstdc++-v3
> building again.

   It is not just libstdc++-v3, it is also libgfortran, libobjc, libjava and
libffi. Maybe also libssp and libiberty.

> If Jie has a patch that gets us around the shl_load failure, I'd be glad
> for us to go that route, and go back to not using the -T simulator options,
> if that's possible.  Especially if we can do it before 4.3 is out, since
> 4.3 will then keep to the precedent set by earlier releases, and not set
> a new precedent of its own.

   I'm not against it in principle, but in practice, configuring target
libraries without linking is very fragile and has been broken more often
than not. Unless someone voluteers to battle with autoconf and libtool every
time it breaks, I'd very much prefer to keep the -L and -B options.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Daniel Jacobowitz]

On Wed, Nov 28, 2007 at 08:10:18AM +0000, 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 for "int main () { return 0; }" without a -T option for MIPS;
> it just gave a warning that __start was undefined and that the entry
> point was being set to some built-in value.  I think both Dan and I
> thought it should be an error instead, but that didn't fly...)

It didn't violently not-fly either; I think we persuaded everyone, but
I haven't been back to submit the obvious patch at the end of that
thread yet.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 do to fix this for Blackfin.

> However, with the libtool upgrade, the shl_load test failed for MIPS
> in the same way as it did for Bernd on Blackfin.  Rask got around this
> by adding a "-T" option for the simulator board in top-level configure.
> I still object to this approach for the reasons we discussed before

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.

Rask, we may have to agree to disagree, as it's clear we both understand
the pros and cons.  I agree that making things link is more likely to
work, in the sense that it puts a lower burden on run-time library
configure scripts -- but I also think it increases the risk that the
configure scripts get the wrong answer.  And, in some cases, there isn't
any way to get a bare-metal toolchain to link; the necessary bits may be
outside Newlib itself and provided only by the end user.

> If Jie has a patch that gets us around the shl_load failure, I'd be glad
> for us to go that route, and go back to not using the -T simulator options,
> if that's possible.

Bernd kindly forwarded Jie's patch.  Unfortunately, it checks
$cross_compile, which means that native and cross compilers will
configure differently, so I don't think we can use that directly.

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:

     Enable checking for dlopen support. This macro should be used if
     the package makes use of the `-dlopen' and `-dlpreopen' flags,
     otherwise libtool will assume that the system does not support
     dlopening.  The macro must be called *before* `AC_PROG_LIBTOOL'.

But, for a bare-metal toolchain, I don't think we need that.  So, I'm
guessing that:

  if test "x${with_newlib}" != "xyes"; then
    AC_LIBTOOL_DLOPEN
  fi

will fix the problem.  (We already have checks for $with_newlib
elsewhere in configure.ac, so I think this is in the same spirit, though
a libstdc++ maintainer would of course be best to review the patch.)

Bernd, Richard, Rask, would one of you be willing to explore that route?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> 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:
>
>      Enable checking for dlopen support. This macro should be used if
>      the package makes use of the `-dlopen' and `-dlpreopen' flags,
>      otherwise libtool will assume that the system does not support
>      dlopening.  The macro must be called *before* `AC_PROG_LIBTOOL'.
>
> But, for a bare-metal toolchain, I don't think we need that.  So, I'm
> guessing that:
>
>   if test "x${with_newlib}" != "xyes"; then
>     AC_LIBTOOL_DLOPEN
>   fi
>
> will fix the problem.  (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)
>
> Bernd, Richard, Rask, would one of you be willing to explore that route?

Sure, thanks for the suggestion.  I've built binutils with _start warning
turned into an error, so I'll see how far I get.

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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.
>
> Rask, we may have to agree to disagree, as it's clear we both understand
> the pros and cons.  I agree that making things link is more likely to
> work, in the sense that it puts a lower burden on run-time library
> configure scripts -- but I also think it increases the risk that the
> configure scripts get the wrong answer.

   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 results.

> And, in some cases, there isn't
> any way to get a bare-metal toolchain to link; the necessary bits may be
> outside Newlib itself and provided only by the end user.

   That's not in itself a problem; you could supply --with-sysroot assuming
you have all the necessary parts built already. It's only when you need GCC
to build those other parts needed to link that it becomes a mess. At the
moment, --with-newlib is a special case in that it allows you to configure
and build a newlib target from scratch with just "configure ...; make" while
e.g. glibc and uClibc targets need a more elaborate process, including
building GCC twice in many cases, and perhaps installing intermediate
libraries to satisfy link tests. A more general --with-libc=dirname option
would configure and build in "dirname", then configure libstdc++ etc. with a
"-B dirname" option to make link tests work.

> But, for a bare-metal toolchain, I don't think we need that.  So, I'm
> guessing that:
> 
>   if test "x${with_newlib}" != "xyes"; then
>     AC_LIBTOOL_DLOPEN
>   fi
> 
> will fix the problem.

   How about an explicit option --without-link-tests, --disable-link-tests
or something like that? Most people don't test on bare-metal targets and
won't notice if they break, but given an explicit option to turn off link
tests, you could make it a requirement to test that configure works with
link tests disabled before checking in changes to configure.{ac,in}.

> (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)

   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 configure.{ac,in}. Supply an option
--simulate-link-tests=file_with_results with the default being no and be
happy. A bit like having created config.cache by hand before configuring, I
suppose.

> Bernd, Richard, Rask, would one of you be willing to explore that route?

   I see that Richard has already started, so I'll leave it to him.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 results.

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 rely on that.

>    How about an explicit option --without-link-tests, --disable-link-tests
> or something like that? Most people don't test on bare-metal targets and
> won't notice if they break, but given an explicit option to turn off link
> tests, you could make it a requirement to test that configure works with
> link tests disabled before checking in changes to configure.{ac,in}.

That's a reasonable idea, but as Joseph said, for GNU/Linux (and other
"hosted" platforms, presumably), we've decided we do need to do links,
so on those platforms, --without-link-tests would probably result in
broken libraries.

>    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 configure.{ac,in}. Supply an option
> --simulate-link-tests=file_with_results with the default being no and be
> happy.

We would still need to hard-code things.  For example, we want libstdc++
to call functions that are in Newlib (but might not be in other C
libraries).  So, libstdc++ has to have some way of asking whether the
function is in the C library, whether by linking, having the answer
hard-coded, or doing some other kind of probe (running nm?).

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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't see how that's any worse than
> > assuming a set of hard coded link test results.
> 
> 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 rely on that.

   Ok, I got that. I suppose that means you don't actually have a way of
making libstdc++ use such extra functionality?

> >    How about an explicit option --without-link-tests, --disable-link-tests
> > or something like that? Most people don't test on bare-metal targets and
> > won't notice if they break, but given an explicit option to turn off link
> > tests, you could make it a requirement to test that configure works with
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > link tests disabled before checking in changes to configure.{ac,in}.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's a reasonable idea, but as Joseph said, for GNU/Linux (and other
> "hosted" platforms, presumably), we've decided we do need to do links,
> so on those platforms, --without-link-tests would probably result in
> broken libraries.

   You wouldn't be using those libraries -- I wouldn't even expect people to
actually wait for the libraries to build -- just check that 'configure
--without-link-tests' runs to completion with no errors, then press ^C.

> >    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 configure.{ac,in}. Supply an option
> > --simulate-link-tests=file_with_results with the default being no and be
> > happy.
> 
> We would still need to hard-code things.

   Yes. The difference being it wouldn't break the first time someone edits
configure.ac. --simulate-link-tests=file would be similar to
--cache-file=file, but anything not specified in 'file' would default to
'no' instead of being probed for. We would ship a file with the hard-coded
answers. It would need no hacks, tricks or work-arounds in configure.ac, and
it would deal with all the libraries, present, past and future, in one fell
swoop.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 rely on that.
> 
>    Ok, I got that. I suppose that means you don't actually have a way of
> making libstdc++ use such extra functionality?

Correct.

>    You wouldn't be using those libraries -- I wouldn't even expect people to
> actually wait for the libraries to build -- just check that 'configure
> --without-link-tests' runs to completion with no errors, then press ^C.

Oh, I understand now; that makes sense to me.

>>>    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 configure.{ac,in}. Supply an option
>>> --simulate-link-tests=file_with_results with the default being no and be
>>> happy.
>> We would still need to hard-code things.
> 
>    Yes. The difference being it wouldn't break the first time someone edits
> configure.ac. --simulate-link-tests=file would be similar to
> --cache-file=file, but anything not specified in 'file' would default to
> 'no' instead of being probed for. We would ship a file with the hard-coded
> answers. It would need no hacks, tricks or work-arounds in configure.ac, and
> it would deal with all the libraries, present, past and future, in one fell
> swoop.

That sounds plausible too.  For libstdc++, there's a fair amount of
target-specificity, so you'd presumably end up with multiple cache files
for various targets, but that sounds like it would work.  The tradeoff
is that you might end up adding checks for functions that are in fact
available in Newlib, but, because nobody added them to the cache file,
wouldn't be used.  The advantage to the current setup is that you get a
loud failure, and have to go actually work out the right answer.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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 configure.{ac,in}. Supply an option
> >>> --simulate-link-tests=file_with_results with the default being no and be
> >>> happy.

> The advantage to the current setup is that you get a
> loud failure, and have to go actually work out the right answer.

   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 target library build directories just before running configure. That
ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
and AC_LIBTOOL_DLOPEN, which is manageble.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Rask Ingemann Lambertsen <rask@sygehus.dk> 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 to explicitly
>> >>> avoiding them in each and every configure.{ac,in}. Supply an option
>> >>> --simulate-link-tests=file_with_results with the default being no and be
>> >>> happy.
>
>> The advantage to the current setup is that you get a
>> loud failure, and have to go actually work out the right answer.
>
>    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 target library build directories just before running configure. That
> ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
> and AC_LIBTOOL_DLOPEN, which is manageble.

I've lost track of whether we're still talking about what to do for 4.3,
or whether we're talking about future directions.  So: are we considering
this for 4.3, or for 4.4+?

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Sat, Dec 01, 2007 at 09:48:20AM +0000, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <rask@sygehus.dk> 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 target library build directories just before running configure. That
> > ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
> > and AC_LIBTOOL_DLOPEN, which is manageble.
> 
> I've lost track of whether we're still talking about what to do for 4.3,
> or whether we're talking about future directions.  So: are we considering
> this for 4.3, or for 4.4+?

   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. Then we can
decide for 4.3 or 4.4.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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. Then we can
> decide for 4.3 or 4.4.

   Correction: $with_newlib seems to be completely unavailable in the toplevel
Makefile(.tpl). Any ideas?

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Andreas Schwab]

Rask Ingemann Lambertsen <rask@sygehus.dk> 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
>> libgfortran, because it seems to basicly work apart from that. Then we can
>> decide for 4.3 or 4.4.
>
>    Correction: $with_newlib seems to be completely unavailable in the toplevel
> Makefile(.tpl). Any ideas?

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 target directories.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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 target directories.

   Thanks. I frequently configure using --with-newlib --without-newlib and
configure gets it right, so I won't just grep the configure args for
--with-newlib. Instead I use AC_SUBST to export with_newlib to the
Makefile.

   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++-v3 with unmodified
libstdc++-v3/configure.ac. Libgfortran's configure.ac needs just the symbol
versioning patch ported from libssp. And that's it!

   The file config-newlib-linktests.cache is just an extract of the
config.cache files I had lying around, except for the last four entries that
I had to extract manually from libgfortran's config.log because they're not
saved to config.cache. It's reasonably straight-forward to add entries as
needed.

Index: configure.ac
===================================================================
--- configure.ac	(revision 130442)
+++ configure.ac	(working copy)
 AC_SUBST(CONFIGURE_GDB_TK)
 AC_SUBST(GDB_TK)
 AC_SUBST(INSTALL_GDB_TK)
+AC_SUBST(with_newlib)
 
 # Build module lists & subconfigure args.
 AC_SUBST(build_configargs)
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 130442)
+++ Makefile.tpl	(working copy)
@@ -394,6 +394,7 @@
 # ------------------------------------
 # Miscellaneous targets and flag lists
 # ------------------------------------
+with_newlib = @with_newlib@
 
 # The first rule in the file had better be this one.  Don't put any above it.
 # This lives here to allow makefile fragments to contain dependencies.
@@ -814,7 +815,12 @@
 	  *) topdir=`echo [+subdir+]/[+module+]/ | \
 		sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
 	esac; \
-	srcdiroption="--srcdir=$${topdir}/[+module+]"; \
+	[+ IF check_multilibs
+	+]if test ! -f config.cache -a "x$(with_newlib)" = "xyes"; then \
+	  echo "Using link test cache $${s}/config-newlib-linktests.cache."; \
+	  cp $${s}/config-newlib-linktests.cache config.cache; \
+	fi; \
+	[+ ENDIF check_multilibs +]srcdiroption="--srcdir=$${topdir}/[+module+]"; \
 	libsrcdir="$$s/[+module+]"; \
 	[+ IF no-config-site +]rm -f no-such-file || : ; \
 	CONFIG_SITE=no-such-file [+ ENDIF +]$(SHELL) $${libsrcdir}/configure \
Index: config-ml.in
===================================================================
--- config-ml.in	(revision 130442)
+++ config-ml.in	(working copy)
@@ -893,6 +893,10 @@
 	fi
     fi
 
+    if test ! -f config.cache -a "x${with_newlib}" = "xyes"; then
+      echo "Using link test cache ${s}/config-newlib-linktests.cache."
+      cp ${s}/config-newlib-linktests.cache config.cache
+    fi
     if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
 	--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
 	${ac_configure_args} ${ml_config_env} ${ml_srcdiroption} ; then
Index: libgfortran/configure.ac
===================================================================
--- libgfortran/configure.ac	(revision 130442)
+++ libgfortran/configure.ac	(working copy)
@@ -144,7 +144,13 @@
 EOF
 save_LDFLAGS="$LDFLAGS"
 LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
-AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+if test x$gcc_no_link = xyes; then
+  # If we cannot link, we cannot build shared libraries, so do not use
+  # symbol versioning.
+  gfortran_use_symver=no
+else
+  AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+fi
 LDFLAGS="$save_LDFLAGS"
 AC_MSG_RESULT($gfortran_use_symver)
 AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
--- /dev/null	2007-11-25 19:34:41.836000250 +0100
+++ config-newlib-linktests.cache	2007-12-01 20:48:47.000000000 +0100
@@ -0,0 +1,298 @@
+ac_cv_func_accept=${ac_cv_func_accept=no}
+ac_cv_func_access=${ac_cv_func_access=no}
+ac_cv_func_alarm=${ac_cv_func_alarm=no}
+ac_cv_func_alloca_works=${ac_cv_func_alloca_works=yes}
+ac_cv_func_argz_append=${ac_cv_func_argz_append=yes}
+ac_cv_func_argz_create_sep=${ac_cv_func_argz_create_sep=yes}
+ac_cv_func_argz_insert=${ac_cv_func_argz_insert=yes}
+ac_cv_func_argz_next=${ac_cv_func_argz_next=yes}
+ac_cv_func_argz_stringify=${ac_cv_func_argz_stringify=yes}
+ac_cv_func_backtrace=${ac_cv_func_backtrace=no}
+ac_cv_func_backtrace_symbols=${ac_cv_func_backtrace_symbols=no}
+ac_cv_func_bind=${ac_cv_func_bind=no}
+ac_cv_func_chdir=${ac_cv_func_chdir=no}
+ac_cv_func_chsize=${ac_cv_func_chsize=no}
+ac_cv_func_clock=${ac_cv_func_clock=yes}
+ac_cv_func_close=${ac_cv_func_close=yes}
+ac_cv_func_closedir=${ac_cv_func_closedir=no}
+ac_cv_func_connect=${ac_cv_func_connect=no}
+ac_cv_func_ctime=${ac_cv_func_ctime=yes}
+ac_cv_func_dlopen=${ac_cv_func_dlopen=no}
+ac_cv_func_dup2=${ac_cv_func_dup2=no}
+ac_cv_func_dup=${ac_cv_func_dup=no}
+ac_cv_func__dyld_func_lookup=${ac_cv_func__dyld_func_lookup=no}
+ac_cv_func_epoll_create=${ac_cv_func_epoll_create=no}
+ac_cv_func_execl=${ac_cv_func_execl=no}
+ac_cv_func_execve=${ac_cv_func_execve=no}
+ac_cv_func_execvp=${ac_cv_func_execvp=no}
+ac_cv_func_fcntl=${ac_cv_func_fcntl=yes}
+ac_cv_func_fdopen=${ac_cv_func_fdopen=yes}
+ac_cv_func_fork=${ac_cv_func_fork=no}
+ac_cv_func_fork=${ac_cv_func_fork=yes}
+ac_cv_func_fp_enable=${ac_cv_func_fp_enable=no}
+ac_cv_func_fp_trap=${ac_cv_func_fp_trap=no}
+ac_cv_func_fstat=${ac_cv_func_fstat=yes}
+ac_cv_func_fsync=${ac_cv_func_fsync=no}
+ac_cv_func_ftruncate=${ac_cv_func_ftruncate=no}
+ac_cv_func_getcwd=${ac_cv_func_getcwd=no}
+ac_cv_func_gethostbyname_r=${ac_cv_func_gethostbyname_r=no}
+ac_cv_func_gethostname=${ac_cv_func_gethostname=no}
+ac_cv_func_getifaddrs=${ac_cv_func_getifaddrs=no}
+ac_cv_func_getloadavg=${ac_cv_func_getloadavg=no}
+ac_cv_func_getlogin=${ac_cv_func_getlogin=no}
+ac_cv_func_getpagesize=${ac_cv_func_getpagesize=no}
+ac_cv_func_getpeername=${ac_cv_func_getpeername=no}
+ac_cv_func_getpwuid=${ac_cv_func_getpwuid=no}
+ac_cv_func_getrlimit=${ac_cv_func_getrlimit=no}
+ac_cv_func_getrusage=${ac_cv_func_getrusage=no}
+ac_cv_func_getsockname=${ac_cv_func_getsockname=no}
+ac_cv_func_getsockopt=${ac_cv_func_getsockopt=no}
+ac_cv_func_gettimeofday=${ac_cv_func_gettimeofday=yes}
+ac_cv_func_htonl=${ac_cv_func_htonl=no}
+ac_cv_func_htons=${ac_cv_func_htons=no}
+ac_cv_func_inet_addr=${ac_cv_func_inet_addr=no}
+ac_cv_func_inet_aton=${ac_cv_func_inet_aton=no}
+ac_cv_func_inet_pton=${ac_cv_func_inet_pton=no}
+ac_cv_func_kevent=${ac_cv_func_kevent=no}
+ac_cv_func_kill=${ac_cv_func_kill=yes}
+ac_cv_func_kqueue=${ac_cv_func_kqueue=no}
+ac_cv_func_link=${ac_cv_func_link=yes}
+ac_cv_func_listen=${ac_cv_func_listen=no}
+ac_cv_func_localtime_r=${ac_cv_func_localtime_r=yes}
+ac_cv_func_lseek=${ac_cv_func_lseek=yes}
+ac_cv_func_lstat=${ac_cv_func_lstat=no}
+ac_cv_func_madvise=${ac_cv_func_madvise=no}
+ac_cv_func_memcpy=${ac_cv_func_memcpy=yes}
+ac_cv_func_memmove=${ac_cv_func_memmove=yes}
+ac_cv_func_memset=${ac_cv_func_memset=yes}
+ac_cv_func_mincore=${ac_cv_func_mincore=no}
+ac_cv_func_mkstemp=${ac_cv_func_mkstemp=yes}
+ac_cv_func_mktime=${ac_cv_func_mktime=yes}
+ac_cv_func_mmap=${ac_cv_func_mmap=no}
+ac_cv_func_mmap_anon=${ac_cv_func_mmap_anon=no}
+ac_cv_func_mmap_dev_zero=${ac_cv_func_mmap_dev_zero=no}
+ac_cv_func_mmap_file=${ac_cv_func_mmap_file=no}
+ac_cv_func_mmap_fixed_mapped=${ac_cv_func_mmap_fixed_mapped=no}
+ac_cv_func_msync=${ac_cv_func_msync=no}
+ac_cv_func_munmap=${ac_cv_func_munmap=no}
+ac_cv_func_open=${ac_cv_func_open=yes}
+ac_cv_func_opendir=${ac_cv_func_opendir=no}
+ac_cv_func_perror=${ac_cv_func_perror=yes}
+ac_cv_func_pipe=${ac_cv_func_pipe=no}
+ac_cv_func_read=${ac_cv_func_read=yes}
+ac_cv_func_readdir=${ac_cv_func_readdir=no}
+ac_cv_func_readdir_r=${ac_cv_func_readdir_r=no}
+ac_cv_func_readlink=${ac_cv_func_readlink=no}
+ac_cv_func_readv=${ac_cv_func_readv=no}
+ac_cv_func_recvfrom=${ac_cv_func_recvfrom=no}
+ac_cv_func_select=${ac_cv_func_select=no}
+ac_cv_func_send=${ac_cv_func_send=no}
+ac_cv_func_sendto=${ac_cv_func_sendto=no}
+ac_cv_func_setmode=${ac_cv_func_setmode=no}
+ac_cv_func_setsockopt=${ac_cv_func_setsockopt=no}
+ac_cv_func_shl_load=${ac_cv_func_shl_load=no}
+ac_cv_func_signal=${ac_cv_func_signal=yes}
+ac_cv_func_sleep=${ac_cv_func_sleep=no}
+ac_cv_func_snprintf=${ac_cv_func_snprintf=yes}
+ac_cv_func_socket=${ac_cv_func_socket=no}
+ac_cv_func_stat=${ac_cv_func_stat=yes}
+ac_cv_func_strcasestr=${ac_cv_func_strcasestr=yes}
+ac_cv_func_strchr=${ac_cv_func_strchr=yes}
+ac_cv_func_strcmp=${ac_cv_func_strcmp=yes}
+ac_cv_func_strerror=${ac_cv_func_strerror=yes}
+ac_cv_func_strerror_r=${ac_cv_func_strerror_r=yes}
+ac_cv_func_strncmp_works=${ac_cv_func_strncmp_works=no}
+ac_cv_func_strrchr=${ac_cv_func_strrchr=yes}
+ac_cv_func_strtof=${ac_cv_func_strtof=yes}
+ac_cv_func_strtold=${ac_cv_func_strtold=no}
+ac_cv_func_symlink=${ac_cv_func_symlink=no}
+ac_cv_func_sysconf=${ac_cv_func_sysconf=no}
+ac_cv_func_time=${ac_cv_func_time=yes}
+ac_cv_func_times=${ac_cv_func_times=yes}
+ac_cv_func_ttyname=${ac_cv_func_ttyname=no}
+ac_cv_func_vsnprintf=${ac_cv_func_vsnprintf=yes}
+ac_cv_func_wait=${ac_cv_func_wait=yes}
+ac_cv_func_which_gethostbyname_r=${ac_cv_func_which_gethostbyname_r=unknown}
+ac_cv_func_write=${ac_cv_func_write=yes}
+ac_cv_func_writev=${ac_cv_func_writev=no}
+ac_cv_lib_c_geteuid=${ac_cv_lib_c_geteuid=no}
+ac_cv_lib_c_getgid=${ac_cv_lib_c_getgid=no}
+ac_cv_lib_c_getpid=${ac_cv_lib_c_getpid=yes}
+ac_cv_lib_c_getppid=${ac_cv_lib_c_getppid=no}
+ac_cv_lib_c_getuid=${ac_cv_lib_c_getuid=no}
+ac_cv_lib_dld_dld_link=${ac_cv_lib_dld_dld_link=no}
+ac_cv_lib_dl_dlopen=${ac_cv_lib_dl_dlopen=no}
+ac_cv_lib_dld_shl_load=${ac_cv_lib_dld_shl_load=no}
+ac_cv_lib_m_acos=${ac_cv_lib_m_acos=yes}
+ac_cv_lib_m_acosf=${ac_cv_lib_m_acosf=yes}
+ac_cv_lib_m_acosh=${ac_cv_lib_m_acosh=yes}
+ac_cv_lib_m_acoshf=${ac_cv_lib_m_acoshf=yes}
+ac_cv_lib_m_acoshl=${ac_cv_lib_m_acoshl=no}
+ac_cv_lib_m_acosl=${ac_cv_lib_m_acosl=no}
+ac_cv_lib_magic_magic_open=${ac_cv_lib_magic_magic_open=no}
+ac_cv_lib_m_asin=${ac_cv_lib_m_asin=yes}
+ac_cv_lib_m_asinf=${ac_cv_lib_m_asinf=yes}
+ac_cv_lib_m_asinh=${ac_cv_lib_m_asinh=yes}
+ac_cv_lib_m_asinhf=${ac_cv_lib_m_asinhf=yes}
+ac_cv_lib_m_asinhl=${ac_cv_lib_m_asinhl=no}
+ac_cv_lib_m_asinl=${ac_cv_lib_m_asinl=no}
+ac_cv_lib_m_atan2=${ac_cv_lib_m_atan2=yes}
+ac_cv_lib_m_atan2f=${ac_cv_lib_m_atan2f=yes}
+ac_cv_lib_m_atan2l=${ac_cv_lib_m_atan2l=no}
+ac_cv_lib_m_atan=${ac_cv_lib_m_atan=yes}
+ac_cv_lib_m_atanf=${ac_cv_lib_m_atanf=yes}
+ac_cv_lib_m_atanh=${ac_cv_lib_m_atanh=yes}
+ac_cv_lib_m_atanhf=${ac_cv_lib_m_atanhf=yes}
+ac_cv_lib_m_atanhl=${ac_cv_lib_m_atanhl=no}
+ac_cv_lib_m_atanl=${ac_cv_lib_m_atanl=no}
+ac_cv_lib_m_cabs=${ac_cv_lib_m_cabs=yes}
+ac_cv_lib_m_cabsf=${ac_cv_lib_m_cabsf=yes}
+ac_cv_lib_m_cabsl=${ac_cv_lib_m_cabsl=no}
+ac_cv_lib_m_carg=${ac_cv_lib_m_carg=no}
+ac_cv_lib_m_cargf=${ac_cv_lib_m_cargf=no}
+ac_cv_lib_m_cargl=${ac_cv_lib_m_cargl=no}
+ac_cv_lib_m_ccos=${ac_cv_lib_m_ccos=no}
+ac_cv_lib_m_ccosf=${ac_cv_lib_m_ccosf=no}
+ac_cv_lib_m_ccosh=${ac_cv_lib_m_ccosh=no}
+ac_cv_lib_m_ccoshf=${ac_cv_lib_m_ccoshf=no}
+ac_cv_lib_m_ccoshl=${ac_cv_lib_m_ccoshl=no}
+ac_cv_lib_m_ccosl=${ac_cv_lib_m_ccosl=no}
+ac_cv_lib_m_ceil=${ac_cv_lib_m_ceil=yes}
+ac_cv_lib_m_ceilf=${ac_cv_lib_m_ceilf=yes}
+ac_cv_lib_m_ceill=${ac_cv_lib_m_ceill=no}
+ac_cv_lib_m_cexp=${ac_cv_lib_m_cexp=no}
+ac_cv_lib_m_cexpf=${ac_cv_lib_m_cexpf=no}
+ac_cv_lib_m_cexpl=${ac_cv_lib_m_cexpl=no}
+ac_cv_lib_m_clog10=${ac_cv_lib_m_clog10=no}
+ac_cv_lib_m_clog10f=${ac_cv_lib_m_clog10f=no}
+ac_cv_lib_m_clog10l=${ac_cv_lib_m_clog10l=no}
+ac_cv_lib_m___clog=${ac_cv_lib_m___clog=no}
+ac_cv_lib_m_clog=${ac_cv_lib_m_clog=no}
+ac_cv_lib_m_clogf=${ac_cv_lib_m_clogf=no}
+ac_cv_lib_m_clogl=${ac_cv_lib_m_clogl=no}
+ac_cv_lib_m_copysign=${ac_cv_lib_m_copysign=yes}
+ac_cv_lib_m_copysignf=${ac_cv_lib_m_copysignf=yes}
+ac_cv_lib_m_copysignl=${ac_cv_lib_m_copysignl=no}
+ac_cv_lib_m_cos=${ac_cv_lib_m_cos=yes}
+ac_cv_lib_m_cosf=${ac_cv_lib_m_cosf=yes}
+ac_cv_lib_m_cosh=${ac_cv_lib_m_cosh=yes}
+ac_cv_lib_m_coshf=${ac_cv_lib_m_coshf=yes}
+ac_cv_lib_m_coshl=${ac_cv_lib_m_coshl=no}
+ac_cv_lib_m_cosl=${ac_cv_lib_m_cosl=no}
+ac_cv_lib_m_cpow=${ac_cv_lib_m_cpow=no}
+ac_cv_lib_m_cpowf=${ac_cv_lib_m_cpowf=no}
+ac_cv_lib_m_cpowl=${ac_cv_lib_m_cpowl=no}
+ac_cv_lib_m_csin=${ac_cv_lib_m_csin=no}
+ac_cv_lib_m_csinf=${ac_cv_lib_m_csinf=no}
+ac_cv_lib_m_csinh=${ac_cv_lib_m_csinh=no}
+ac_cv_lib_m_csinhf=${ac_cv_lib_m_csinhf=no}
+ac_cv_lib_m_csinhl=${ac_cv_lib_m_csinhl=no}
+ac_cv_lib_m_csinl=${ac_cv_lib_m_csinl=no}
+ac_cv_lib_m_csqrt=${ac_cv_lib_m_csqrt=no}
+ac_cv_lib_m_csqrtf=${ac_cv_lib_m_csqrtf=no}
+ac_cv_lib_m_csqrtl=${ac_cv_lib_m_csqrtl=no}
+ac_cv_lib_m_ctan=${ac_cv_lib_m_ctan=no}
+ac_cv_lib_m_ctanf=${ac_cv_lib_m_ctanf=no}
+ac_cv_lib_m_ctanh=${ac_cv_lib_m_ctanh=no}
+ac_cv_lib_m_ctanhf=${ac_cv_lib_m_ctanhf=no}
+ac_cv_lib_m_ctanhl=${ac_cv_lib_m_ctanhl=no}
+ac_cv_lib_m_ctanl=${ac_cv_lib_m_ctanl=no}
+ac_cv_lib_m_erf=${ac_cv_lib_m_erf=yes}
+ac_cv_lib_m_erfc=${ac_cv_lib_m_erfc=yes}
+ac_cv_lib_m_erfcf=${ac_cv_lib_m_erfcf=yes}
+ac_cv_lib_m_erfcl=${ac_cv_lib_m_erfcl=no}
+ac_cv_lib_m_erff=${ac_cv_lib_m_erff=yes}
+ac_cv_lib_m_erfl=${ac_cv_lib_m_erfl=no}
+ac_cv_lib_m_exp=${ac_cv_lib_m_exp=yes}
+ac_cv_lib_m_expf=${ac_cv_lib_m_expf=yes}
+ac_cv_lib_m_expl=${ac_cv_lib_m_expl=no}
+ac_cv_lib_m_fabs=${ac_cv_lib_m_fabs=yes}
+ac_cv_lib_m_fabsf=${ac_cv_lib_m_fabsf=yes}
+ac_cv_lib_m_fabsl=${ac_cv_lib_m_fabsl=no}
+ac_cv_lib_m_feenableexcept=${ac_cv_lib_m_feenableexcept=no}
+ac_cv_lib_m_floor=${ac_cv_lib_m_floor=yes}
+ac_cv_lib_m_floorf=${ac_cv_lib_m_floorf=yes}
+ac_cv_lib_m_floorl=${ac_cv_lib_m_floorl=no}
+ac_cv_lib_m_fmod=${ac_cv_lib_m_fmod=yes}
+ac_cv_lib_m_fmodf=${ac_cv_lib_m_fmodf=yes}
+ac_cv_lib_m_fmodl=${ac_cv_lib_m_fmodl=no}
+ac_cv_lib_m_frexp=${ac_cv_lib_m_frexp=yes}
+ac_cv_lib_m_frexpf=${ac_cv_lib_m_frexpf=yes}
+ac_cv_lib_m_frexpl=${ac_cv_lib_m_frexpl=no}
+ac_cv_lib_m_hypot=${ac_cv_lib_m_hypot=yes}
+ac_cv_lib_m_hypotf=${ac_cv_lib_m_hypotf=yes}
+ac_cv_lib_m_hypotl=${ac_cv_lib_m_hypotl=no}
+ac_cv_lib_m_j0=${ac_cv_lib_m_j0=yes}
+ac_cv_lib_m_j0f=${ac_cv_lib_m_j0f=yes}
+ac_cv_lib_m_j0l=${ac_cv_lib_m_j0l=no}
+ac_cv_lib_m_j1=${ac_cv_lib_m_j1=yes}
+ac_cv_lib_m_j1f=${ac_cv_lib_m_j1f=yes}
+ac_cv_lib_m_j1l=${ac_cv_lib_m_j1l=no}
+ac_cv_lib_m_jn=${ac_cv_lib_m_jn=yes}
+ac_cv_lib_m_jnf=${ac_cv_lib_m_jnf=yes}
+ac_cv_lib_m_jnl=${ac_cv_lib_m_jnl=no}
+ac_cv_lib_m_ldexp=${ac_cv_lib_m_ldexp=yes}
+ac_cv_lib_m_ldexpf=${ac_cv_lib_m_ldexpf=yes}
+ac_cv_lib_m_ldexpl=${ac_cv_lib_m_ldexpl=no}
+ac_cv_lib_m_lgamma=${ac_cv_lib_m_lgamma=yes}
+ac_cv_lib_m_lgammaf=${ac_cv_lib_m_lgammaf=yes}
+ac_cv_lib_m_lgammal=${ac_cv_lib_m_lgammal=no}
+ac_cv_lib_m_llround=${ac_cv_lib_m_llround=no}
+ac_cv_lib_m_llroundf=${ac_cv_lib_m_llroundf=no}
+ac_cv_lib_m_llroundl=${ac_cv_lib_m_llroundl=no}
+ac_cv_lib_m_log10=${ac_cv_lib_m_log10=yes}
+ac_cv_lib_m_log10f=${ac_cv_lib_m_log10f=yes}
+ac_cv_lib_m_log10l=${ac_cv_lib_m_log10l=no}
+ac_cv_lib_m_log=${ac_cv_lib_m_log=yes}
+ac_cv_lib_m_logf=${ac_cv_lib_m_logf=yes}
+ac_cv_lib_m_logl=${ac_cv_lib_m_logl=no}
+ac_cv_lib_m_lround=${ac_cv_lib_m_lround=yes}
+ac_cv_lib_m_lroundf=${ac_cv_lib_m_lroundf=yes}
+ac_cv_lib_m_lroundl=${ac_cv_lib_m_lroundl=no}
+ac_cv_lib_m_nextafter=${ac_cv_lib_m_nextafter=yes}
+ac_cv_lib_m_nextafterf=${ac_cv_lib_m_nextafterf=yes}
+ac_cv_lib_m_nextafterl=${ac_cv_lib_m_nextafterl=no}
+ac_cv_lib_m_pow=${ac_cv_lib_m_pow=yes}
+ac_cv_lib_m_powf=${ac_cv_lib_m_powf=yes}
+ac_cv_lib_m_powl=${ac_cv_lib_m_powl=no}
+ac_cv_lib_m_round=${ac_cv_lib_m_round=yes}
+ac_cv_lib_m_roundf=${ac_cv_lib_m_roundf=yes}
+ac_cv_lib_m_roundl=${ac_cv_lib_m_roundl=no}
+ac_cv_lib_m_scalbn=${ac_cv_lib_m_scalbn=yes}
+ac_cv_lib_m_scalbnf=${ac_cv_lib_m_scalbnf=yes}
+ac_cv_lib_m_scalbnl=${ac_cv_lib_m_scalbnl=no}
+ac_cv_lib_m_sin=${ac_cv_lib_m_sin=yes}
+ac_cv_lib_m_sinf=${ac_cv_lib_m_sinf=yes}
+ac_cv_lib_m_sinh=${ac_cv_lib_m_sinh=yes}
+ac_cv_lib_m_sinhf=${ac_cv_lib_m_sinhf=yes}
+ac_cv_lib_m_sinhl=${ac_cv_lib_m_sinhl=no}
+ac_cv_lib_m_sinl=${ac_cv_lib_m_sinl=no}
+ac_cv_lib_m_sqrt=${ac_cv_lib_m_sqrt=yes}
+ac_cv_lib_m_sqrtf=${ac_cv_lib_m_sqrtf=yes}
+ac_cv_lib_m_sqrtl=${ac_cv_lib_m_sqrtl=no}
+ac_cv_lib_m_tan=${ac_cv_lib_m_tan=yes}
+ac_cv_lib_m_tanf=${ac_cv_lib_m_tanf=yes}
+ac_cv_lib_m_tanh=${ac_cv_lib_m_tanh=yes}
+ac_cv_lib_m_tanhf=${ac_cv_lib_m_tanhf=yes}
+ac_cv_lib_m_tanhl=${ac_cv_lib_m_tanhl=no}
+ac_cv_lib_m_tanl=${ac_cv_lib_m_tanl=no}
+ac_cv_lib_m_tgamma=${ac_cv_lib_m_tgamma=yes}
+ac_cv_lib_m_tgammaf=${ac_cv_lib_m_tgammaf=yes}
+ac_cv_lib_m_tgammal=${ac_cv_lib_m_tgammal=no}
+ac_cv_lib_m_trunc=${ac_cv_lib_m_trunc=yes}
+ac_cv_lib_m_truncf=${ac_cv_lib_m_truncf=yes}
+ac_cv_lib_m_truncl=${ac_cv_lib_m_truncl=no}
+ac_cv_lib_m_y0=${ac_cv_lib_m_y0=yes}
+ac_cv_lib_m_y0f=${ac_cv_lib_m_y0f=yes}
+ac_cv_lib_m_y0l=${ac_cv_lib_m_y0l=no}
+ac_cv_lib_m_y1=${ac_cv_lib_m_y1=yes}
+ac_cv_lib_m_y1f=${ac_cv_lib_m_y1f=yes}
+ac_cv_lib_m_y1l=${ac_cv_lib_m_y1l=no}
+ac_cv_lib_m_yn=${ac_cv_lib_m_yn=yes}
+ac_cv_lib_m_ynf=${ac_cv_lib_m_ynf=yes}
+ac_cv_lib_m_ynl=${ac_cv_lib_m_ynl=no}
+ac_cv_lib_svld_dlopen=${ac_cv_lib_svld_dlopen=no}
+have_attribute_alias=${have_attribute_alias=yes}
+have_fpsetmask=${have_fpsetmask=no}
+have_mingw_snprintf=${have_mingw_snprintf=no}
+have_sync_fetch_and_add=${have_sync_fetch_and_add=no}

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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++-v3 with unmodified
> libstdc++-v3/configure.ac. Libgfortran's configure.ac needs just the symbol
> versioning patch ported from libssp. And that's it!

This trick seems plausible to me.  Certainly, if it works, it would
simplify development of configure scripts for run-time libraries.

My only concern with this approach is that Newlib might not be entirely
consistent across configurations and architectures.  The libstdc++
approach presumably entails some manual verification of each function's
presence or absence; before we claim that "Newlib has foo" someone
verifies that.  I don't know if this is a problem in practice.

For example, these lines seem like things that might vary.

> +have_fpsetmask=${have_fpsetmask=no}
...
> +have_sync_fetch_and_add=${have_sync_fetch_and_add=no}

I suppose we could solve that problem, if it arises, with different
config.cache files for different targets.  Perhaps it would be best to
generalize this by adding a top-level --with-target-lib-cache= option,
and then, if that's not present, and $with_newlib is set, passing in the
Newlib cache that you have?

That would give people a way to say that for their particular RTOS
and/or C library the following functions are available.

In theory, at least, we might also have differences between multilibs.
It Would Be Nice to be moving GCC in the direction of allowing different
multilibs for different operating systems and/or C libraries.  So, I
suppose the all-singing, all-dancing version of this would be some
option that allows you to specify a cache file per multilib.  But, I
think that could be left for later.

What do you and others think?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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)
>  AC_SUBST(INSTALL_GDB_TK)
> +AC_SUBST(with_newlib)
>  
>  # Build module lists & subconfigure args.
>  AC_SUBST(build_configargs)

   That hunk is corrupt, it should look like this:

Index: configure.ac
===================================================================
--- configure.ac	(revision 130442)
+++ configure.ac	(working copy)
@@ -2435,6 +2435,7 @@
 AC_SUBST(CONFIGURE_GDB_TK)
 AC_SUBST(GDB_TK)
 AC_SUBST(INSTALL_GDB_TK)
+AC_SUBST(with_newlib)
 
 # Build module lists & subconfigure args.
 AC_SUBST(build_configargs)

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> 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:
>
>      Enable checking for dlopen support. This macro should be used if
>      the package makes use of the `-dlopen' and `-dlpreopen' flags,
>      otherwise libtool will assume that the system does not support
>      dlopening.  The macro must be called *before* `AC_PROG_LIBTOOL'.
>
> But, for a bare-metal toolchain, I don't think we need that.  So, I'm
> guessing that:
>
>   if test "x${with_newlib}" != "xyes"; then
>     AC_LIBTOOL_DLOPEN
>   fi
>
> will fix the problem.  (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)

I built a version of binutils that treated an undefined _start as
a hard error.  (I also had another local binutils patch to fix an
unrelated .eh_frame_hdr problem.)  Reverting the libgloss change
and applying the change above introduced no regressions.

Applying this patch would revert to the previous situation of
libgfortran being unbuildable for mips*-elf*.  That's not a regression
from previous releases, and I'm not sure how useful the status quo is.
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 sounds like we've agreed that, if we want
to support libgfortran on targets like mips*-elf*, we should use
libstd++-like with_newlib checks there too.

Perhaps we should turn target-libgfortran off by default for mips*-elf*.
I'll work on a patch to do that if this one is OK.

Richard


	Revert:

	2007-09-10  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	PR other/32154
	* configure.ac: For libgloss targets, point the linker to the linker
	script, startup code and simulator library.
	* configure: Regenerate.

libstdc++-v3/
2007-xx-xx  Mark Mitchell  <mark@codesourcery.com>

	* configure.ac: Don't check AC_LIBTOOL_DLOPEN if using newlib.
	* configure: Regenerate.

Index: configure.ac
===================================================================
--- configure.ac	(revision 130491)
+++ configure.ac	(working copy)
@@ -399,9 +399,6 @@ if test x$enable_libgomp = x ; then
     esac
 fi
 
-# Default libgloss CPU subdirectory.
-libgloss_dir="$target_cpu"
-
 case "${target}" in
   *-*-chorusos)
     noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}"
@@ -507,7 +504,6 @@ case "${target}" in
       *) noconfigdirs="$noconfigdirs gdb readline"
 	 ;;
     esac
-    libgloss_dir=wince
     ;;
   arc-*-*)
     noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
@@ -516,11 +512,9 @@ case "${target}" in
     ;;
   arm-*-coff | strongarm-*-coff | xscale-*-coff)
     noconfigdirs="$noconfigdirs ${libgcj}"
-    libgloss_dir=arm
     ;;
   arm-*-elf* | strongarm-*-elf* | xscale-*-elf* | arm*-*-eabi* )
     noconfigdirs="$noconfigdirs target-libffi target-qthreads"
-    libgloss_dir=arm
     ;;
   arm*-*-linux-gnueabi)
     noconfigdirs="$noconfigdirs target-qthreads"
@@ -528,11 +522,9 @@ case "${target}" in
     case ${with_newlib} in
       no) noconfigdirs="$noconfigdirs target-newlib target-libgloss"
     esac
-    libgloss_dir=arm
     ;;
   arm*-*-symbianelf*)
     noconfigdirs="$noconfigdirs ${libgcj} target-libiberty"
-    libgloss_dir=arm
     ;;
   arm-*-pe*)
     noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
@@ -579,7 +571,6 @@ case "${target}" in
 	unsupported_languages="$unsupported_languages fortran"
 	noconfigdirs="$noconfigdirs ${libgcj} target-newlib target-libgloss";;
     esac
-    libgloss_dir=cris
     ;;
   crx-*-*)
     noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap ${libgcj}"
@@ -590,9 +581,6 @@ case "${target}" in
   d30v-*-*)
     noconfigdirs="$noconfigdirs ${libgcj} gdb"
     ;;
-  ep9312-*-elf | ep9312-*-coff)
-    libgloss_dir=arm
-    ;;
   fr30-*-elf*)
     noconfigdirs="$noconfigdirs ${libgcj} gdb"
     ;;
@@ -624,9 +612,6 @@ case "${target}" in
   hppa*-hp-hpux11*)
     noconfigdirs="$noconfigdirs ld shellutils"
     ;;
-  hppa*-*-pro*)
-    libgloss_dir=pa
-    ;;
   hppa*-*-*)
     # According to Alexandre Oliva <aoliva@redhat.com>, libjava won't
     # build on HP-UX 10.20.
@@ -647,7 +632,6 @@ case "${target}" in
     ;;
   i[[3456789]]86-*-coff | i[[3456789]]86-*-elf)
     noconfigdirs="$noconfigdirs ${libgcj}"
-    libgloss_dir=i386
     ;;
   i[[3456789]]86-*-linux*)
     # The GCC port for glibc1 has no MD_FALLBACK_FRAME_STATE_FOR, so let's
@@ -717,7 +701,6 @@ case "${target}" in
     ;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
     noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 ${libgcj}"
-    libgloss_dir=m68hc11
     ;;
   m68k-*-elf*)
     noconfigdirs="$noconfigdirs ${libgcj}"
@@ -725,9 +708,6 @@ case "${target}" in
   m68k-*-coff*)
     noconfigdirs="$noconfigdirs ${libgcj}"
     ;;
-  m68*-*-* | fido-*-*)
-    libgloss_dir=m68k
-    ;;
   mcore-*-pe*)
   # The EPOC C++ environment does not support exceptions or rtti,
   # and so building libstdc++-v3 tends not to always work.
@@ -759,17 +739,14 @@ case "${target}" in
     # This is temporary until we can link against shared libraries
   powerpcle-*-solaris*)
     noconfigdirs="$noconfigdirs gdb sim make tcl tk expect itcl gnuserv ${libgcj}"
-    libgloss_dir=rs6000
     ;;
   powerpc-*-beos*)
     noconfigdirs="$noconfigdirs gdb target-newlib target-libgloss ${libgcj}"
     ;;
   powerpc-*-eabi)
     noconfigdirs="$noconfigdirs ${libgcj}"
-    libgloss_dir=rs6000
     ;;
   powerpc-*-eabi* | powerpcle-*-eabi* | powerpc-*-rtems* )
-    libgloss_dir=rs6000
     ;;
   rs6000-*-lynxos*)
     noconfigdirs="$noconfigdirs target-newlib gprof ${libgcj}"
@@ -809,7 +786,6 @@ case "${target}" in
     ;;
   mips*-*-*)
     noconfigdirs="$noconfigdirs gprof ${libgcj}"
-    libgloss_dir=mips
     ;;
   romp-*-*)
     noconfigdirs="$noconfigdirs bfd binutils ld gas opcodes target-libgloss ${libgcj}"
@@ -823,19 +799,14 @@ case "${target}" in
     esac
     noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
     ;;
-  sparclet-*-aout* | sparc86x-*-*)
-    libgloss_dir=sparc
-    ;;
   sparc-*-elf*)
     noconfigdirs="$noconfigdirs ${libgcj}"
     ;;
   sparc64-*-elf*)
     noconfigdirs="$noconfigdirs ${libgcj}"
-    libgloss_dir=sparc
     ;;
   sparclite-*-*)
     noconfigdirs="$noconfigdirs ${libgcj}"
-    libgloss_dir=sparc
     ;;
   sparc-*-sunos4*)
     noconfigdirs="$noconfigdirs ${libgcj}"
@@ -2360,19 +2331,6 @@ case " $target_configdirs " in
       # for any libc-related directories first (so make it the last -B
       # switch).
       FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/newlib/ -isystem $$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem $$s/newlib/libc/include'
-
-      # If we're building libgloss, find the startup file, simulator library
-      # and linker script.
-      case " $target_configdirs " in
-	*" libgloss "*)
-	# Look for startup file, simulator library and maybe linker script.
-	FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/libgloss/'"$libgloss_dir"
-	# Look for libnosys.a in case the target needs it.
-	FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys'
-	# Most targets have the linker script in the source directory.
-	FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$s/libgloss/'"$libgloss_dir"
-	;;
-      esac
       ;;
    esac
    ;;
@@ -2410,6 +2368,16 @@ fi
 
 # Search for other target-specific linker scripts and such.
 case "${target}" in
+  m32c-*-* )
+    if test -d ${srcdir}/libgloss/m32c; then
+      # This is for crt0.o
+      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/libgloss/m32c'
+      # This is for r8c.ld
+      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/m32c'
+      # This is for libnosys.a
+      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys'
+    fi
+    ;;
   mep*)
     FLAGS_FOR_TARGET="$FLAGS_FOR_TARGET -mlibrary"
     ;;
Index: libstdc++-v3/configure.ac
===================================================================
--- libstdc++-v3/configure.ac	(revision 130491)
+++ libstdc++-v3/configure.ac	(working copy)
@@ -82,7 +82,9 @@ AH_TEMPLATE(VERSION, [Version number of 
 # up critical shell variables.
 GLIBCXX_CONFIGURE
 
-AC_LIBTOOL_DLOPEN
+if test "x${with_newlib}" != "xyes"; then
+  AC_LIBTOOL_DLOPEN
+fi
 AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 change
> and applying the change above introduced no regressions.

Thank you for working on this.

> Perhaps we should turn target-libgfortran off by default for mips*-elf*.

I think that is the right thing to do.  If we want Fortran to work on
bare-metal targets, then we should make it's configure script work like
the libstdc++ one, as you say.

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.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> 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

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Thu, Nov 29, 2007 at 10:05:54PM +0000, 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-unknown-elf:
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01428.html
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01468.html
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00427.html

   Some work has been and is being done in this area:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

   Hans, you showed gfortran results for cris-elf, but we don't seem to be
building gfortran for the cris?

> It sounds like we've agreed that, if we want
> to support libgfortran on targets like mips*-elf*, we should use
> libstd++-like with_newlib checks there too.

   Likewise for the other target libraries - how many did you test?

   I tried a build of sparc-unknown-elf (which is know to fail link tests)
with "with_newlib" checks around the AC_LIBTOOL_DLOPEN macro in both
libstdc++ and libgfortran. It fails because:

configure:3391: checking whether symbol versioning is supported
configure:3402: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

With this patch I get marginally further:

Index: libgfortran/configure.ac
===================================================================
--- libgfortran/configure.ac    (revision 130442)
+++ libgfortran/configure.ac    (working copy)
@@ -142,12 +142,14 @@
   global: *foo*; bar; local: *;
 };
 EOF
-save_LDFLAGS="$LDFLAGS"
-LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
-AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
-LDFLAGS="$save_LDFLAGS"
-AC_MSG_RESULT($gfortran_use_symver)
-AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
+if test "x${with_newlib}" != "xyes"; then
+  save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
+  AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+  LDFLAGS="$save_LDFLAGS"
+  AC_MSG_RESULT($gfortran_use_symver)
+  AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
+fi

 # Find other programs we need.
 AC_CHECK_TOOL(AS, as)
@@ -158,7 +160,9 @@

 # Configure libtool
 #AC_MSG_NOTICE([====== Starting libtool configuration])
-AC_LIBTOOL_DLOPEN
+if test "x${with_newlib}" != "xyes"; then
+  AC_LIBTOOL_DLOPEN
+fi
 AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)

configure:18061: checking for getrusage
configure:18067: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

> 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.

> @@ -2410,6 +2368,16 @@ fi
>  
>  # Search for other target-specific linker scripts and such.
>  case "${target}" in
> +  m32c-*-* )
> +    if test -d ${srcdir}/libgloss/m32c; then
> +      # This is for crt0.o
> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/libgloss/m32c'
> +      # This is for r8c.ld
> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/m32c'
> +      # This is for libnosys.a
> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys'
> +    fi
> +    ;;
>    mep*)
>      FLAGS_FOR_TARGET="$FLAGS_FOR_TARGET -mlibrary"
>      ;;

   This hunk should be left out. And I would prefer that we don't revert the
patch until everything that builds with the patch also builds without the
patch.

   Additionally, I would prefer we call the option something else than
--with-newlib - suppose there's no newlib for the target. At least the AVR
uses something else.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 and its libraries, testing is of incidental
benefit; the primary goal is to build things. :-) The testsuite is for
testing things.

It's great to know that gfortran works for other ELF targets.  That
means that there must be something a bit odd in the MIPS support
somewhere, and I'm sure we can find it and fix it.

Thanks for working on the gfortran configure script.  I think it would
be great to make that work like the libstdc++ script.

>    This hunk should be left out. And I would prefer that we don't revert the
> patch until everything that builds with the patch also builds without the
> patch.

I don't think that's necessary -- unless these things built with
previous releases, in which case I'd be very concerned about making a
change that caused fewer things to build.  Did this work in 4.2?  I
don't know, but I'm expecting that it did not?

It sounds like we upgraded libtool, and that introduced link-time tests
into libstdc++, which caused build failures.  So you came up with the
top-level patch, which then probably made it possible to build some of
the other target libraries that didn't build before for bare metal
because they had always depended on link-time tests.  Is that correct?

We should be conservative about making changes in assumptions.  If we're
going to change the assumption that target library configure scripts
cannot rely on link-time tests when $with_newlib is set, then let's do
that consciously.  I think it's reasonable to take that position (even
though it's not my preference), but I don't want to change the
assumption quietly.  And, I think libstdc++ is our canonical model of a
run-time library; others should follow its lead, until/unless we
consciously decide otherwise.

I also don't want to see each architecture or run-time library doing
things in different ways.  GCC's biggest strength is its cross-platform
nature; we undermine that every time we do things in slightly different
ways within our own individual areas of concentration.

I'm in no way criticizing you or your top-level patch.  I understand
completely why you did what you did and its benefits.  But, I want to
get everyone on the same page, and until that happens, I want to stick
with how things have been in the past.

>    Additionally, I would prefer we call the option something else than
> --with-newlib - suppose there's no newlib for the target. At least the AVR
> uses something else.

That might be a good idea -- I think we do need to know which C library
is in use for at least some of the target libraries.  I'm pretty sure
that libstdc++ actually depends on --with-newlib meaning that you're
using Newlib (rather than some other C library) in that it uses
facilities in Newlib that aren't necessarily part of a standard C
library.  I could be wrong about that, though.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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 the compiler until you try to compile something.
> 
> When building the compiler and its libraries, testing is of incidental
> benefit; the primary goal is to build things. :-)   The testsuite is for
> testing things.

   The benefit is the same, incidental or not. We have the testsuite as a
result of someone trying to build something with the compiler and not being
satisfied with the result. Alternatively, think of libfortran as a testsuite
in itself. :-)

> It's great to know that gfortran works for other ELF targets.  That
> means that there must be something a bit odd in the MIPS support
> somewhere, and I'm sure we can find it and fix it.

   I think so too. IIRC, of the *-elf targets that don't currently work with
libfortran, one runs into a memory access trap and the others have a link
failures due to a missing symbol.
 
> It sounds like we upgraded libtool, and that introduced link-time tests
> into libstdc++, which caused build failures.  So you came up with the
> top-level patch, which then probably made it possible to build some of
> the other target libraries that didn't build before for bare metal
> because they had always depended on link-time tests.  Is that correct?

   No, the problem with GCC_NO_EXECUTABLES failures predates the libtool
upgrade and I don't recall any problems related to the libtool upgrade. The
timeline:

2003-08-21: PR 12019 opened: libstdc++ GCC_NO_EXECUTABLES failure.
2006-04-18: DJ Delorie adds -L and -B options for the m32c due to libssp
	    failing to build with GCC_NO_EXECUTABLES problems. The patch
	    also enables libstdc++ on the m32c.
2006-09-29: Joseph S. Myers fixes libssp/configure.ac.
2007-01-??: I duplicate DJ Delorie's -L/-B options for the powerpc.
2007-05-24: Libtool is upgraded with revision 125032, 16:37:27.
2007-05-30: I open PR 32154, early patch against revision 125037, 19:19:31.
2007-09-10: PR 32154 (and PR 12019) fixed.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Rask Ingemann Lambertsen <rask@sygehus.dk> writes:
> On Thu, Nov 29, 2007 at 10:05:54PM +0000, 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-unknown-elf:
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01428.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01468.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00427.html
>
>    Some work has been and is being done in this area:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
>
>    Hans, you showed gfortran results for cris-elf, but we don't seem to be
> building gfortran for the cris?
>
>> It sounds like we've agreed that, if we want
>> to support libgfortran on targets like mips*-elf*, we should use
>> libstd++-like with_newlib checks there too.
>
>    Likewise for the other target libraries - how many did you test?

C, C++ and Objective C.  Libjava isn't supported before or after
the patch for mips*-elf*.  Which other libraries were you thinking of?

>    I tried a build of sparc-unknown-elf (which is know to fail link tests)
> with "with_newlib" checks around the AC_LIBTOOL_DLOPEN macro in both
> libstdc++ and libgfortran. It fails because:
>
> configure:3391: checking whether symbol versioning is supported
> configure:3402: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
>
> With this patch I get marginally further:

Yeah, as it happens, I'd got a similar patch too.  As the comment says,
the test is taken from libssp, which was later adjusted to handle
$with_newlib correctly:

--------------------------------------------------------------------------
AC_MSG_CHECKING([whether symbol versioning is supported])
cat > conftest.map <<EOF
FOO_1.0 {
  global: *foo*; bar; local: *;
};
EOF
save_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
if test x$gcc_no_link = xyes; then
  # If we cannot link, we cannot build shared libraries, so do not use
  # symbol versioning.
  ssp_use_symver=no
else
  AC_TRY_LINK([int foo;],[],[ssp_use_symver=yes],[ssp_use_symver=no])
fi
LDFLAGS="$save_LDFLAGS"
AC_MSG_RESULT($ssp_use_symver)
AM_CONDITIONAL(LIBSSP_USE_SYMVER, [test "x$ssp_use_symver" = xyes])
--------------------------------------------------------------------------

So my patch simply copied the new test across to libgfortran, although the
outcome is obviously the same either way.

However, I then realised that it was only the beginning.  We have lots
of AC_CHECK_FUNCS and AC_CHECK_LIB tests, which we would need to handle
in the same way as for libstdc++-v3.  A useful project, but probably too
dangerous for 4.3.

>> @@ -2410,6 +2368,16 @@ fi
>>  
>>  # Search for other target-specific linker scripts and such.
>>  case "${target}" in
>> +  m32c-*-* )
>> +    if test -d ${srcdir}/libgloss/m32c; then
>> +      # This is for crt0.o
>> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/libgloss/m32c'
>> +      # This is for r8c.ld
>> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/m32c'
>> +      # This is for libnosys.a
>> +      FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys'
>> +    fi
>> +    ;;
>>    mep*)
>>      FLAGS_FOR_TARGET="$FLAGS_FOR_TARGET -mlibrary"
>>      ;;
>
>    This hunk should be left out.

I was thinking I should return it to the pre-patch situation, as I wasn't
comfortable overriding a decision made by the m32c maintainer.  That said,
the changelog says:

2006-04-18  DJ Delorie  <dj@redhat.com>

	* configure.in (m32c): Build libstdc++-v3.  Pass flags to
	reference libgloss so that libssp can be built in a combined
	tree.
	* configure: Regenerate.

and libssp was later made newlib-friendly by (at least):

2006-09-29  Joseph S. Myers  <joseph@codesourcery.com>

	PR other/25035
	* configure.ac (AC_EXEEXT): Remove.
	(GCC_NO_EXECUTABLES): Call.
	(ssp_use_symver): Default to no if unable to link.
	(AC_CHECK_FUNCS): Hardwire results if unable to link.
	* aclocal.m4, configure, Makefile.in: Regenerate.

Mark, DJ?  Do you agree it's OK to drop that hunk?

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Fri, Nov 30, 2007 at 08:44:59AM +0000, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <rask@sygehus.dk> writes:
> > On Thu, Nov 29, 2007 at 10:05:54PM +0000, Richard Sandiford wrote:
> >> It sounds like we've agreed that, if we want
> >> to support libgfortran on targets like mips*-elf*, we should use
> >> libstd++-like with_newlib checks there too.
> >
> >    Likewise for the other target libraries - how many did you test?
> 
> C, C++ and Objective C.  Libjava isn't supported before or after
> the patch for mips*-elf*.  Which other libraries were you thinking of?

   Libjava, libssp and libffi, of which libssp has already been taken care
of.

   I checked my build directories and it looks like we only build libjava on
the ARM and there, it doesn't quite build yet, but that is work in (slow)
progress:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
http://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340

   The only target I know of that builds libffi is ia64-unknown-elf, but
expect arm-unknown-{eabi,elf} to follow. Checking ia64's libffi/config.log,
I spotted three link tests (for mmap, memcpy and alloca).

> I was thinking I should return it to the pre-patch situation, as I wasn't
> comfortable overriding a decision made by the m32c maintainer.  That said,
> the changelog says:
> 
> 2006-04-18  DJ Delorie  <dj@redhat.com>
> 
> 	* configure.in (m32c): Build libstdc++-v3.  Pass flags to
> 	reference libgloss so that libssp can be built in a combined
> 	tree.
> 	* configure: Regenerate.
> 
> and libssp was later made newlib-friendly by (at least):

   And we don't build libjava or libffi on the m32c. That leaves libgfortran
which doesn't build due to PR 32055. So although that hunk did make it into
the 4.2 branch, there's no loss on the m32c.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Richard Sandiford wrote:

> 2006-04-18  DJ Delorie  <dj@redhat.com>
> 
> 	* 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 that hunk?

I'm not quite sure if you're asking for agreement to leave it in our
sourcebase, or to remove it therefrom, so, unambiguously:

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.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[DJ Delorie]

> 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.

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>> 2006-04-18  DJ Delorie  <dj@redhat.com>
>> 
>> 	* 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 that hunk?
>
> I'm not quite sure if you're asking for agreement to leave it in our
> sourcebase, or to remove it therefrom, so, unambiguously:

Yeah, sorry about that.  And...

> 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 was indeed asking whether I could remove that hunk from the source,
rather than restoring it to its original position.

Anyway, given that there have been objections to the patch generally,
I realise that the pre-approval is void.

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

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 we decide to change the overall strategy, then we
can do that all at once.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> 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 the libstdc++ configury more
> self-consistent; if we decide to change the overall strategy, then we
> can do that all at once.

Well, Rask's patch would make the libstdc++ change unnecessary,
so it seems premature to change libstdc++ now.  (Not that I'm objecting
to anyone else doing it.  I'm just not comfortable doing it myself,
especially since, on its own, it doesn't affect any of "my" targets.)

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Fri, Nov 30, 2007 at 03:21:32AM +0100, Rask Ingemann Lambertsen wrote:
> On Thu, Nov 29, 2007 at 10:05:54PM +0000, 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-unknown-elf:
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01428.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01468.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00427.html
> 
>    Some work has been and is being done in this area:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
> 
>    Hans, you showed gfortran results for cris-elf, but we don't seem to be
> building gfortran for the cris?

   A one-liner for cris-axis-elf does the trick:

Index: configure.ac
===================================================================
--- configure.ac        (revision 130442)
+++ configure.ac        (working copy)
@@ -571,7 +571,6 @@
        unsupported_languages="$unsupported_languages fortran"
        noconfigdirs="$noconfigdirs target-libffi target-boehm-gc";;
       *-*-elf)
-       unsupported_languages="$unsupported_languages fortran"
        noconfigdirs="$noconfigdirs target-boehm-gc";;
       *-*-linux*)
        noconfigdirs="$noconfigdirs target-newlib target-libgloss";;

                === gfortran Summary ===

# of expected passes            21543
# of unexpected failures        235
# of expected failures          6
# of unresolved testcases       48
# of unsupported tests          116

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Mon, Dec 03, 2007 at 04:07:35PM +0000, 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
> I hadn't even realised it was _supposed_ to work now.  I'll have a prod.

mips-core: 1 byte read to unmapped address 0x0 at 0xffffffff80021468
program stopped with signal 10.

There are 8456 such messages at slightly different addresses out of a total
of 8488 failures. And generally, on the targets with problems, the problems
seem to be in the simulation part (dejagnu, the simulator itself or the
linker script) rather than in GCC. For example, the special linker script
used for SPARC testing needs to be updated to handle .e.g. .rodata.*
sections so they don't collide with the .bss section.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Thu, Nov 29, 2007 at 10:05:54PM +0000, Richard Sandiford wrote:
> libstdc++-v3/
> 2007-xx-xx  Mark Mitchell  <mark@codesourcery.com>
> 
> 	* configure.ac: Don't check AC_LIBTOOL_DLOPEN if using newlib.
> 	* configure: Regenerate.
> 
> Index: libstdc++-v3/configure.ac
> ===================================================================
> --- libstdc++-v3/configure.ac	(revision 130491)
> +++ libstdc++-v3/configure.ac	(working copy)
> @@ -82,7 +82,9 @@ AH_TEMPLATE(VERSION, [Version number of 
>  # up critical shell variables.
>  GLIBCXX_CONFIGURE
>  
> -AC_LIBTOOL_DLOPEN
> +if test "x${with_newlib}" != "xyes"; then
> +  AC_LIBTOOL_DLOPEN
> +fi
>  AM_PROG_LIBTOOL
>  AC_SUBST(enable_shared)
>  AC_SUBST(enable_static)

   This bit is fine with me as it clearly improves the situation. For
example, it is now possible to build and test sparc-unknown-elf with fortran
disabled (--enable-languages=c,c++,objc,obj-c++,java) which is an
improvement over the current situation.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

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
> worked since what is now "-msim" was default behaviour, but it started
> to fail the libstdc++ configury once Jie changed that to use
> target-specific linker scripts.

When you are building a compiler to bootstrap libc, with a view to 
building a later full toolchain using that libc, the bootstrap compiler 
should be C-only (and have most of the other runtime libraries apart from 
libgcc disabled), so you only build libstdc++ after you have a libc.

The only exception would be if your libc contains C++ code and depends on 
libstdc++ - I think this has been mentioned as an issue for Cygwin.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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 file or directory

$ grep -F -e bf532.ld gcc/config/bfin/*
gcc/config/bfin/elf.h:%{!T*:%{!msim:%{mcpu=bf531:-Tbf531.ld}%{mcpu=bf532:-Tbf532.ld} \
gcc/config/bfin/elf.h:        %{!mcpu=*:-Tbf532.ld}}}"

The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 linker script file bf532.ld: No such file or directory
> 
> $ grep -F -e bf532.ld gcc/config/bfin/*
> gcc/config/bfin/elf.h:%{!T*:%{!msim:%{mcpu=bf531:-Tbf531.ld}%{mcpu=bf532:-Tbf532.ld} \
> gcc/config/bfin/elf.h:        %{!mcpu=*:-Tbf532.ld}}}"
> 
> 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/libgloss from

http://blackfin.uclinux.org/gf/project/toolchain/scmsvn

But if it cannot find bf532.ld, it should avoid further link tests.


Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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/libgloss from
> 
> http://blackfin.uclinux.org/gf/project/toolchain/scmsvn

   Thanks. With that, I instead get:

/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
crt532.o: No such file: No such file or directory

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

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/libgloss changes to upstream 
> > yet. Currently you could get latest blackfin port newlib/libgloss from
> > 
> > http://blackfin.uclinux.org/gf/project/toolchain/scmsvn
> 
>    Thanks. With that, I instead get:
> 
> /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 but there's no (obvious) clue as to why in config.log. If
I run make again, it begins to build libstdc++ but fails with this:

Making all in libsupc++
make[4]: Entering directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++'
/bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc -shared-libgcc -B/home/rask/build/gcc-bfin-unknown-elf/./gcc -nostdinc++ -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src/.libs -nostdinc -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem /home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include -isystem /n/12/rask/src/all/newlib/libc/include -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/bfin -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/libnosys -L/n/12/rask/src/all/libgloss/bfin -B/usr/local/bfin-unknown-elf/bin/ -B/usr/local/bfin-unknown-elf/lib/ -isystem /usr/local/bfin-unknown-elf/include -isystem /usr/local/bfin-unknown-elf/sys-include -L/home/rask/build/gcc-bfin-unknown-elf/./ld -I/n/12/rask/src/all/libstdc++-v3/../gcc -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include/bfin-unknown-elf -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include -I/n/12/rask/src/all/libstdc++-v3/libsupc++  -fno-implicit-templates  -Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections  -g -O2    -c -o array_type_info.lo /n/12/rask/src/all/libstdc++-v3/libsupc++/array_type_info.cc
/bin/sh: ../libtool: No such file or directory
make[4]: *** [array_type_info.lo] Error 127
make[4]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf'
make: *** [all] Error 2

I don't know why this happens to bfin and not to the other newlib targets.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

[Jie Zhang]

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 but there's no (obvious) clue as to why in config.log. If
> I run make again, it begins to build libstdc++ but fails with this:
> 
> Making all in libsupc++
> make[4]: Entering directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++'
> /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc -shared-libgcc -B/home/rask/build/gcc-bfin-unknown-elf/./gcc -nostdinc++ -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src/.libs -nostdinc -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem /home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include -isystem /n/12/rask/src/all/newlib/libc/include -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/bfin -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/libnosys -L/n/12/rask/src/all/libgloss/bfin -B/usr/local/bfin-unknown-elf/bin/ -B/usr/local/bfin-unknown-elf/lib/ -isystem /usr/local/bfin-unknown-elf/include -isystem /usr/local/bfin-unknown-elf/sys-include -L/home/rask/build/gcc-bfin-unknown-elf/./ld -I/n/12/rask/src/all/libstdc++-v3/../gcc -I/home/r
ask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include/bfin-unknown-elf -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include -I/n/12/rask/src/all/libstdc++-v3/libsupc++  -fno-implicit-templates  -Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections  -g -O2    -c -o array_type_info.lo /n/12/rask/src/all/libstdc++-v3/libsupc++/array_type_info.cc
> /bin/sh: ../libtool: No such file or directory
> make[4]: *** [array_type_info.lo] Error 127
> make[4]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3'
> make[1]: *** [all-target-libstdc++-v3] Error 2
> make[1]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf'
> make: *** [all] Error 2
> 
> I don't know why this happens to bfin and not to the other newlib targets.
> 
I guess it might be caused by different multilib settings in our local 
(not FSF) newlib and FSF gcc. I have committed a patch in FSF gcc which 
makes FSF gcc use the same multilib setting as our local gcc. Sorry 
about that. Please try again.


Jie

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> 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 to do compile-time tests if at
all possible, as then native/cross configury is unified.

From configure.ac...

# Enable all the variable C++ runtime options that doesn't require
linking. 
GLIBCXX_ENABLE_CSTDIO

...

# Checks for operating systems support that don't require linking.
GLIBCXX_CHECK_SYSTEM_ERROR

...

if $GLIBCXX_IS_NATIVE; then

  # We can do more elaborate tests that assume a working linker.
  CANADIAN=no
....

The intent here seems obvious to me: is this not clear? 

It's not especially well enforced, as you note. (And other runtimes
may not take as much care or notice about this at all.) In particular, 

>> AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

is not something libstdc++ has much control over.... I see this as a
bug in AM_PROG_LIBTOOL or these other macros.

> 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 configure tests, that's
> something everyone should know.

And....

> Since the preferred bare-metal setup is that linking not
> work without -msim (or a -T option), we don't want configure tests
> that detect any properties that might depend on what happens when you
> link. We want to make sure that detected properties are a property
> only of the parts that a user isn't going to change.

Thanks for this Mark. Absolutely agreed.

It is insanity to have this differ on a machine by machine or port by
port basis!!!! 

-benjamin

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

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 to link anything."

Unless it knows it must be able to link anyway when building libstdc++.  
Which is the case in order to build (shared) libstdc++ for GNU/Linux.  
Where link tests are more reliable than compile tests, given that uClibc 
doesn't always disable header declarations just because functions are 
disabled in the library.

(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.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> (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 directory, with all the libs that gcc +
deps need in one canonical place, named coherently and
consistently, built with proper deps, then we can use link tests.

Till then, we bite it, avoid, and hard-code the minimum amount
necessary.

It's not optimum, but it's well established procedure. Let's not change
this at random, on a per-port basis. Or, if we do, let's have a plan
and communicate it clearly, with a full transition by all the runtime
libs.

Haphazardly breaking stuff is weak.

-benjamin