Re: Link tests after GCC_NO_EXECUTABLES

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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]

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

[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

btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

(CC list pruned and updated.)

On Fri, 30 Nov 2007, 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.

Richard, I don't know when you tested; either you're telling
history or you're more updated, see PR21185 track for my
datestamp.

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

Only for two lame reasons, now that gfortran is expected to
build and test.

1 - it'll take much longer to regtest
2 - btest-gcc.sh isn't updated to cover fortran.
    Patch at <http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01710.html>.  Ping!

or three actually:
3 - not much real-world use for fortran on this target

brgds, H-P

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: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Hans-Peter Nilsson <hp@bitrange.com> writes:
> On Fri, 30 Nov 2007, 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.
>
> Richard, I don't know when you tested; either you're telling
> history or you're more updated, see PR21185 track for my
> datestamp.

Hmm.  Are you talking about mips*-elf or cris-elf?  The context
was snipped in the message you replied to, but I was only talking
about mips*-elf when I said the above.  FWIW, the full quote was:

    http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01668.html
    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.

(Even mips*-elf was probably too general, since now I think about it,
I probably only tried running the gfortran testsuite on 64-bit targets.
So many different configurations...)

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.

But yeah, it's clear from the PR that you and Rask have already done a
lot of work on this, and that you both know far more about it than I do.
I only really entered the thread because Mark asked me a direct question.
Given which, it would probably be best if I bowed out here.

Thanks to Rask for all the work he's done on this.

Richard

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Geoff Keating]

On Dec 3, 2007, at 6:40 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:

> (CC list pruned and updated.)
>
> On Fri, 30 Nov 2007, 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.
>
> 2 - btest-gcc.sh isn't updated to cover fortran.
>>
>>
>    Patch at <http://gcc.gnu.org/ml/gcc-patches/2007-09/ 
> msg01710.html>.  Ping!

Rejected; I do not think this script needs to be configurable in this  
fashion.  If there's a log missing, and you think the underlying  
functionality is stable and well supported by GCC contributors on all  
platforms where it is enabled, propose a patch to add it.

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

On Mon, 3 Dec 2007, Geoff Keating wrote:
> On Dec 3, 2007, at 6:40 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > 2 - btest-gcc.sh isn't updated to cover fortran.
> >   Patch at <http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01710.html>.  Ping!
>
> Rejected; I do not think this script needs to be configurable in this fashion.

But *I* do.  As it doesn't affect the default functionality or
the integrity of the result (everything still listed in
build_log), and doesn't take away or add redundant
functionality, I don't really understand your rejection.

> If there's a log missing, and you think the underlying functionality is stable
> and well supported by GCC contributors on all platforms where it is enabled,
> propose a patch to add it.

The fortran tests are stable where it works, or so it seems.
Whether it works is port-specific (build issue on *-elf being
covered in this thread), and the patch above was a way to add
the functionality per-platform.  It would also allow e.g.
tracking gas or ld results in a combined tree.

I just need a regtest-script I can point to, such that people
can see how I build and regtest and possibly repeat it.  Your
btest-gcc.sh mostly fits, but not covering all gcc-related tests
that run by "make check" is really an issue.  I guess I could
solve that by adding a variant of that script in contrib/ though
I do prefer improving the existing one.

brgds, H-P

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

On Mon, 3 Dec 2007, Richard Sandiford wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
> > Richard, I don't know when you tested; either you're telling
> > history or you're more updated, see PR21185 track for my
> > datestamp.
>
> Hmm.  Are you talking about mips*-elf or cris-elf?

For the record, just mips-elf or your favorite variant thereof.
(I've since seen the update from Rask.   Thanks!)

brgds, H-P

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Geoff Keating]

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


On 03/12/2007, at 2:39 PM, Hans-Peter Nilsson wrote:

> On Mon, 3 Dec 2007, Geoff Keating wrote:
>> On Dec 3, 2007, at 6:40 AM, Hans-Peter Nilsson <hp@bitrange.com>  
>> wrote:
>>> 2 - btest-gcc.sh isn't updated to cover fortran.
>>>  Patch at <http://gcc.gnu.org/ml/gcc-patches/2007-09/ 
>>> msg01710.html>.  Ping!
>>
>> Rejected; I do not think this script needs to be configurable in  
>> this fashion.
>
> But *I* do.  As it doesn't affect the default functionality or
> the integrity of the result (everything still listed in
> build_log), and doesn't take away or add redundant
> functionality, I don't really understand your rejection.

Part of the integrity of the result is that the same things are tested  
in every run of the script on a particular platform.  The script was  
specifically intended to not be configurable in the manner you want,  
because that would allow for the possibility that a misconfigured  
tester might miss some tests that ought to be run.

>> If there's a log missing, and you think the underlying  
>> functionality is stable
>> and well supported by GCC contributors on all platforms where it is  
>> enabled,
>> propose a patch to add it.
>
> The fortran tests are stable where it works, or so it seems.
> Whether it works is port-specific (build issue on *-elf being
> covered in this thread), and the patch above was a way to add
> the functionality per-platform.  It would also allow e.g.
> tracking gas or ld results in a combined tree.

