Bug#616362: gcc-snapshot: link failure with gnat (/usr/bin/ld: cannot find -laddr2line)
Євгеній Мещеряков eu...@debian.org writes: Hello, I reported that bug because I tried to compile spark-gpl. I'm interested in that; I'm sure others are, too. Could you please announce your effort on debian-...@lists.debian.org? It must be possible to join efforts. IIUC, the main stumbling block is, or was, that some SPARK tools are written in Prolog and require a non-free Prolog compiler. Do you know anything about that? Compilation failed with stack overflow or invalid memory access. It was compiled fine with gcc-snapshot, but linking failed. So I guess the bug with stack overflow was fixed somewhere between gcc-4.4 and 4.6. Or maybe it was introduced by patches... This bug has quite a complex history. Upstream (AdaCore) supports symbolic tracebacks through a library called libaddr2line.a, which they produce from their own patched binutils sources. This has been so for as long as I can remember. I patched gnat 3.15p back in 2005 to support symbolic tracebacks without requiring this special library (doing a fork()/exec() of addr2line instead). This patch was broken by an upstream change in gnat-4.3 and re-fixed in gnat-4.4 (=4.4.4-4). 3 березня 2011 о 21:07 +0100 Ludovic Brenta написав(-ла): This is because the patch ada-symbolic-tracebacks.diff has not been ported to gcc-snapshot. I see that this patch is present in gcc-snapshot source, and it is even applied (at least at the beginning of the build, I do not have enough free time now to build it all). But installed g-trasym.adb really contains pragma Linker_Options (-laddr2line);. Is it intended behaviour or there is something wrong here? Yes, this is wrong. Debian has no such library as libaddr2line, so the Linker_Options should not be there. The patch ada-symbolic-tracebacks.diff normally removes it but, as I said, it has not yet been ported to gcc-snapshot, so it leaves the sources in an inconsistent state. BTW do you think it is worth it to submit bug reports to the gnat bugzilla? I see there are many reports from years ago with no comment. Is it used at all by upstream? Submitting bugs in the bugzilla is always a good idea. AdaCore look at these bugs occasionally but not systematically; they have already fixed a majority of them (see the closed PRs). (It is only natural that they give priority to bugs submitted by paying customers). In addition, contributors outside AdaCore occasionally step in. Thanks for your interest. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj0swmr8@ludovic-brenta.org
Results for 4.5.2 (Debian 4.5.2-5) testsuite on x86_64-pc-linux-gnu
LAST_UPDATED: Sat Mar 5 01:31:43 UTC 2011 (revision 170696) Target: x86_64-linux-gnu gcc version 4.5.2 (Debian 4.5.2-5) Native configuration is x86_64-pc-linux-gnu === g++ tests === Running target unix UNRESOLVED: attribute_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared UNRESOLVED: pragma_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared UNRESOLVED: selfassign.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -O -DIN_GCC -fPIC -shared UNRESOLVED: dumb_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared UNRESOLVED: header_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared === g++ Summary for unix === # of expected passes23031 # of expected failures 151 # of unresolved testcases 5 # of unsupported tests 303 Running target unix/-fstack-protector UNRESOLVED: attribute_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared UNRESOLVED: pragma_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -DIN_GCC -fPIC -shared UNRESOLVED: selfassign.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../libcpp/include -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../intl -O -DIN_GCC -fPIC -shared UNRESOLVED: dumb_plugin.c compilation, -I. -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/build/gcc/testsuite/g++/../../../gcc -I/scratch/packages/gcc/4.5/gcc-4.5-4.5.2/src/gcc/testsuite/../../include
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Dave, What's your opinion on switching to GCC 4.5 for HPPA? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinznkgbhpaqc7hd6peyppr8da+1iponh1im6...@mail.gmail.com
Re: GCC-4.5 as the default for (at least some) architectures
On Wed, 02 Mar 2011 02:34:01 +0100 Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). GCC4.5 still segfault when i try to compile, all previous version work fine (without any kind of warning), maybe my GCC4.5 isn't the right one (4.5.2-4), but i'm not so sure can be deployed as default (compiling on i386) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307015837.a9d87800.syt...@sythos.net
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within th= e next two weeks before more transitions start. =A0GCC-4.5 is already used as th= e default compiler for almost any other distribution, so there shouldn't be many su= rprises on at least the common architectures. =A0About 50% of the build failures = exposed by GCC-4.5 are fixed [1]. =A0I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object f= iles linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like t= o ask which architectures should do the switch together with the four architect= ures mentioned above, and which not, and which ones should be better delayed, = or dropped. Dave, What's your opinion on switching to GCC 4.5 for HPPA? Do it! I have built glibc with it and all my recent kernel have been with 4.5. I'm not aware of any new issues with 4.5 and a number of things are fixed. For kernel builds, the following patch must be included: 2010-12-18 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/46915 * config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead of next_real_insn. Search forward checking for both ASM_INPUT and ASM_OPERANDS asms until exit condition is found. (branch_needs_nop_p): Likewise. (use_skip_p): New function. (output_cbranch): Use use_skip_p. (output_bb, output_bvb): Likewise. There are some other bug fixes in 4.6 that might need back porting. We also need this binutils change: 2011-02-18 John David Anglin dave.ang...@nrc-cnnrc.gc.ca PR ld/12376 emulparams/hppalinux.sh (DATA_ADDR): Define. (SHLIB_DATA_ADDR): Likewise. This should eliminate cache issues arising from non equivalent aliasing. Hopefully, the above will help resolve some of the build and kernel issues that blocked squeeze. I personally don't know what the critical blockers were. If they involve GCC or binutils, I'm willing to take a look. I'm sure a number of things have been magically fixed by updates to the middle-end. The biggest issue is the callee copies args on HPPA and this differs from most other targets. Regards, Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307013751.74c8c5...@hiauly1.hia.nrc.ca
