Re: -B vs Multilib
On Wed, Mar 12, 2008 at 10:44:48PM +1100, Greg Schafer wrote: Currently, -B doesn't add the multilib search paths when processing startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in $prefix/lib/../lib64 Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes do actually process the multilibs. Is there any good reason why -B needs to be different? Maybe there are assumptions in the GCC build itself that would break if this were to change. Ok, finally got around to trying some builds. The change I tested was this: diff -Naur gcc-4.3.0.orig/gcc/gcc.c gcc-4.3.0/gcc/gcc.c --- gcc-4.3.0.orig/gcc/gcc.c2008-03-02 22:55:19.0 + +++ gcc-4.3.0/gcc/gcc.c 2008-03-16 21:39:07.0 + @@ -3854,7 +3854,7 @@ add_prefix (exec_prefixes, value, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); add_prefix (startfile_prefixes, value, NULL, - PREFIX_PRIORITY_B_OPT, 0, 0); + PREFIX_PRIORITY_B_OPT, 0, 1); add_prefix (include_prefixes, value, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); n_switches++; Initial signs were encouraging because a standard x86_64 bootstrap with multilib enabled was successful. However, some non-standard build scenarios resulted in build failure when building the 32-bit libgomp (configure test failed to find -lgcc). It seems there are indeed some subtleties introduced by the above as evidenced by this snippet of diffed -print-search-dirs -m32 output: -/temptools/src/gcc-build/./gcc/32/ +/temptools/src/gcc-build/./gcc/../lib/ Therefore, for the time being I withdraw any proposal to modify the -B behaviour. T'is a shame though, because it has the potential to solve the other 4.3 driver problem I reported earlier.. Regards Greg
-B vs Multilib
Hi, Currently, -B doesn't add the multilib search paths when processing startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in $prefix/lib/../lib64 Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes do actually process the multilibs. Is there any good reason why -B needs to be different? Maybe there are assumptions in the GCC build itself that would break if this were to change. As you can probably tell, I haven't yet tried a build with this changed but was just wondering if anyone knew the rationale for the current -B behaviour WRT startfiles and/or whether it's just an oversight. Thanks Greg
Re: Possible GCC 4.3 driver regression caused by your patch
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote: Greg Schafer wrote: Hi Carlos and Mark, Your Relocated compiler should not look in $prefix patch here: http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib What options did you use to configure the compiler? Could you double check your host system is actually i686-pc-linux-gnu? When you say breaks my build, what error are you seeing? The issue is now filed as http://gcc.gnu.org/PR35532 It would be appreciated if the responsible Codesourcery folks could address this regression. Thanks Greg
Re: Possible GCC 4.3 driver regression caused by your patch
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote: Greg Schafer wrote: Hi Carlos and Mark, Your Relocated compiler should not look in $prefix patch here: http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib What options did you use to configure the compiler? Could you double check your host system is actually i686-pc-linux-gnu? When you say breaks my build, what error are you seeing? Hi Carlos, The problem boils down to this: - when xgcc is run from $objdir, GCC thinks it is a relocated compiler - your patch changed the behaviour of relocated compilers - therefore your patch also changed the behaviour of GCC when it is run from $objdir eg: when building the target libs. This is the key point that breaks my build. The following patch restores the old behaviour and fixes my build. I suspect what is really needed is for GCC to somehow differentiate when it is being run from $objdir and when it is truly relocated. Thoughts? diff -Naur gcc-4.3.0-RC-20080222.orig/gcc/gcc.c gcc-4.3.0-RC-20080222/gcc/gcc.c --- gcc-4.3.0-RC-20080222.orig/gcc/gcc.c2008-01-24 18:57:12.0 + +++ gcc-4.3.0-RC-20080222/gcc/gcc.c 2008-03-02 06:07:36.0 + @@ -6370,6 +6370,11 @@ machine_suffix, standard_startfile_prefix, NULL), NULL, PREFIX_PRIORITY_LAST, 0, 1); + add_prefix (startfile_prefixes, + concat (standard_exec_prefix, + machine_suffix, + standard_startfile_prefix, NULL), + NULL, PREFIX_PRIORITY_LAST, 0, 1); } /* Sysrooted prefixes are relocated because target_system_root is For the record, the scenario I quoted initially was contrived to demonstrate the problem. The real breakage happens in a slightly more complicated procedure that involves bootstrapping a 64-bit toolchain from a 32-bit host. Thanks Greg
Possible GCC 4.3 driver regression caused by your patch
Hi Carlos and Mark, Your Relocated compiler should not look in $prefix patch here: http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib Compare the following -v output snippets to demonstrate the problem: GCC 4.2.3 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /mnt/sysroot/temptools/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /mnt/sysroot/temptools/bin/../lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crt1.o GCC 4.3.0-RC1 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /temptools/src/gcc-build/./gcc/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /usr/lib/crt1.o NOTE - I can try to work around the problem by defining STANDARD_STARTFILE_PREFIX_1 and define STANDARD_STARTFILE_PREFIX_2 to in the target headers but then the build fails when linking libgcc_s.so.1. /temptools/i686-pc-linux-gnu/bin/ld: crti.o: No such file: No such file or directory I realize my scenario is slightly non-standard, but nevertheless, I'd be grateful if you could pass comment on whether this is a regression or not. I haven't relocated anything. All I've done is try to build a native GCC with --prefix=/temptools which used to work fine. Thanks for any help. Thanks Greg
4.3 build failure in driver-i386.c
Hi,
driver-i386.s: Assembler messages:
driver-i386.s:2454: Error: invalid character '{' in mnemonic
driver-i386.s:2455: Error: invalid character '{' in mnemonic
driver-i386.s:2456: Error: invalid character '{' in mnemonic
driver-i386.s:2457: Error: invalid character '{' in mnemonic
driver-i386.s:2458: Error: invalid character '{' in mnemonic
driver-i386.s:2459: Error: invalid character '{' in mnemonic
driver-i386.s:2460: Error: invalid character '{' in mnemonic
driver-i386.s:2461: Error: invalid character '{' in mnemonic
driver-i386.s:2462: Error: invalid character '{' in mnemonic
driver-i386.s:2463: Error: invalid character '{' in mnemonic
This is on an ancient distro (don't ask..) i.e. RedHat 6.2. (4.2.3 builds
fine so this is somewhat of a regression...)
Looking at the -save-temps output, it seems the old assembler is choking
on this syntax from __get_cpuid_max() in cpuid.h:
.stabn 68,0,91,.LM210-__get_cpuid_max
.LM210:
#APP
pushf{l|d}
pushf{l|d}
pop{l} %eax
mov{l} {%eax, %edx|%edx, %eax}
xor{l} {$2097152, %eax|%eax, $2097152}
push{l} %eax
popf{l|d}
pushf{l|d}
pop{l} %eax
popf{l|d}
#NO_APP
It's kind of unfortunate for the build to break in this way. Is there any
hope for some kind of fix or workaround? I realize ancient distros are not
a priority, but still
Thanks
Greg
Re: build failure, GMP not available
Mark Mitchell wrote: I don't believe there's a serious problem with the concept, as long as ./configure; make; make install for GMP DTRT. If you can do it for GCC, you can do it for a library it uses too. Just another data point. I tried building GMP on an i686-pc-linux-gnu Ubuntu system (but running on AMD64 hardware). The GMP configure script is apparently too smart for its own good because it detected my build system as x86_64-pc-linux-gnu and configure failed. I had to pass --build=i686-linux to get configure to complete. Yes, I should probably send a problem report to the GMP dev's.. Regards Greg -- http://www.diy-linux.org/
Re: GCC-4.1.x include/ssl/*.h ??
Mark Mitchell wrote: This will be the final patch for GCC 4.1.0. I plan to work through the release checklist tonight. As always, the official announcement will follow after the release has had time to make it to the mirrors. Just a word of warning about this patch for unsuspecting travellers. It appears to be parallel make unfriendly. (GNU Make 3.80) i.e. running the following command on a dual cpu system results in a missing `/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include/ssp' directory and no ssp headers. make install -j3 No errors, no nothing. Weird.. It's 100% reproducible here. Remove the -j3 and all is well. I suppose most folks never run `make install' in parallel.. but sometimes it's convenient to just simply: export MAKEFLAGS=-j3 for big compile jobs. Regards Greg -- http://www.diy-linux.org/
Re: GCC 4.1.0 RC1
Mark Mitchell wrote: Please download, build, and test. Please use these tarballs, rather than the current SVN branch, so that we test packaging, and other similar issues. Here it looks good so far on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html Regards Greg
Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux cross compiler...
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote: It looks like you forgot to check the crt*.o files for undefined references. If the gcc/glibc toolchain wasn't built the optimal way, it is possible for crtbegin.o to have register_frame_info and deregister_frame_info calls for C++ EH unwinding which would require libgcc always. If built the optimal way, then the gcc/glibc toolchain will use an alternate method for C++ EH unwinding that does not require crtbegin.o support and hence does not require libgcc. This is why the x86 FC3 is OK. See the USE_PT_GNU_EH_FRAME stuff in gcc/crtstuff.c. Jim, I'd be grateful if you could please clarify what you mean by the optimal way. I assume you mean whether the initial bootstrap cross compiler was built against Glibc headers or not. ie: Glibc headers ARE provided - inhibit_libc NOT defined - optimal Glibc headers ARE NOT provided - inhibit_libc IS defined - suboptimal It seems to me that most Glibc targets can be built either way, but some need a little coaxing, Mips can certainly be built either way out of the box. AFAICT, IA64 is the only target that cannot be built without access to the Glibc headers. Clearly, optimal is best :-) Thanks for any clarification. Regards Greg
Headsup - New PCH Failures on 3.4.x under Linux-2.6.12
Hi This is just a headsup for any folks running 3.4.x testsuite under Linux 2.6.12 kernels (stock Linus). I started seeing new PCH failures after upgrading to this kernel: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01069.html The cause is due to inclusion of the address space randomization patches into 2.6.12 ie: probably the same thing that RH previously called exec-shield-randomize. The PCH support in GCC-3.4.x is apparently incompatible with address space randomization. This PR is relevant: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14206 and probably this one too: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14400 It's possible to disable address space randomization via sysctl or simply: echo 0 /proc/sys/kernel/randomize_va_space GCC-4.x appears unaffected. Regards Greg -- http://www.diy-linux.org/
Re: GCC 3.4.4 RC2
On Sun, May 15, 2005 at 01:54:03AM +0200, Ulrich Weigand wrote: It would appear the problem is this patch: 2005-05-12 Mark Mitchell [EMAIL PROTECTED] 2005-04-04 Mark Mitchell [EMAIL PROTECTED] * testsuite/Makefile.am (check-local): Remove. (curent_symbols.txt): Likewise. (check-abi): Do not depend on current_symbols.txt. * testsuite/Makefile.in: Regenerated. * testsuite/libstdc++-abi/abi.exp: Build current_symbols.txt. 2005-04-01 Mark Mitchell [EMAIL PROTECTED] * testsuite/Makefile.am (noinst_PROGRAMS): Remove. (site.exp): Write out the path to the baseline file. (check-abi): Use DejaGNU. (check-abi-verbose): Remove. * testsuite/Makefile.in: Regenerated. * testsuite/abi_check.cc (main): Check the return value from compare_symbols. * testsuite/testsuite_abi.cc (compare_symbols): Return a value. * testsuite/testsuite_abi.h (compare_symbols): Adjust prototype. * testsuite/libstdc++-abi/abi.exp: New file. 2004-03-19 Phil Edwards [EMAIL PROTECTED] * testsuite/Makefile.am (site.exp): New target, based on that created by automake. Also set libiconv. While using DejaGNU for check-abi might be a good idea in principle, the way it is currently set up means that the 'make check-abi' run will overwrite the libstdc++.log and libstdc++.sum files generated by the main 'make check' run. This is why the results are missing from the test_summary report ... Yes. We used to get: libstdc++-abi.log libstdc++-abi.sum libstdc++.log libstdc++.sum Now we only get: libstdc++.log libstdc++.sum I believe you are correct that `check-abi' is overwriting the main libstdc++ log files. I've opened a BZ so the issue can be tracked: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21577 Regards Greg
Re: GCC 3.4.4 RC2
On Fri, May 13, 2005 at 03:44:59PM -0700, Mark Mitchell wrote: GCC 3.4.4 RC2 is now available here: ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512 There are just a few changes from RC1 to fix critical problems people experienced with RC1. Please download, build, and test. Done. Something went wrong with the libstdc++ testsuite. It doesn't show up in the test results: http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00856.html AFAICT, the libstdc++ testsuite _did_ run, but it doesn't show up. This could be pilot error on my behalf, but I've followed the exact same scripted procedure for ages so I don't think so. Oops, I failed to realise it also happened with RC1: http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00670.html I've run out of time right now and cannot investigate it immediately. Anyone else seeing this? Quick browse of other test results suggests I'm not alone. Maybe there's a BZ already? Dunno. Thanks Greg
Re: GCC 4.0 RC1 Available
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ My test results on i686-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html All looks good except for the libmudflap failures which I'm not sure about.. but browsing the results from others indicates I'm not alone with those. Regards Greg
Re: BOOT_CFLAGS and -fomit-frame-pointer
On Fri, Mar 25, 2005 at 12:06:33PM +0100, Eric Botcazou wrote: What is wrong exactly? Why should 2 different build processes generate the same executable? Is there a (written) rule about this? No, there is no written rule. However, some folks (like me) are concerned with matters of binary reproducibility, and this subtle change in x86 GCC's default behaviour seemed a little suspect (to me at least). Like I said, no big deal. If noone else thinks it's a problem, don't worry. Regards Greg
BOOT_CFLAGS and -fomit-frame-pointer
Hi There are occasions, especially when bootstrapping a whole new World where one needs to build GCC multiple times, that you don't want to be bootstrapping GCC on every invocation, only the first. On x86 with GCC-4 and above, `make bootstrap' results in the compiler being built with `BOOT_CFLAGS = -O2 -g -fomit-frame-pointer' (picked up from config/mh-x86omitfp). However, if performing a non-bootstrap build ie: built with a plain old `make', BOOT_CFLAGS have no effect and the compiler gets built without `-fomit-frame-pointer'. This means you get a different compiler depending on whether you `make bootstrap'ed it or not, which just seems wrong to me. This never used to be the case. Of course, the problem can easily be worked around once you know what's going on.. but that's not the point. Thanks for any comments. Regards Greg