The patch does not accomplish this.  It instead adds the functionality  
*per-tester*.  That's different to per-platform.

> I just need a regtest-script I can point to, such that people can  
> see how I build and regtest and possibly repeat it.

I would not go look at the scripts if I was trying to reproduce the  
results of my tester.  I would instead look at the build log which  
shows the exact 'configure' and 'make' commands used, with no need to  
do shell variable substitution in my head.

>  Your btest-gcc.sh mostly fits, but not covering all gcc-related  
> tests that run by "make check" is really an issue.

The patch does not implement this, either, but it might be a good idea.

The reason the script doesn't cover all tests is because some parts of  
the testsuite were too unreliable to be used in an automated fashion.   
That was some time ago and it may be that today it should simply look  
at all the testsuite.  Or, not.  If you have some data that points  
either way it would be very helpful.

>  I guess I could solve that by adding a variant of that script in  
> contrib/ though I do prefer improving the existing one.


Why?

I can't imagine you're saving an enormous amount of time in  
maintenance.  Nor is this script more conveniently located than a  
script you maintain in your own tree.  You could put your script on a  
web server and point people at that.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2460 bytes --]

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: btest-gcc.sh patch ping

[Hans-Peter Nilsson]

On Mon, 3 Dec 2007, Geoff Keating wrote:
> Part of the integrity of the result is that the same things are tested in
> every run of the script on a particular platform.  The script was specifically
> intended to not be configurable in the manner you want, because that would
> allow for the possibility that a misconfigured tester might miss some tests
> that ought to be run.

The same original set of tests are still run on all platforms.
If there are more that "ought to be run", I suggest you add
them.  Regarding missing tests, you must mean some other patch.
The way $BTEST_GCC_EXTRA_TESTLOGS is added in the patch, just as
with the "static" logs, it will be an error if the file(s) do
not exist and contains "PASS:".  ("More stable" than the
optional test logs added on an "if exists" basis above the
patched area, for example.)

> > > If there's a log missing, and you think the underlying functionality is
> > > stable
> > > and well supported by GCC contributors on all platforms where it is
> > > enabled,
> > > propose a patch to add it.
> >
> > The fortran tests are stable where it works, or so it seems.
> > Whether it works is port-specific (build issue on *-elf being
> > covered in this thread), and the patch above was a way to add
> > the functionality per-platform.  It would also allow e.g.
> > tracking gas or ld results in a combined tree.
>
> The patch does not accomplish this.  It instead adds the functionality
> *per-tester*.  That's different to per-platform.

It does too, but better: rather than the static list you seem to
imply, it's enables the *tester* control over which optional
testlogs apply to which platform.

> > I just need a regtest-script I can point to, such that people can see how I
> > build and regtest and possibly repeat it.
>
> I would not go look at the scripts if I was trying to reproduce the results of
> my tester.  I would instead look at the build log which shows the exact
> 'configure' and 'make' commands used, with no need to do shell variable
> substitution in my head.

By "repeat" I did not mean a specific run but to *reusing the
script for their own setup*.  The build_log just as before
contains all details about the specific run, including whatever
value BTEST_GCC_EXTRA_TESTLOGS had at the time.

> > Your btest-gcc.sh mostly fits, but not covering all gcc-related tests that
> > run by "make check" is really an issue.
>
> The patch does not implement this, either, but it might be a good idea.

Yes it does too again: the tester will have to know beforehand
which logs apply, but I think that makes more sense than using
"find" and adding all testsuite logs willy-nilly.

> The reason the script doesn't cover all tests is because some parts of the
> testsuite were too unreliable to be used in an automated fashion.  That was
> some time ago and it may be that today it should simply look at all the
> testsuite.  Or, not.  If you have some data that points either way it would be
> very helpful.

I wouldn't do it by default, but I agree e.g. a --find-all-logs
option might be useful.  I don't have a use for it myself, I
just meant it as an example of what the patch enables.

> > I guess I could solve that by adding a variant of that script in contrib/
> > though I do prefer improving the existing one.
> Why?
>
> I can't imagine you're saving an enormous amount of time in maintenance.  Nor
> is this script more conveniently located than a script you maintain in your
> own tree.  You could put your script on a web server and point people at that.

I could say your arguments speak more against
contrib/regression/btest-gcc.sh being there, but I don't agree
with your arguments in either case.

On the contrary, I think there's a use for a script dealing with
the housekeeping of an automatic regression tester, and with
some optional aspects enabling different setups.  I just mistook
your script for being it.  I also think the place for such a
script is naturally in contrib/ - is really not the convenience
of having the script there, both for maintenance and sharing
obvious to you?  If you mean something else, speak in clear text.

I propose adding a "less stringent" version as
contrib/build-and-regtest-gcc.sh.

If someone already has their own, different, script for
autotesting they are willing to contribute and is open to
changes while maintaining the default functionality, a script
which is no less than btest-gcc.sh (e.g. handles adding new
tests and pruning old ones), I don't mind switching my
autotester over.

