* Re: Link tests after GCC_NO_EXECUTABLES [not found] ` <46EFDA4D.3070006@gmail.com> @ 2007-11-27 15:35 ` Bernd Schmidt 2007-11-27 22:17 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2007-11-27 15:35 UTC (permalink / raw) To: Jie Zhang; +Cc: gcc, GCC Patches [-- 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 15:35 ` Link tests after GCC_NO_EXECUTABLES Bernd Schmidt @ 2007-11-27 22:17 ` Mark Mitchell 2007-11-27 22:40 ` Bernd Schmidt 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-27 22:17 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 22:17 ` Mark Mitchell @ 2007-11-27 22:40 ` Bernd Schmidt 2007-11-27 22:43 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2007-11-27 22:40 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 22:40 ` Bernd Schmidt @ 2007-11-27 22:43 ` Mark Mitchell 2007-11-27 22:58 ` Bernd Schmidt 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-27 22:43 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 22:43 ` Mark Mitchell @ 2007-11-27 22:58 ` Bernd Schmidt 2007-11-27 23:17 ` Mark Mitchell 2007-11-28 8:54 ` Joseph S. Myers 0 siblings, 2 replies; 83+ messages in thread From: Bernd Schmidt @ 2007-11-27 22:58 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 22:58 ` Bernd Schmidt @ 2007-11-27 23:17 ` Mark Mitchell 2007-11-28 0:23 ` Bernd Schmidt 2007-11-28 8:54 ` Joseph S. Myers 1 sibling, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-27 23:17 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 23:17 ` Mark Mitchell @ 2007-11-28 0:23 ` Bernd Schmidt 2007-11-28 0:33 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2007-11-28 0:23 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 0:23 ` Bernd Schmidt @ 2007-11-28 0:33 ` Mark Mitchell 2007-11-28 1:03 ` Bernd Schmidt 2007-11-28 13:07 ` Richard Sandiford 0 siblings, 2 replies; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 0:33 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 0:33 ` Mark Mitchell @ 2007-11-28 1:03 ` Bernd Schmidt 2007-11-28 1:24 ` Mark Mitchell 2007-11-28 13:07 ` Richard Sandiford 1 sibling, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2007-11-28 1:03 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 1:03 ` Bernd Schmidt @ 2007-11-28 1:24 ` Mark Mitchell 2007-11-28 6:34 ` Bernd Schmidt 2007-11-28 8:16 ` Joseph S. Myers 0 siblings, 2 replies; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 1:24 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 1:24 ` Mark Mitchell @ 2007-11-28 6:34 ` Bernd Schmidt 2007-11-28 10:37 ` Mark Mitchell 2007-11-28 8:16 ` Joseph S. Myers 1 sibling, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2007-11-28 6:34 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 6:34 ` Bernd Schmidt @ 2007-11-28 10:37 ` Mark Mitchell 2007-11-28 15:47 ` Bernd Schmidt 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 10:37 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 10:37 ` Mark Mitchell @ 2007-11-28 15:47 ` Bernd Schmidt 0 siblings, 0 replies; 83+ messages in thread From: Bernd Schmidt @ 2007-11-28 15:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 1:24 ` Mark Mitchell 2007-11-28 6:34 ` Bernd Schmidt @ 2007-11-28 8:16 ` Joseph S. Myers 2007-11-28 10:01 ` Mark Mitchell 1 sibling, 1 reply; 83+ messages in thread From: Joseph S. Myers @ 2007-11-28 8:16 UTC (permalink / raw) To: Mark Mitchell Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 8:16 ` Joseph S. Myers @ 2007-11-28 10:01 ` Mark Mitchell 2007-11-28 11:37 ` Joseph S. Myers 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 10:01 UTC (permalink / raw) To: Joseph S. Myers Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 10:01 ` Mark Mitchell @ 2007-11-28 11:37 ` Joseph S. Myers 2007-11-28 11:40 ` Mark Mitchell 2007-11-28 15:37 ` Bernd Schmidt 0 siblings, 2 replies; 83+ messages in thread From: Joseph S. Myers @ 2007-11-28 11:37 UTC (permalink / raw) To: Mark Mitchell Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 11:37 ` Joseph S. Myers @ 2007-11-28 11:40 ` Mark Mitchell 2007-11-28 15:37 ` Bernd Schmidt 1 sibling, 0 replies; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 11:40 UTC (permalink / raw) To: Joseph S. Myers Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 11:37 ` Joseph S. Myers 2007-11-28 11:40 ` Mark Mitchell @ 2007-11-28 15:37 ` Bernd Schmidt 1 sibling, 0 replies; 83+ messages in thread From: Bernd Schmidt @ 2007-11-28 15:37 UTC (permalink / raw) To: Joseph S. Myers Cc: Mark Mitchell, Jie Zhang, gcc, GCC Patches, Richard Sandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 0:33 ` Mark Mitchell 2007-11-28 1:03 ` Bernd Schmidt @ 2007-11-28 13:07 ` Richard Sandiford 2007-11-28 16:06 ` Rask Ingemann Lambertsen ` (2 more replies) 1 sibling, 3 replies; 83+ messages in thread From: Richard Sandiford @ 2007-11-28 13:07 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 13:07 ` Richard Sandiford @ 2007-11-28 16:06 ` Rask Ingemann Lambertsen 2007-11-28 16:59 ` Daniel Jacobowitz 2007-11-28 18:55 ` Mark Mitchell 2 siblings, 0 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-28 16:06 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 13:07 ` Richard Sandiford 2007-11-28 16:06 ` Rask Ingemann Lambertsen @ 2007-11-28 16:59 ` Daniel Jacobowitz 2007-11-28 18:55 ` Mark Mitchell 2 siblings, 0 replies; 83+ messages in thread From: Daniel Jacobowitz @ 2007-11-28 16:59 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 13:07 ` Richard Sandiford 2007-11-28 16:06 ` Rask Ingemann Lambertsen 2007-11-28 16:59 ` Daniel Jacobowitz @ 2007-11-28 18:55 ` Mark Mitchell 2007-11-28 22:41 ` Richard Sandiford ` (2 more replies) 2 siblings, 3 replies; 83+ messages in thread From: Mark Mitchell @ 2007-11-28 18:55 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, Rask Ingemann Lambertsen 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 18:55 ` Mark Mitchell @ 2007-11-28 22:41 ` Richard Sandiford 2007-11-28 23:03 ` Rask Ingemann Lambertsen 2007-11-30 3:56 ` Richard Sandiford 2 siblings, 0 replies; 83+ messages in thread From: Richard Sandiford @ 2007-11-28 22:41 UTC (permalink / raw) To: Mark Mitchell Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, Rask Ingemann Lambertsen 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 18:55 ` Mark Mitchell 2007-11-28 22:41 ` Richard Sandiford @ 2007-11-28 23:03 ` Rask Ingemann Lambertsen 2007-11-29 6:21 ` Mark Mitchell 2007-11-30 3:56 ` Richard Sandiford 2 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-28 23:03 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 23:03 ` Rask Ingemann Lambertsen @ 2007-11-29 6:21 ` Mark Mitchell 2007-11-30 21:07 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-29 6:21 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-29 6:21 ` Mark Mitchell @ 2007-11-30 21:07 ` Rask Ingemann Lambertsen 2007-11-30 21:08 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-30 21:07 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 21:07 ` Rask Ingemann Lambertsen @ 2007-11-30 21:08 ` Mark Mitchell [not found] ` <20071130211005.GQ17368@sygehus.dk> 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-30 21:08 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
[parent not found: <20071130211005.GQ17368@sygehus.dk>]
* Re: Link tests after GCC_NO_EXECUTABLES [not found] ` <20071130211005.GQ17368@sygehus.dk> @ 2007-12-01 9:48 ` Richard Sandiford 2007-12-01 11:53 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Richard Sandiford @ 2007-12-01 9:48 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 9:48 ` Richard Sandiford @ 2007-12-01 11:53 ` Rask Ingemann Lambertsen 2007-12-01 12:03 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-01 11:53 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 11:53 ` Rask Ingemann Lambertsen @ 2007-12-01 12:03 ` Rask Ingemann Lambertsen 2007-12-01 13:37 ` Andreas Schwab 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-01 12:03 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 12:03 ` Rask Ingemann Lambertsen @ 2007-12-01 13:37 ` Andreas Schwab 2007-12-01 22:35 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Andreas Schwab @ 2007-12-01 13:37 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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." ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 13:37 ` Andreas Schwab @ 2007-12-01 22:35 ` Rask Ingemann Lambertsen 2007-12-02 21:11 ` Mark Mitchell ` (2 more replies) 0 siblings, 3 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-01 22:35 UTC (permalink / raw) To: Andreas Schwab Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 22:35 ` Rask Ingemann Lambertsen @ 2007-12-02 21:11 ` Mark Mitchell 2007-12-05 17:22 ` Rask Ingemann Lambertsen 2007-12-04 14:46 ` Rask Ingemann Lambertsen 2007-12-05 0:10 ` Hans-Peter Nilsson 2 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-02 21:11 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Andreas Schwab, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-02 21:11 ` Mark Mitchell @ 2007-12-05 17:22 ` Rask Ingemann Lambertsen 2007-12-06 0:38 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-05 17:22 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-05 17:22 ` Rask Ingemann Lambertsen @ 2007-12-06 0:38 ` Mark Mitchell 2007-12-06 17:58 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-06 0:38 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-06 0:38 ` Mark Mitchell @ 2007-12-06 17:58 ` Rask Ingemann Lambertsen 2007-12-07 1:37 ` Mark Mitchell 2007-12-07 11:27 ` Richard Sandiford 0 siblings, 2 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-06 17:58 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-06 17:58 ` Rask Ingemann Lambertsen @ 2007-12-07 1:37 ` Mark Mitchell 2007-12-07 15:31 ` Rask Ingemann Lambertsen 2007-12-07 11:27 ` Richard Sandiford 1 sibling, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-07 1:37 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 1:37 ` Mark Mitchell @ 2007-12-07 15:31 ` Rask Ingemann Lambertsen 2007-12-07 18:39 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-07 15:31 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 15:31 ` Rask Ingemann Lambertsen @ 2007-12-07 18:39 ` Mark Mitchell 2007-12-07 21:48 ` Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-07 18:39 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 18:39 ` Mark Mitchell @ 2007-12-07 21:48 ` Rask Ingemann Lambertsen 2007-12-07 21:57 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-07 21:48 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 21:48 ` Rask Ingemann Lambertsen @ 2007-12-07 21:57 ` Mark Mitchell 2007-12-13 22:25 ` [PATCH v2] " Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-07 21:57 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 21:57 ` Mark Mitchell @ 2007-12-13 22:25 ` Rask Ingemann Lambertsen 2007-12-30 13:46 ` Ping " Rask Ingemann Lambertsen 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-13 22:25 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Ping [PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES 2007-12-13 22:25 ` [PATCH v2] " Rask Ingemann Lambertsen @ 2007-12-30 13:46 ` Rask Ingemann Lambertsen 2007-12-30 17:41 ` Paolo Bonzini 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-30 13:46 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Ping [PATCH v2] Re: Link tests after GCC_NO_EXECUTABLES 2007-12-30 13:46 ` Ping " Rask Ingemann Lambertsen @ 2007-12-30 17:41 ` Paolo Bonzini 0 siblings, 0 replies; 83+ messages in thread From: Paolo Bonzini @ 2007-12-30 17:41 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, GCC Patches, rsandifo, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-06 17:58 ` Rask Ingemann Lambertsen 2007-12-07 1:37 ` Mark Mitchell @ 2007-12-07 11:27 ` Richard Sandiford 2007-12-07 15:18 ` Rask Ingemann Lambertsen 1 sibling, 1 reply; 83+ messages in thread From: Richard Sandiford @ 2007-12-07 11:27 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, GCC Patches, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 11:27 ` Richard Sandiford @ 2007-12-07 15:18 ` Rask Ingemann Lambertsen 2007-12-08 11:25 ` Richard Sandiford 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-07 15:18 UTC (permalink / raw) To: Mark Mitchell, GCC Patches, fortran, java-patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-07 15:18 ` Rask Ingemann Lambertsen @ 2007-12-08 11:25 ` Richard Sandiford 0 siblings, 0 replies; 83+ messages in thread From: Richard Sandiford @ 2007-12-08 11:25 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, GCC Patches, fortran, java-patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 22:35 ` Rask Ingemann Lambertsen 2007-12-02 21:11 ` Mark Mitchell @ 2007-12-04 14:46 ` Rask Ingemann Lambertsen 2007-12-05 0:10 ` Hans-Peter Nilsson 2 siblings, 0 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-04 14:46 UTC (permalink / raw) To: Andreas Schwab Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 22:35 ` Rask Ingemann Lambertsen 2007-12-02 21:11 ` Mark Mitchell 2007-12-04 14:46 ` Rask Ingemann Lambertsen @ 2007-12-05 0:10 ` Hans-Peter Nilsson 2007-12-05 0:19 ` Rask Ingemann Lambertsen 2 siblings, 1 reply; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-05 0:10 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-05 0:10 ` Hans-Peter Nilsson @ 2007-12-05 0:19 ` Rask Ingemann Lambertsen 2007-12-05 0:46 ` Hans-Peter Nilsson 0 siblings, 1 reply; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-12-05 0:19 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-05 0:19 ` Rask Ingemann Lambertsen @ 2007-12-05 0:46 ` Hans-Peter Nilsson 0 siblings, 0 replies; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-05 0:46 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-28 18:55 ` Mark Mitchell 2007-11-28 22:41 ` Richard Sandiford 2007-11-28 23:03 ` Rask Ingemann Lambertsen @ 2007-11-30 3:56 ` Richard Sandiford 2007-11-30 5:32 ` Mark Mitchell ` (3 more replies) 2 siblings, 4 replies; 83+ messages in thread From: Richard Sandiford @ 2007-11-30 3:56 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches 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) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 3:56 ` Richard Sandiford @ 2007-11-30 5:32 ` Mark Mitchell 2007-11-30 8:07 ` Benjamin Kosnik 2007-11-30 9:58 ` Rask Ingemann Lambertsen ` (2 subsequent siblings) 3 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-30 5:32 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, libstdc++ 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 5:32 ` Mark Mitchell @ 2007-11-30 8:07 ` Benjamin Kosnik 0 siblings, 0 replies; 83+ messages in thread From: Benjamin Kosnik @ 2007-11-30 8:07 UTC (permalink / raw) To: Mark Mitchell Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, libstdc++ > 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 3:56 ` Richard Sandiford 2007-11-30 5:32 ` Mark Mitchell @ 2007-11-30 9:58 ` Rask Ingemann Lambertsen 2007-11-30 11:41 ` Mark Mitchell ` (2 more replies) 2007-11-30 20:49 ` Rask Ingemann Lambertsen 2008-05-15 21:40 ` Bernd Schmidt 3 siblings, 3 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-30 9:58 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, hp 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 9:58 ` Rask Ingemann Lambertsen @ 2007-11-30 11:41 ` Mark Mitchell 2007-11-30 23:25 ` Rask Ingemann Lambertsen 2007-11-30 13:16 ` Richard Sandiford 2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson 2 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-11-30 11:41 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, hp 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 11:41 ` Mark Mitchell @ 2007-11-30 23:25 ` Rask Ingemann Lambertsen 0 siblings, 0 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-30 23:25 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo, hp 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 9:58 ` Rask Ingemann Lambertsen 2007-11-30 11:41 ` Mark Mitchell @ 2007-11-30 13:16 ` Richard Sandiford 2007-11-30 20:32 ` Rask Ingemann Lambertsen 2007-11-30 21:10 ` Mark Mitchell 2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson 2 siblings, 2 replies; 83+ messages in thread From: Richard Sandiford @ 2007-11-30 13:16 UTC (permalink / raw) To: Rask Ingemann Lambertsen Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 13:16 ` Richard Sandiford @ 2007-11-30 20:32 ` Rask Ingemann Lambertsen 2007-11-30 21:10 ` Mark Mitchell 1 sibling, 0 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-30 20:32 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 13:16 ` Richard Sandiford 2007-11-30 20:32 ` Rask Ingemann Lambertsen @ 2007-11-30 21:10 ` Mark Mitchell 2007-11-30 21:15 ` DJ Delorie 2007-12-01 9:55 ` Richard Sandiford 1 sibling, 2 replies; 83+ messages in thread From: Mark Mitchell @ 2007-11-30 21:10 UTC (permalink / raw) To: Rask Ingemann Lambertsen, Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 21:10 ` Mark Mitchell @ 2007-11-30 21:15 ` DJ Delorie 2007-12-01 9:55 ` Richard Sandiford 1 sibling, 0 replies; 83+ messages in thread From: DJ Delorie @ 2007-11-30 21:15 UTC (permalink / raw) To: mark; +Cc: rask, mark, bernds_cb1, jzhang918, gcc, gcc-patches, hp, rsandifo > 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 21:10 ` Mark Mitchell 2007-11-30 21:15 ` DJ Delorie @ 2007-12-01 9:55 ` Richard Sandiford 2007-12-02 21:01 ` Mark Mitchell 1 sibling, 1 reply; 83+ messages in thread From: Richard Sandiford @ 2007-12-01 9:55 UTC (permalink / raw) To: Mark Mitchell Cc: Rask Ingemann Lambertsen, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-01 9:55 ` Richard Sandiford @ 2007-12-02 21:01 ` Mark Mitchell 2007-12-03 15:55 ` Richard Sandiford 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2007-12-02 21:01 UTC (permalink / raw) To: Mark Mitchell, Rask Ingemann Lambertsen, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-12-02 21:01 ` Mark Mitchell @ 2007-12-03 15:55 ` Richard Sandiford 0 siblings, 0 replies; 83+ messages in thread From: Richard Sandiford @ 2007-12-03 15:55 UTC (permalink / raw) To: Mark Mitchell Cc: Rask Ingemann Lambertsen, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, hp, dj 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 9:58 ` Rask Ingemann Lambertsen 2007-11-30 11:41 ` Mark Mitchell 2007-11-30 13:16 ` Richard Sandiford @ 2007-12-03 14:40 ` Hans-Peter Nilsson 2007-12-03 16:07 ` Richard Sandiford 2007-12-03 16:59 ` Geoff Keating 2 siblings, 2 replies; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-03 14:40 UTC (permalink / raw) To: Rask Ingemann Lambertsen; +Cc: GCC Patches, Geoff Keating, rsandifo (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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson @ 2007-12-03 16:07 ` Richard Sandiford 2007-12-03 22:43 ` Hans-Peter Nilsson 2007-12-03 16:59 ` Geoff Keating 1 sibling, 1 reply; 83+ messages in thread From: Richard Sandiford @ 2007-12-03 16:07 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Rask Ingemann Lambertsen, GCC Patches, Geoff Keating 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-03 16:07 ` Richard Sandiford @ 2007-12-03 22:43 ` Hans-Peter Nilsson 0 siblings, 0 replies; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-03 22:43 UTC (permalink / raw) To: Richard Sandiford; +Cc: Rask Ingemann Lambertsen, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson 2007-12-03 16:07 ` Richard Sandiford @ 2007-12-03 16:59 ` Geoff Keating 2007-12-03 22:39 ` Hans-Peter Nilsson 1 sibling, 1 reply; 83+ messages in thread From: Geoff Keating @ 2007-12-03 16:59 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Rask Ingemann Lambertsen, GCC Patches, rsandifo 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-03 16:59 ` Geoff Keating @ 2007-12-03 22:39 ` Hans-Peter Nilsson 2007-12-04 6:52 ` Geoff Keating 0 siblings, 1 reply; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-03 22:39 UTC (permalink / raw) To: Geoff Keating; +Cc: Rask Ingemann Lambertsen, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-03 22:39 ` Hans-Peter Nilsson @ 2007-12-04 6:52 ` Geoff Keating 2007-12-04 22:26 ` btest-gcc.sh patch ping Hans-Peter Nilsson 2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther 0 siblings, 2 replies; 83+ messages in thread From: Geoff Keating @ 2007-12-04 6:52 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Rask Ingemann Lambertsen, GCC Patches [-- 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 --] ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping 2007-12-04 6:52 ` Geoff Keating @ 2007-12-04 22:26 ` Hans-Peter Nilsson 2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther 1 sibling, 0 replies; 83+ messages in thread From: Hans-Peter Nilsson @ 2007-12-04 22:26 UTC (permalink / raw) To: Geoff Keating; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2007-12-04 6:52 ` Geoff Keating 2007-12-04 22:26 ` btest-gcc.sh patch ping Hans-Peter Nilsson @ 2009-03-28 14:10 ` Richard Guenther 2009-03-28 20:37 ` Geoff Keating 1 sibling, 1 reply; 83+ messages in thread From: Richard Guenther @ 2009-03-28 14:10 UTC (permalink / raw) To: Geoff Keating; +Cc: Hans-Peter Nilsson, Rask Ingemann Lambertsen, GCC Patches 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES 2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther @ 2009-03-28 20:37 ` Geoff Keating 0 siblings, 0 replies; 83+ messages in thread From: Geoff Keating @ 2009-03-28 20:37 UTC (permalink / raw) To: Richard Guenther Cc: Hans-Peter Nilsson, Rask Ingemann Lambertsen, GCC Patches [-- 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 --] ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 3:56 ` Richard Sandiford 2007-11-30 5:32 ` Mark Mitchell 2007-11-30 9:58 ` Rask Ingemann Lambertsen @ 2007-11-30 20:49 ` Rask Ingemann Lambertsen 2008-05-15 21:40 ` Bernd Schmidt 3 siblings, 0 replies; 83+ messages in thread From: Rask Ingemann Lambertsen @ 2007-11-30 20:49 UTC (permalink / raw) To: Mark Mitchell, Bernd Schmidt, Jie Zhang, gcc, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-30 3:56 ` Richard Sandiford ` (2 preceding siblings ...) 2007-11-30 20:49 ` Rask Ingemann Lambertsen @ 2008-05-15 21:40 ` Bernd Schmidt 2008-05-15 23:02 ` Richard Sandiford 3 siblings, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2008-05-15 21:40 UTC (permalink / raw) To: Mark Mitchell, Jie Zhang, GCC Patches, rsandifo 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-05-15 21:40 ` Bernd Schmidt @ 2008-05-15 23:02 ` Richard Sandiford 2008-05-15 23:10 ` Bernd Schmidt 0 siblings, 1 reply; 83+ messages in thread From: Richard Sandiford @ 2008-05-15 23:02 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Mark Mitchell, Jie Zhang, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-05-15 23:02 ` Richard Sandiford @ 2008-05-15 23:10 ` Bernd Schmidt 2008-05-16 0:18 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Bernd Schmidt @ 2008-05-15 23:10 UTC (permalink / raw) To: Mark Mitchell, Jie Zhang, GCC Patches, rdsandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-05-15 23:10 ` Bernd Schmidt @ 2008-05-16 0:18 ` Mark Mitchell 2008-05-16 2:21 ` Joseph S. Myers 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2008-05-16 0:18 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Jie Zhang, GCC Patches, rdsandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-05-16 0:18 ` Mark Mitchell @ 2008-05-16 2:21 ` Joseph S. Myers 2008-06-18 21:05 ` Ralf Wildenhues 0 siblings, 1 reply; 83+ messages in thread From: Joseph S. Myers @ 2008-05-16 2:21 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bernd Schmidt, Jie Zhang, GCC Patches, rdsandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-05-16 2:21 ` Joseph S. Myers @ 2008-06-18 21:05 ` Ralf Wildenhues 2008-06-19 3:57 ` Mark Mitchell 0 siblings, 1 reply; 83+ messages in thread From: Ralf Wildenhues @ 2008-06-18 21:05 UTC (permalink / raw) To: Joseph S. Myers Cc: Mark Mitchell, Bernd Schmidt, Jie Zhang, GCC Patches, rdsandiford <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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-06-18 21:05 ` Ralf Wildenhues @ 2008-06-19 3:57 ` Mark Mitchell 2008-07-07 20:14 ` Ralf Wildenhues 0 siblings, 1 reply; 83+ messages in thread From: Mark Mitchell @ 2008-06-19 3:57 UTC (permalink / raw) To: Ralf Wildenhues, Joseph S. Myers, Mark Mitchell, Bernd Schmidt, Jie Zhang, GCC Patches, rdsandiford 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2008-06-19 3:57 ` Mark Mitchell @ 2008-07-07 20:14 ` Ralf Wildenhues 0 siblings, 0 replies; 83+ messages in thread From: Ralf Wildenhues @ 2008-07-07 20:14 UTC (permalink / raw) To: Mark Mitchell Cc: Joseph S. Myers, Bernd Schmidt, Jie Zhang, GCC Patches, rdsandiford <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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Link tests after GCC_NO_EXECUTABLES 2007-11-27 22:58 ` Bernd Schmidt 2007-11-27 23:17 ` Mark Mitchell @ 2007-11-28 8:54 ` Joseph S. Myers 1 sibling, 0 replies; 83+ messages in thread From: Joseph S. Myers @ 2007-11-28 8:54 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Mark Mitchell, Jie Zhang, gcc, GCC Patches 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
end of thread, other threads:[~2009-03-28 19:51 UTC | newest] Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <46EFBCC1.6070200@gmail.com> [not found] ` <46EFC383.7020503@t-online.de> [not found] ` <46EFC9E9.7090201@gmail.com> [not found] ` <46EFCEF9.3060304@t-online.de> [not found] ` <46EFCF7A.2080704@gmail.com> [not found] ` <46EFD236.6080907@t-online.de> [not found] ` <46EFDA4D.3070006@gmail.com> 2007-11-27 15:35 ` Link tests after GCC_NO_EXECUTABLES Bernd Schmidt 2007-11-27 22:17 ` Mark Mitchell 2007-11-27 22:40 ` Bernd Schmidt 2007-11-27 22:43 ` Mark Mitchell 2007-11-27 22:58 ` Bernd Schmidt 2007-11-27 23:17 ` Mark Mitchell 2007-11-28 0:23 ` Bernd Schmidt 2007-11-28 0:33 ` Mark Mitchell 2007-11-28 1:03 ` Bernd Schmidt 2007-11-28 1:24 ` Mark Mitchell 2007-11-28 6:34 ` Bernd Schmidt 2007-11-28 10:37 ` Mark Mitchell 2007-11-28 15:47 ` Bernd Schmidt 2007-11-28 8:16 ` Joseph S. Myers 2007-11-28 10:01 ` Mark Mitchell 2007-11-28 11:37 ` Joseph S. Myers 2007-11-28 11:40 ` Mark Mitchell 2007-11-28 15:37 ` Bernd Schmidt 2007-11-28 13:07 ` Richard Sandiford 2007-11-28 16:06 ` Rask Ingemann Lambertsen 2007-11-28 16:59 ` Daniel Jacobowitz 2007-11-28 18:55 ` Mark Mitchell 2007-11-28 22:41 ` Richard Sandiford 2007-11-28 23:03 ` Rask Ingemann Lambertsen 2007-11-29 6:21 ` Mark Mitchell 2007-11-30 21:07 ` Rask Ingemann Lambertsen 2007-11-30 21:08 ` Mark Mitchell [not found] ` <20071130211005.GQ17368@sygehus.dk> 2007-12-01 9:48 ` Richard Sandiford 2007-12-01 11:53 ` Rask Ingemann Lambertsen 2007-12-01 12:03 ` Rask Ingemann Lambertsen 2007-12-01 13:37 ` Andreas Schwab 2007-12-01 22:35 ` Rask Ingemann Lambertsen 2007-12-02 21:11 ` Mark Mitchell 2007-12-05 17:22 ` Rask Ingemann Lambertsen 2007-12-06 0:38 ` Mark Mitchell 2007-12-06 17:58 ` Rask Ingemann Lambertsen 2007-12-07 1:37 ` Mark Mitchell 2007-12-07 15:31 ` Rask Ingemann Lambertsen 2007-12-07 18:39 ` Mark Mitchell 2007-12-07 21:48 ` Rask Ingemann Lambertsen 2007-12-07 21:57 ` Mark Mitchell 2007-12-13 22:25 ` [PATCH v2] " Rask Ingemann Lambertsen 2007-12-30 13:46 ` Ping " Rask Ingemann Lambertsen 2007-12-30 17:41 ` Paolo Bonzini 2007-12-07 11:27 ` Richard Sandiford 2007-12-07 15:18 ` Rask Ingemann Lambertsen 2007-12-08 11:25 ` Richard Sandiford 2007-12-04 14:46 ` Rask Ingemann Lambertsen 2007-12-05 0:10 ` Hans-Peter Nilsson 2007-12-05 0:19 ` Rask Ingemann Lambertsen 2007-12-05 0:46 ` Hans-Peter Nilsson 2007-11-30 3:56 ` Richard Sandiford 2007-11-30 5:32 ` Mark Mitchell 2007-11-30 8:07 ` Benjamin Kosnik 2007-11-30 9:58 ` Rask Ingemann Lambertsen 2007-11-30 11:41 ` Mark Mitchell 2007-11-30 23:25 ` Rask Ingemann Lambertsen 2007-11-30 13:16 ` Richard Sandiford 2007-11-30 20:32 ` Rask Ingemann Lambertsen 2007-11-30 21:10 ` Mark Mitchell 2007-11-30 21:15 ` DJ Delorie 2007-12-01 9:55 ` Richard Sandiford 2007-12-02 21:01 ` Mark Mitchell 2007-12-03 15:55 ` Richard Sandiford 2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson 2007-12-03 16:07 ` Richard Sandiford 2007-12-03 22:43 ` Hans-Peter Nilsson 2007-12-03 16:59 ` Geoff Keating 2007-12-03 22:39 ` Hans-Peter Nilsson 2007-12-04 6:52 ` Geoff Keating 2007-12-04 22:26 ` btest-gcc.sh patch ping Hans-Peter Nilsson 2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther 2009-03-28 20:37 ` Geoff Keating 2007-11-30 20:49 ` Rask Ingemann Lambertsen 2008-05-15 21:40 ` Bernd Schmidt 2008-05-15 23:02 ` Richard Sandiford 2008-05-15 23:10 ` Bernd Schmidt 2008-05-16 0:18 ` Mark Mitchell 2008-05-16 2:21 ` Joseph S. Myers 2008-06-18 21:05 ` Ralf Wildenhues 2008-06-19 3:57 ` Mark Mitchell 2008-07-07 20:14 ` Ralf Wildenhues 2007-11-28 8:54 ` Joseph S. Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).