brgds, H-P

Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

On Sat, 1 Dec 2007, Rask Ingemann Lambertsen wrote:

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

Does it work without --with-newlib, i.e. is it automatically
added and works with your change?

If not, passing --with-newlib didn't use to be a requirement,
and I don't think it should be, if it's an *-elf target and
newlib is in the tree.

Or at least let's make it target-dependent.

brgds, H-P

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Tue, Dec 04, 2007 at 07:10:05PM -0500, Hans-Peter Nilsson wrote:
> On Sat, 1 Dec 2007, Rask Ingemann Lambertsen wrote:
> 
> >    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.
> 
> Does it work without --with-newlib, i.e. is it automatically
> added and works with your change?

   AFAIK it is target specific. My patch doesn't change how it works.

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

[Hans-Peter Nilsson]

On Wed, 5 Dec 2007, Rask Ingemann Lambertsen wrote:
> On Tue, Dec 04, 2007 at 07:10:05PM -0500, Hans-Peter Nilsson wrote:
> > Does it work without --with-newlib, i.e. is it automatically
> > added and works with your change?
>
>    AFAIK it is target specific. My patch doesn't change how it works.

Right, line 1725 in configure.ac (r130610) does the default.
Thanks.

brgds, H-P

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Sun, Dec 02, 2007 at 01:10:44PM -0800, Mark Mitchell wrote:
> 
> 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.

   I think it wouldn't be all that difficult. The top-level configure could
try to append the target name to the default config.cache and use that as
the default for the --with-target-lib-cache= option. The multilibs are
handled by config-ml.in which could try to append the multilib name and see
if that file exists, and if not, just use what was passed down from the top
level. Less than twenty lines of code on a good day.

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

>> 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.
> 
>    I think it wouldn't be all that difficult.

All right.

Rask, your patch as posted is OK, assuming no objections within 48 hours.

Thanks,

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

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Wed, Dec 05, 2007 at 04:37:42PM -0800, Mark Mitchell wrote:
> 
> Rask, your patch as posted is OK, assuming no objections within 48 hours.

   I do have a few changes to libffi and libjava/libltdl from trying to
build for bfin-unknown-elf. Alas, building libjava ends with
classpath/native/fdlibm/ieeefp.h:159:2: error: #error Endianess not declared!!
but at least it configures now. I added more entries to the cache file:

ac_cv_func_which_gethostbyname_r=${ac_cv_func_which_gethostbyname_r=unknown}
ac_cv_lib_magic_magic_open=${ac_cv_lib_magic_magic_open=no}
ac_cv_search_inet_pton=${ac_cv_search_inet_pton='none required'}
ac_cv_search_opendir=${ac_cv_search_opendir='none required'}
ac_cv_var_tzname=${ac_cv_var_tzname=yes}
gcc_cv_getipinfo=${gcc_cv_getipinfo=yes}
gcc_cv_have_tls=${gcc_cv_have_tls=yes}
libjava_cv_anon_version_script=${libjava_cv_anon_version_script=yes}
# TODO: am_cv_func_iconv: This is configurable (--enable-newlib-iconv).
am_cv_func_iconv=${am_cv_func_iconv=no}

   I have bootstrapped and tested on x86_64-unknown-linux-gnu with no
regressions. I'll retest on arm-unknown-elf, cris-axis-elf,
fr30-unknown-elf, m32c-unknown-elf, mipsisa64-unknown-elf, sh-unknown-elf
and v850-unknown-elf. Ok if it passes?

2007-12-06  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* configure.ac: Export with_newlib.
	* Makefile.tpl: Import with_newlib.  Use hard coded link test results
	if newlib is built.
	* config-ml.in: Use hard coded link test results if newlib is built.
	* config-newlib-linktests.cache: New.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

libgfortran/
	* configure.ac: Disable symbol versioning when link tests are not
	possible.
	* configure: Regenerate.

libffi/
	* configure.ac: Call GCC_NO_EXECUTABLES.
	* configure: Regenerate.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libjava/libltdl/
	* configure.ac: Call GCC_NO_EXECUTABLES.  Work around link test
	problems with the AC_LIB_LTDL macro.
	* configure: Regenerate.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.

Index: configure.ac
===================================================================
--- configure.ac	(revision 130651)
+++ 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)
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 130651)
+++ 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 130651)
+++ config-ml.in	(working copy)
@@ -852,6 +852,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 130651)
+++ 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])
Index: libffi/configure.ac
===================================================================
--- libffi/configure.ac	(revision 130651)
+++ libffi/configure.ac	(working copy)
@@ -14,6 +14,8 @@
 
 AM_INIT_AUTOMAKE
 
+GCC_NO_EXECUTABLES
+
 # The same as in boehm-gc and libstdc++. Have to borrow it from there.
 # We must force CC to /not/ be precious variables; otherwise
 # the wrong, non-multilib-adjusted value will be used in multilibs.
Index: libjava/libltdl/configure.ac
===================================================================
--- libjava/libltdl/configure.ac	(revision 130651)
+++ libjava/libltdl/configure.ac	(working copy)
@@ -61,6 +61,7 @@
 ## ------------------ ##
 ## C compiler checks. ##
 ## ------------------ ##
+GCC_NO_EXECUTABLES
 AC_PROG_CC
 AC_C_CONST
 AC_C_INLINE
@@ -73,9 +74,12 @@
 AC_PROG_LIBTOOL
 AC_SUBST([LIBTOOL_DEPS])
 
+# The AC_LIB_LTDL macro is broken: ${ac_cv_lib_dl_dlopen} isn't checked.
+# Temporarily permit link tests even if not working.
+save_gcc_no_link="$gcc_no_link"; gcc_no_link=no
 AC_LIB_LTDL
+gcc_no_link="$save_gcc_no_link"
 
-
 ## -------- ##
 ## Outputs. ##
 ## -------- ##
--- /dev/null	2007-12-04 21:23:27.128000250 +0100
+++ config-newlib-linktests.cache	2007-12-06 17:12:53.000000000 +0100
@@ -0,0 +1,308 @@
+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_pthread_getattr_np=${ac_cv_func_pthread_getattr_np=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}
+ac_cv_search_inet_pton=${ac_cv_search_inet_pton='none required'}
+ac_cv_search_opendir=${ac_cv_search_opendir='none required'}
+ac_cv_var_tzname=${ac_cv_var_tzname=yes}
+gcc_cv_getipinfo=${gcc_cv_getipinfo=yes}
+gcc_cv_have_tls=${gcc_cv_have_tls=yes}
+have_attribute_alias=${have_attribute_alias=yes}
+have_mingw_snprintf=${have_mingw_snprintf=no}
+libjava_cv_anon_version_script=${libjava_cv_anon_version_script=yes}
+# TODO: Some targets might have these functions.
+have_fpsetmask=${have_fpsetmask=no}
+have_sync_fetch_and_add=${have_sync_fetch_and_add=no}
+# TODO: am_cv_func_iconv: This is configurable (--enable-newlib-iconv).
+am_cv_func_iconv=${am_cv_func_iconv=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:

> gcc_cv_have_tls=${gcc_cv_have_tls=yes}

How do we get TLS with Newlib on the average bare-metal target?

> # TODO: am_cv_func_iconv: This is configurable (--enable-newlib-iconv).
> am_cv_func_iconv=${am_cv_func_iconv=no}

I guess this is OK, in that it's the conservative choice.

Thanks,

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

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

OK, I'm not doing a good job of staying out of this discussion as
promised, but I was hoping someone else would raise this point...

My main concern with applying this patch in its current state is that,
while we have (intentionally) only been talking about *-elf so far,
newlib != *-elf.  Cygwin is also an important newlib user, and I don't
remember anyone explicitly mentioning it so far in this thread.  Is this
patch really safe there?  Cygwin's newlib provides all sorts of POSIXy
stuff that you don't get in your typical *-elf target (see libc/posix)
so things like:

> +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}

(just a sample) might unintentionally limit the functionality of
libgfortran on that target.  I think the same thing could apply
to targets like Newlib/Linux, if GCC supports it.

While I'm here, I noticed a very minor nit.  The patch has:

> +ac_cv_func_fork=${ac_cv_func_fork=no}
> +ac_cv_func_fork=${ac_cv_func_fork=yes}

where the last line is redundant (though harmless).

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Fri, Dec 07, 2007 at 11:27:31AM +0000, Richard Sandiford wrote:
> OK, I'm not doing a good job of staying out of this discussion as
> promised, but I was hoping someone else would raise this point...
> 
> My main concern with applying this patch in its current state is that,
> while we have (intentionally) only been talking about *-elf so far,
> newlib != *-elf.  Cygwin is also an important newlib user, and I don't
> remember anyone explicitly mentioning it so far in this thread.

   What is a good way of detecting the bare-metal targets? *-elf*, *-eabi*?

> While I'm here, I noticed a very minor nit.  The patch has:
> 
> > +ac_cv_func_fork=${ac_cv_func_fork=no}
> > +ac_cv_func_fork=${ac_cv_func_fork=yes}

   Well spotted. The nit is real enough. What happens is this (with
unpatched mainline):

Checking multilib configuration for libgfortran...
mkdir -p -- v850-unknown-elf/libgfortran
Configuring in v850-unknown-elf/libgfortran
configure: creating cache ./config.cache
[...]
checking for access... yes
checking for fork... yes
checking for execl... no
[...]

   The same tests with fr30-unknown-elf:

checking for access... no
checking for fork... no
checking for execl... no

   Other examples: gettimeofday, link, mkstemp, pipe, stat, time and wait.

-- 
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, Dec 06, 2007 at 05:37:01PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
> 
> > gcc_cv_have_tls=${gcc_cv_have_tls=yes}
> 
> How do we get TLS with Newlib on the average bare-metal target?

   I thought I saw a patch for that going in a while ago, but configuring
libjava on arm-unknown-elf returns no, so I'll change the cache file
accordingly.

   Speaking of tbe cache file, should I put it into the config subdirectory
(s,config-newlib-linktests.cache,config/newlib-linktests.cache,g)?

-- 
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:
> On Thu, Dec 06, 2007 at 05:37:01PM -0800, Mark Mitchell wrote:
>> Rask Ingemann Lambertsen wrote:
>>
>>> gcc_cv_have_tls=${gcc_cv_have_tls=yes}
>> How do we get TLS with Newlib on the average bare-metal target?
> 
>    I thought I saw a patch for that going in a while ago, but configuring
> libjava on arm-unknown-elf returns no, so I'll change the cache file
> accordingly.

I have to admit that I'm getting concerned.  The issue Richard has
raised about Cygwin, and the various corner-cases here are making me
think that we're at risk of introducing instability.

I was trying to go along with your patch because it seemed like a
compromise between (a) the top-level patch to make things link (even
though they may not correspond to how the toolchain will be used) and
(b) going backwards (undoing the ability to build various run-time
libraries that the top-level patch added).

I was thinking that a basic cache file would be safe, in the sense that
at least it might accidentally disable a capability or two, but not use
capabilities that aren't there.  But, I'm afraid that we're going to
have a hard time getting it set conservative enough, and that if we do
we're going to miss important capabilities.  I'm afraid that we're
making a relatively large change relatively late in the game.

I think I'd prefer to be more conservative: return to the state we had
with previous releases.  The patch that Richard tested fixes libstdc++
and allows us to revert the various top-level changes.

Then, for 4.4, we can tackle the broad question of how we ought to be
build the run-time libraries for bare-metal.  Maybe configure-time
arguments that let the toolchain link in a representative way for the
target environment?  Or a cache file that contains answers to the
questions the run-time library configury is going to ask?  Or hand-coded
logic like presently used by libstdc++?  Since you have strong opinions
about this, perhaps you could lead this debate.

Would you be willing to go along with that plan?

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

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Fri, Dec 07, 2007 at 10:37:59AM -0800, Mark Mitchell wrote:
> 
> I have to admit that I'm getting concerned.  The issue Richard has
> raised about Cygwin, and the various corner-cases here are making me
> think that we're at risk of introducing instability.

   I think so too. If the Cygwin example had been raised a week ago I
wouldn't have used ${with_newlib} to enable use of the cache file.

   Status is that I would still hate to loose the ability to build the
simulator targets in a straight-forward way. At the same time, I can easily
live with adding one more option to the configure command to get the
simulator targets to build. So my suggestion is this:

1) Make the cached link test results require an explicit option to enable
them. I can code that up tomorrow.
2) Put in the libstdc++ patch.
3) Revert the top level changes for the -B and -L options.

   Does this sound safe enough?

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

> 1) Make the cached link test results require an explicit option to enable
> them. I can code that up tomorrow.
> 2) Put in the libstdc++ patch.
> 3) Revert the top level changes for the -B and -L options.
> 
>    Does this sound safe enough?

Yes, I think that's a good plan.  That gives the cached link tests as an
experimental path forward for people who want to try it, but otherwise
gets us back to the status quo ante.

Thank you,

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

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Rask Ingemann Lambertsen <rask@sygehus.dk> writes:
> On Fri, Dec 07, 2007 at 11:27:31AM +0000, Richard Sandiford wrote:
>> OK, I'm not doing a good job of staying out of this discussion as
>> promised, but I was hoping someone else would raise this point...
>> 
>> My main concern with applying this patch in its current state is that,
>> while we have (intentionally) only been talking about *-elf so far,
>> newlib != *-elf.  Cygwin is also an important newlib user, and I don't
>> remember anyone explicitly mentioning it so far in this thread.
>
>    What is a good way of detecting the bare-metal targets? *-elf*, *-eabi*?

TBH, I'm not sure.  I wonder if a good starting point might be to take
the toplevel configure.ac stanzas that currently (i.e. after your earlier
patch) set libgloss_dir, and see which of those have an appropriate
"bare-metal-like" configuration in newlib/libgloss.  That might be
easier than a full two-way comparison between toplevel configure
and newlib/libgloss, and it can always be added to later.

(On that note, it might be a good idea to introduce a specific
mips*-*-elf* stanza in the toplevel makefile, and only do the
ibgloss_dir stuff, or its replacement, for that.  The current
mips*-*-* stanza traps almost-certainly-bitrotten targets like
mips*-openbsd* as well.)

I see downthread that you and Mark talked about a new configure option.
Would it be worth defaulting to on for the targets we know are "safe"?

(For the record, I do like the cache idea, and thanks for implementing it.
I hope yesterday's message didn't make it sound otherwise.  I just wanted
to make sure that what went into mainline wouldn't cast the net too wide.
Once we identify targets that work with the cache, I'd personally like
them to use it by default.  And that includes the mips*-elf* family.)

Richard

[PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Fri, Dec 07, 2007 at 01:56:52PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
> 
> > 1) Make the cached link test results require an explicit option to enable
> > them. I can code that up tomorrow.
> > 2) Put in the libstdc++ patch.
> > 3) Revert the top level changes for the -B and -L options.
> > 
> >    Does this sound safe enough?
> 
> Yes, I think that's a good plan.  That gives the cached link tests as an
> experimental path forward for people who want to try it, but otherwise
> gets us back to the status quo ante.

   I bootstrapped and tested on x86_64-unknown-linux-gnu with no
regressions. I built and tested cross-compilers for arm-unknown-elf,
cris-axis-elf, fr30-unknown-elf, m32c-unknown-elf, m32r-unknown-elf,
mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf with no
regressions. I also built a cross compiler for sparc-unknown-elf which
doesn't work without the patch but does work with the new option.
Ok for trunk?

2007-12-13  Rask Ingemann Lambertsen  <rask@sygehus.dk>

	* configure.ac: New option --with-target-config.  Pass it to target
	sub-configures when set.  Export with_target_config.
	* Makefile.tpl: Import with_target_config.  Preload target configure
	test results when $(with_target_config) is set.
	* config-ml.in: Preload target configure test results when
	${with_target_config} is set.
	* config/newlib-linktests.cache: New.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

libgfortran/
	* configure.ac: Disable symbol versioning when link tests are not
	possible.
	* configure: Regenerate.

libffi/
	* configure.ac: Call GCC_NO_EXECUTABLES.
	* configure: Regenerate.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

libjava/libltdl/
	* configure.ac: Call GCC_NO_EXECUTABLES.  Work around link test
	problems with the AC_LIB_LTDL macro.
	* configure: Regenerate.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.

Index: configure.ac
===================================================================
--- configure.ac	(revision 130699)
+++ configure.ac	(working copy)
@@ -2634,6 +2634,20 @@
 AC_SUBST(COMPILER_LD_FOR_TARGET)
 AC_SUBST(COMPILER_NM_FOR_TARGET)
 
+AC_ARG_WITH([target-config],
+  [  --with-target-config=FILE
+                          Preload FILE before configuring target libraries],
+  [if test "x${with_target_config}" = "xno" ; then
+    with_target_config=
+  fi],
+  [with_target_config=])
+AC_SUBST(with_target_config)
+
+# Pass --with-target-config if set.
+if test "x${with_target_config}" != "x" ; then
+  target_configargs="--with-target-config=${with_target_config} ${target_configargs}"
+fi
+
 AC_MSG_CHECKING([whether to enable maintainer-specific portions of Makefiles])
 AC_ARG_ENABLE(maintainer-mode,
 [  --enable-maintainer-mode enable make rules and dependencies not useful
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 130699)
+++ Makefile.tpl	(working copy)
@@ -394,6 +394,7 @@
 # ------------------------------------
 # Miscellaneous targets and flag lists
 # ------------------------------------
+with_target_config = @with_target_config@
 
 # 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_target_config)" != "x"; then \
+	  echo "Preloading target configuration $${with_target_config}."; \
+	  cp "$${with_target_config}" 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 130699)
+++ config-ml.in	(working copy)
@@ -852,6 +852,10 @@
 	fi
     fi
 
+    if test ! -f config.cache -a "x${with_target_config}" != "x"; then
+      echo "Preloading target configuration ${with_target_config}."
+      cp "${with_target_config}" 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 130699)
+++ 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])
Index: libffi/configure.ac
===================================================================
--- libffi/configure.ac	(revision 130699)
+++ libffi/configure.ac	(working copy)
@@ -14,6 +14,8 @@
 
 AM_INIT_AUTOMAKE
 
+GCC_NO_EXECUTABLES
+
 # The same as in boehm-gc and libstdc++. Have to borrow it from there.
 # We must force CC to /not/ be precious variables; otherwise
 # the wrong, non-multilib-adjusted value will be used in multilibs.
Index: libjava/libltdl/configure.ac
===================================================================
--- libjava/libltdl/configure.ac	(revision 130699)
+++ libjava/libltdl/configure.ac	(working copy)
@@ -61,6 +61,7 @@
 ## ------------------ ##
 ## C compiler checks. ##
 ## ------------------ ##
+GCC_NO_EXECUTABLES
 AC_PROG_CC
 AC_C_CONST
 AC_C_INLINE
@@ -73,9 +74,12 @@
 AC_PROG_LIBTOOL
 AC_SUBST([LIBTOOL_DEPS])
 
+# The AC_LIB_LTDL macro is broken: ${ac_cv_lib_dl_dlopen} isn't checked.
+# Temporarily permit link tests even if not working.
+save_gcc_no_link="$gcc_no_link"; gcc_no_link=no
 AC_LIB_LTDL
+gcc_no_link="$save_gcc_no_link"
 
-
 ## -------- ##
 ## Outputs. ##
 ## -------- ##
--- /dev/null	2007-12-04 21:23:27.128000250 +0100
+++ config/newlib-linktests.cache	2007-12-08 19:13:55.000000000 +0100
@@ -0,0 +1,308 @@
+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_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_pthread_getattr_np=${ac_cv_func_pthread_getattr_np=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_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}
+ac_cv_search_inet_pton=${ac_cv_search_inet_pton='none required'}
+ac_cv_search_opendir=${ac_cv_search_opendir='none required'}
+ac_cv_var_tzname=${ac_cv_var_tzname=yes}
+gcc_cv_getipinfo=${gcc_cv_getipinfo=yes}
+gcc_cv_have_tls=${gcc_cv_have_tls=no}
+have_attribute_alias=${have_attribute_alias=yes}
+have_mingw_snprintf=${have_mingw_snprintf=no}
+libjava_cv_anon_version_script=${libjava_cv_anon_version_script=yes}
+TODO: Most *-elf targets have times(), but e.g. sparc and mips don't.
+ac_cv_func_times=${ac_cv_func_times=no}
+# TODO: Some targets might have these functions.
+have_fpsetmask=${have_fpsetmask=no}
+have_sync_fetch_and_add=${have_sync_fetch_and_add=no}
+# TODO: am_cv_func_iconv: This is configurable (--enable-newlib-iconv).
+am_cv_func_iconv=${am_cv_func_iconv=no}

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

Ping [PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00632.html

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

Re: Ping [PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES

[Paolo Bonzini]

Rask Ingemann Lambertsen wrote:
> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00632.html

Can you try using --cache-file= instead of "preloading" the cache file? 
  Like this:

# Pass --with-target-config if set.
if test "x${with_target_config}" != "x" ; then
   target_configargs="--cache-file=${with_target_config} 
${target_configargs}"
fi

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

Please change gfortran_use_symver to something like 
gfortran_cv_use_symver and use AC_CACHE_CHECK so that it can be 
overridden in the target cache file.

> +# The AC_LIB_LTDL macro is broken: ${ac_cv_lib_dl_dlopen} isn't checked.
> +# Temporarily permit link tests even if not working.
> +save_gcc_no_link="$gcc_no_link"; gcc_no_link=no
>  AC_LIB_LTDL
> +gcc_no_link="$save_gcc_no_link"

Please change AC_LTDL_DLLIB in libjava/libltdl/acinclude.m4 instead. 
You should use AC_SEARCH_LIBS like this:

ltdl_save_LIBS=$LIBS
AC_SEARCH_LIBS([dlopen], [dl])
LIBS=$ltdl_save_LIBS
case "$ac_cv_search_gethostbyname" in
   -ldl)
     LIBADD_DL="-ldl" libltdl_cv_lib_dl_dlopen="yes"\
     AC_DEFINE([HAVE_LIBDL], [1],
               [Define if you have the libdl library or equivalent.]
     ;;
   "none required")
     libltdl_cv_func_dlopen="yes"
     AC_DEFINE([HAVE_LIBDL], [1],
               [Define if you have the libdl library or equivalent.]
     ;;
   *) ...
esac

Thanks!

Paolo

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Richard Sandiford wrote:
> 	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)

<...>

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

We had a big discussion about this last year, but nothing appears to 
have been checked in.  I'll need at least the libstdc++-v3 part for a 
Blackfin patch I'm about to check in.  Since Mark approved this - would 
you like to retest and commit, or should I just commit the libstdc++-v3 
bits for now?


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

[Richard Sandiford]

Bernd Schmidt <bernds_cb1@t-online.de> writes:
> Richard Sandiford wrote:
>> 	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)
>
> <...>
>
>> 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)
>
> We had a big discussion about this last year, but nothing appears to 
> have been checked in.

Unfortunately true.

> I'll need at least the libstdc++-v3 part for a 
> Blackfin patch I'm about to check in.  Since Mark approved this - would 
> you like to retest and commit, or should I just commit the libstdc++-v3 
> bits for now?

To be honest, I don't know what the best thing to do is.  Maybe Mark has
an opinion.

IIRC, the patch you quote was the one that restored us to 4.2 behaviour,
for which libgloss targets were not supposed to (need to) depend on link
tests.  This was tied up with a discussion on binutils@ about whether a
failure to find the start symbol should be a fatal error.  I think the
binutils@ discussion got stalled too.

If so, the patch you quote never got checked in because Rask was working
on a patch to use a config cache file instead.  He posted a version of
that, but I don't think it ever got to state in which it was approved.
I think Rask has since moved onto other things.  (Perhaps because of
the way this discussion and review process went?  I hope not.)

As it stands, I believe 4.3 went out with the same behaviour it had at
the time of the discussion.  Sorry in advance if I'm wrong about that;
it's all a bit hazy now.

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Richard Sandiford wrote:
> Bernd Schmidt <bernds_cb1@t-online.de> writes:
>> 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.
>>>

> To be honest, I don't know what the best thing to do is.  Maybe Mark has
> an opinion.

I've now checked in the libstdc++-v3 patch, which is a reasonably 
obvious bug fix.  I've never had an opinion on whether other targets 
ought to fail link tests, hence I'm not really interested in pursuing 
the other part of the patch.  I'll leave that to you or Mark, if you wish.


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:

> I've now checked in the libstdc++-v3 patch, which is a reasonably 
> obvious bug fix.  I've never had an opinion on whether other targets 
> ought to fail link tests, hence I'm not really interested in pursuing 
> the other part of the patch.  I'll leave that to you or Mark, if you wish.

I think the libstdc++-v3 change is indeed pretty obvious.

I still think that reverting Rask's patch is the right thing to do.  I 
think the fundamental assumption that you can use the simulator target 
as way to probe the target is just wrong for bare-metal systems; what's 
available in simulation and might what might be available otherwise need 
not be the same.  We're making assumptions about the target system when 
the only reliable way to do that is to have the person configuring the 
compiler tell us.  I think that we sometimes try too hard to make 
configury smart; essentially, we're preferring wrong answers to making 
the user do some work.

But, I also don't have a compelling reason to push forward on that 
myself at this point.

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

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

On Thu, 15 May 2008, Mark Mitchell wrote:

> Bernd Schmidt wrote:
> 
> > I've now checked in the libstdc++-v3 patch, which is a reasonably obvious
> > bug fix.  I've never had an opinion on whether other targets ought to fail
> > link tests, hence I'm not really interested in pursuing the other part of
> > the patch.  I'll leave that to you or Mark, if you wish.
> 
> I think the libstdc++-v3 change is indeed pretty obvious.

As I understand it, it's also a regression fix that should go on 4.3 
branch as well.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Link tests after GCC_NO_EXECUTABLES

[Ralf Wildenhues]

<http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00948.html>

* Joseph S. Myers wrote on Fri, May 16, 2008 at 02:05:35AM CEST:
> On Thu, 15 May 2008, Mark Mitchell wrote:
> > Bernd Schmidt wrote:
> > 
> > > I've now checked in the libstdc++-v3 patch, which is a reasonably obvious
> > > bug fix.  I've never had an opinion on whether other targets ought to fail
> > > link tests, hence I'm not really interested in pursuing the other part of
> > > the patch.  I'll leave that to you or Mark, if you wish.
> > 
> > I think the libstdc++-v3 change is indeed pretty obvious.
> 
> As I understand it, it's also a regression fix that should go on 4.3 
> branch as well.

This has not happened yet.  Is there anything holding it up?

Also, I've been kind of wondering.  AC_LIBTOOL_DLOPEN is also used in
libgfortran and libmudflap; the latter has no GCC_NO_EXECUTABLES though.
Do these directories never get built on newlib targets?

Thanks,
Ralf

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Ralf Wildenhues wrote:

> This has not happened yet.  Is there anything holding it up?

Not so far as I am aware.  If you would like to apply the patch, please 
go ahead and apply it to 4.3 as well.

> Also, I've been kind of wondering.  AC_LIBTOOL_DLOPEN is also used in
> libgfortran and libmudflap; the latter has no GCC_NO_EXECUTABLES though.
> Do these directories never get built on newlib targets?

I don't think they're used very often on Newlib-based targets.  I'm sure 
someone will tell us that they do in fact use them, but I think they're 
much more often used on workstation/server class systems.

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

Re: Link tests after GCC_NO_EXECUTABLES

[Ralf Wildenhues]

<http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00948.html>

* Mark Mitchell wrote on Thu, Jun 19, 2008 at 05:49:46AM CEST:
> Ralf Wildenhues wrote:
>
>> This has not happened yet.  Is there anything holding it up?
>
> Not so far as I am aware.  If you would like to apply the patch, please  
> go ahead and apply it to 4.3 as well.

Thanks, and sorry for the delay.  I've put Bernd's patch from trunk
in 4.3 now.

Cheers,
Ralf

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Richard Guenther]

On Tue, Dec 4, 2007 at 7:52 AM, Geoff Keating <geoffk@geoffk.org> wrote:
>
>>  I guess I could solve that by adding a variant of that script in contrib/
>> though I do prefer improving the existing one.
>
>
> Why?
>
> I can't imagine you're saving an enormous amount of time in maintenance.
>  Nor is this script more conveniently located than a script you maintain in
> your own tree.  You could put your script on a web server and point people
> at that.

Huh.  So what exactly does btest-gcc.sh do then in the public repository
in the first place if it is seemingly your personal read-only copy?

People could of course branch their own btest-gcc.sh file and switch only
that file to their branch if testing a tree.

Richard.

Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES

[Geoff Keating]

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


On 28/03/2009, at 6:57 AM, Richard Guenther wrote:

> On Tue, Dec 4, 2007 at 7:52 AM, Geoff Keating <geoffk@geoffk.org>  
> wrote:
>>
>>>  I guess I could solve that by adding a variant of that script in  
>>> contrib/
>>> though I do prefer improving the existing one.
>>
>>
>> Why?
>>
>> I can't imagine you're saving an enormous amount of time in  
>> maintenance.
>>  Nor is this script more conveniently located than a script you  
>> maintain in
>> your own tree.  You could put your script on a web server and point  
>> people
>> at that.
>
> Huh.  So what exactly does btest-gcc.sh do then in the public  
> repository
> in the first place if it is seemingly your personal read-only copy?

If having it in the repository doesn't provide any benefits to others,  
I'll take it out.  I put it there because over the years I had  
numerous requests to make these scripts public.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2464 bytes --]