* AIX library issues @ 2011-10-18 4:48 Perry Smith 2011-10-18 8:30 ` Jonathan Wakely 2011-10-18 15:37 ` David Edelsohn 0 siblings, 2 replies; 13+ messages in thread From: Perry Smith @ 2011-10-18 4:48 UTC (permalink / raw) To: gcc I've discovered an issue which I can't believe I'm the first to bump in to. But I've checked older gcc installs and find the same issue. I did a brief internet search and found sorta similar issues but I'm not sure if they explained it as I see it. I bumped into this while trying to build lzma. What follows is from a gcc 4.5.2 build using gcc 4.5.2 to compile it running AIX 6.1 TL05 SP06. But, as I said, I've compared this to output produced by a gcc 4.3.1 running on AIX 5.3 with the same results. On AIX, there is a tool called dump. dump -H <file> dumps out the header of the loader section. When I link lzma and try to run it, it dies with a long error (that I won't post). In essence it boils down to this: lzma needs libstdc++. In that archive is one shared object. The loader can find lzma and can find the libstdc++ object but it can not load either because libstc++ depends upon another library that the loader can not find. Here is why: dump -H libstdc++.so.6 ./powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs/libstdc++.so.6.orig: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCent LENidSTR 0x00000001 0x00000fe0 0x000033b6 0x000000da #IMPfilID OFFidSTR LENstrTBL OFFstrTBL 0x00000003 0x0003e9a8 0x0002dec7 0x0003ea82 ***Import File Strings*** INDEX PATH BASE MEMBER 0 /usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src:/usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs:/usr/work/build/gcc-4.5.2/./gcc:/usr/lib:/lib 1 libc.a shr.o 2 libgcc_s.a shr.o What this is telling us is that libstdc++.so.6 needs libc.a(shr.o) and libgcc_s.a(shr.o) and it is also telling us that when libc.a(shr.o) and libgcc_s.a(shr.o) is needed at run time, the list of places searched is the list of directories listed in entry 0. But the list is the list of where the library is built -- not where it (or more importantly where libgcc_s.a) will be installed. When I configured and built this gcc, prefix path was set to /gsa/ausgsa/projects/r/ruby. Here are the first few lines of my config.log: /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-languages=c,c++ I have told configure that /gsa/ausgsa/projects/r/ruby is the place I plan to install this compiler. Yet its search path does not include this path at all. For most (perhaps all) of the other shared objects, the path doesn't make THAT much difference because the only library needed is libc.a and it will be found in /usr/lib. The executables suffer from the same thing. Again, it doesn't seem to matter since they only include libc.a. I've been told but I do not know for sure that libtool understands AIX's peculiarities. In particular, what needs to happen is a relink needs to be done. The executables and libraries are correct for testing the results in the current directory. But they are not correct when the final result is moved into the place it was designed to go in to. The good news is that a program compiled with gcc produces an object file with the proper path so all the programs produced from the final gcc are correct. I'm fairly sure that this isn't a pilot error (I somehow botched the call to configure or something like that) but I sure would be happy to find out it was my fault. This seems like a rather hard nut to crack. I hope all this is clear. I'm more than happy to help out in solving this. Thank you, pedz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-18 4:48 AIX library issues Perry Smith @ 2011-10-18 8:30 ` Jonathan Wakely 2011-10-18 10:28 ` Jonathan Wakely 2011-10-18 15:37 ` David Edelsohn 1 sibling, 1 reply; 13+ messages in thread From: Jonathan Wakely @ 2011-10-18 8:30 UTC (permalink / raw) To: Perry Smith; +Cc: gcc On 18 October 2011 03:05, Perry Smith wrote: > I've discovered an issue which I can't believe I'm the first to bump > in to. Isn't this covered by these FAQs? http://gcc.gnu.org/faq.html#rpath http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-18 8:30 ` Jonathan Wakely @ 2011-10-18 10:28 ` Jonathan Wakely 0 siblings, 0 replies; 13+ messages in thread From: Jonathan Wakely @ 2011-10-18 10:28 UTC (permalink / raw) To: Perry Smith; +Cc: gcc On 18 October 2011 09:21, Jonathan Wakely wrote: > On 18 October 2011 03:05, Perry Smith wrote: >> I've discovered an issue which I can't believe I'm the first to bump >> in to. > > Isn't this covered by these FAQs? > http://gcc.gnu.org/faq.html#rpath > http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths > See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354 although if AIX doesn't support $ORIGIN then the suggested configure-time option wouldn't be so useful, as the path couldn't be relative and the gcc installation wouldn't be relocatable. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-18 4:48 AIX library issues Perry Smith 2011-10-18 8:30 ` Jonathan Wakely @ 2011-10-18 15:37 ` David Edelsohn 2011-10-24 0:59 ` Perry Smith 1 sibling, 1 reply; 13+ messages in thread From: David Edelsohn @ 2011-10-18 15:37 UTC (permalink / raw) To: Perry Smith; +Cc: gcc On Mon, Oct 17, 2011 at 10:05 PM, Perry Smith <pedzsan@gmail.com> wrote: > dump -H libstdc++.so.6 > > ./powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs/libstdc++.so.6.orig: > > ***Loader Section*** > Loader Header Information > VERSION# #SYMtableENT #RELOCent LENidSTR > 0x00000001 0x00000fe0 0x000033b6 0x000000da > > #IMPfilID OFFidSTR LENstrTBL OFFstrTBL > 0x00000003 0x0003e9a8 0x0002dec7 0x0003ea82 > > > ***Import File Strings*** > INDEX PATH BASE MEMBER > 0 /usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src:/usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs:/usr/work/build/gcc-4.5.2/./gcc:/usr/lib:/lib > 1 libc.a shr.o > 2 libgcc_s.a shr.o > > What this is telling us is that libstdc++.so.6 needs libc.a(shr.o) and > libgcc_s.a(shr.o) and it is also telling us that when libc.a(shr.o) > and libgcc_s.a(shr.o) is needed at run time, the list of places > searched is the list of directories listed in entry 0. But the list > is the list of where the library is built -- not where it (or more > importantly where libgcc_s.a) will be installed. When I configured > and built this gcc, prefix path was set to > /gsa/ausgsa/projects/r/ruby. > > Here are the first few lines of my config.log: > > /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-languages=c,c++ AIX inserts the list of libraries provided with -L options on the link command line into the default search path. If you want, you can edit libtool created for libstdc++ to add -Wl,-blibpath:/gsa/ausgsa/projects/r/ruby/lib:/usr/lib:/lib and relink libstdc++ (or edit the path in the shared object header directly). - David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-18 15:37 ` David Edelsohn @ 2011-10-24 0:59 ` Perry Smith 2011-10-24 2:36 ` David Edelsohn 0 siblings, 1 reply; 13+ messages in thread From: Perry Smith @ 2011-10-24 0:59 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Oct 18, 2011, at 9:59 AM, David Edelsohn wrote: > On Mon, Oct 17, 2011 at 10:05 PM, Perry Smith <pedzsan@gmail.com> wrote: > >> dump -H libstdc++.so.6 >> >> ... >> /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-languages=c,c++ > > AIX inserts the list of libraries provided with -L options on the link > command line into the default search path. If you want, you can edit > libtool created for libstdc++ to add > -Wl,-blibpath:/gsa/ausgsa/projects/r/ruby/lib:/usr/lib:/lib and relink > libstdc++ (or edit the path in the shared object header directly). I'm working on a real solution to this but bumped into a question: libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a. The first two do not present a problem. But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread). Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread). My question is: which libgcc_s.a should I link to? (this question is for each of the four versions of libgomp.so.1). Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken). So, this may be a question that has never been asked or answered. My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc. But I notice that it will always include pthread so that is what caused me to pause and ask. Part of me wonders if the two non-pthread versions of libgomp make any sense. I don't really know anything about libgomp. Thank you for your time pedz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-24 0:59 ` Perry Smith @ 2011-10-24 2:36 ` David Edelsohn 2011-10-24 9:45 ` Perry Smith [not found] ` <5FB999D3-E0FA-4AC7-A26A-DAA4397D833F@gmail.com> 0 siblings, 2 replies; 13+ messages in thread From: David Edelsohn @ 2011-10-24 2:36 UTC (permalink / raw) To: Perry Smith; +Cc: gcc On Sun, Oct 23, 2011 at 10:16 AM, Perry Smith <pedzsan@gmail.com> wrote: > libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a. The first two do not present a problem. But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread). > > Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread). > > My question is: which libgcc_s.a should I link to? (this question is for each of the four versions of libgomp.so.1). > > Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken). So, this may be a question that has never been asked or answered. > > My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc. But I notice that it will always include pthread so that is what caused me to pause and ask. > > Part of me wonders if the two non-pthread versions of libgomp make any sense. I don't really know anything about libgomp. libgomp (-fopenmp) does not make sense without pthreads. -fopenmp implies pthreads. One thing to note: AIX tools default to 32 bit mode, although all systems are 64 bit, unlike GNU/Linux, which defaults to 64 bit mode (on x86-64 and PPC64). Only two of the four libgomp multilibs truly are necessary, but avoiding the non-pthread builds is not worth the trouble. The non-pthread libgomp libraries never will be used, unless GCC is invoked incorrectly. Each library, including libgomp, should list its multilib install directory first, e.g., ppc64 pthread would be -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0/pthread/ppc64:.../lib/pthread/ppc64:/usr/lib:/lib and default would be -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0:.../lib:/usr/lib:/lib The GCC build process and driver directory search process make a lot of assumptions that the system directories follow a Linux/SVR4/Solaris layout. To follow AIX style, the PPC64 and PPC32 non-reentrant (non-pthreads) libraries should be archived into the same file libgomp.a (which never would be referenced) and the reentrant (pthreads) libraries for PPC64 and PPC32 should be archived into libgomp_r.a. The benefit has not been shown to be worth the effort. - David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-24 2:36 ` David Edelsohn @ 2011-10-24 9:45 ` Perry Smith [not found] ` <5FB999D3-E0FA-4AC7-A26A-DAA4397D833F@gmail.com> 1 sibling, 0 replies; 13+ messages in thread From: Perry Smith @ 2011-10-24 9:45 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Oct 23, 2011, at 1:59 PM, David Edelsohn wrote: > On Sun, Oct 23, 2011 at 10:16 AM, Perry Smith <pedzsan@gmail.com> wrote: > >> libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a. The first two do not present a problem. But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread). >> >> Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread). >> >> My question is: which libgcc_s.a should I link to? (this question is for each of the four versions of libgomp.so.1). >> >> Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken). So, this may be a question that has never been asked or answered. >> >> My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc. But I notice that it will always include pthread so that is what caused me to pause and ask. >> >> Part of me wonders if the two non-pthread versions of libgomp make any sense. I don't really know anything about libgomp. > > libgomp (-fopenmp) does not make sense without pthreads. -fopenmp > implies pthreads. > > One thing to note: AIX tools default to 32 bit mode, although all > systems are 64 bit, unlike GNU/Linux, which defaults to 64 bit mode > (on x86-64 and PPC64). > > Only two of the four libgomp multilibs truly are necessary, but > avoiding the non-pthread builds is not worth the trouble. The > non-pthread libgomp libraries never will be used, unless GCC is > invoked incorrectly. Each library, including libgomp, should list its > multilib install directory first, e.g., ppc64 pthread would be > > -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0/pthread/ppc64:.../lib/pthread/ppc64:/usr/lib:/lib > > and default would be > > -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0:.../lib:/usr/lib:/lib > > The GCC build process and driver directory search process make a lot > of assumptions that the system directories follow a Linux/SVR4/Solaris > layout. To follow AIX style, the PPC64 and PPC32 non-reentrant > (non-pthreads) libraries should be archived into the same file > libgomp.a (which never would be referenced) and the reentrant > (pthreads) libraries for PPC64 and PPC32 should be archived into > libgomp_r.a. The benefit has not been shown to be worth the effort. Thanks David, One more question on this quest (drifting a little more off topic). In my log files I see a lot of these errors: > ld: 0711-768 WARNING: Object ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1, function .std::terminate(): > The branch at address 0x10c is not followed by a recognized no-op > or TOC-reload instruction. The unrecognized instruction is 0x0. The build continues and completes. I just want to make sure that I can safely ignore them. Surfing the web, sometimes I see people flag the as errors and other times not. Thank you again, pedz ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <5FB999D3-E0FA-4AC7-A26A-DAA4397D833F@gmail.com>]
* Re: AIX library issues [not found] ` <5FB999D3-E0FA-4AC7-A26A-DAA4397D833F@gmail.com> @ 2011-10-25 6:31 ` David Edelsohn 2011-10-25 9:13 ` Richard Guenther 0 siblings, 1 reply; 13+ messages in thread From: David Edelsohn @ 2011-10-25 6:31 UTC (permalink / raw) To: Perry Smith; +Cc: gcc On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith <pedzsan@gmail.com> wrote: > One more question on this quest (drifting a little more off topic). > In my log files I see a lot of these errors: > > ld: 0711-768 WARNING: Object > ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1, > function .std::terminate(): > The branch at address 0x10c is not followed by a recognized no-op > or TOC-reload instruction. The unrecognized instruction is 0x0. > > The build continues and completes. I just want to make sure that I can > safely ignore them. Surfing the web, sometimes I see people flag the as > errors and other times not. G++ probably is performing an optimization because the terminate function will not return, so I suspect the error message can be ignored. GCC does not always generate completely conformant AIX assembly code and the AIX assembler does not always follow the rule to be liberal in what it accepts. The biggest problem is that AIX users of GCC ask questions here and on other forums, but do not communicate to IBM AIX Brand executives that the GNU Toolchain on AIX is important. The fact that GCC continues to function at all on AIX seem to place it in the "out of sight, out of mind" category. If you are a developer or ISV or your company uses GCC on AIX, tell your IBM sales representative or executive contact that it is important to your business. - David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-25 6:31 ` David Edelsohn @ 2011-10-25 9:13 ` Richard Guenther 2011-10-25 9:24 ` Arnaud Charlet 0 siblings, 1 reply; 13+ messages in thread From: Richard Guenther @ 2011-10-25 9:13 UTC (permalink / raw) To: David Edelsohn; +Cc: Perry Smith, gcc On Tue, Oct 25, 2011 at 1:25 AM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith <pedzsan@gmail.com> wrote: > >> One more question on this quest (drifting a little more off topic). >> In my log files I see a lot of these errors: >> >> ld: 0711-768 WARNING: Object >> ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1, >> function .std::terminate(): >> The branch at address 0x10c is not followed by a recognized no-op >> or TOC-reload instruction. The unrecognized instruction is 0x0. >> >> The build continues and completes. I just want to make sure that I can >> safely ignore them. Surfing the web, sometimes I see people flag the as >> errors and other times not. > > G++ probably is performing an optimization because the terminate > function will not return, so I suspect the error message can be > ignored. > > GCC does not always generate completely conformant AIX assembly code > and the AIX assembler does not always follow the rule to be liberal in > what it accepts. > > The biggest problem is that AIX users of GCC ask questions here and on > other forums, but do not communicate to IBM AIX Brand executives that > the GNU Toolchain on AIX is important. The fact that GCC continues to > function at all on AIX seem to place it in the "out of sight, out of > mind" category. > > If you are a developer or ISV or your company uses GCC on AIX, tell > your IBM sales representative or executive contact that it is > important to your business. I wonder if it might make sense to more strongly suggest to use GNU as on AIX? The install manual currently says The native @command{as} and @command{ld} are recommended for bootstrapping on AIX@. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is required to bootstrap on AIX 5@. The native AIX tools do interoperate with GCC@. What's the downside of not using the native AIX tools at all (assembler and linker)? Richard. > - David > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-25 9:13 ` Richard Guenther @ 2011-10-25 9:24 ` Arnaud Charlet 2011-10-25 15:14 ` David Edelsohn 0 siblings, 1 reply; 13+ messages in thread From: Arnaud Charlet @ 2011-10-25 9:24 UTC (permalink / raw) To: Richard Guenther; +Cc: David Edelsohn, Perry Smith, gcc > I wonder if it might make sense to more strongly suggest to use GNU as > on AIX? The install manual currently says > > The native @command{as} and @command{ld} are recommended for > bootstrapping > on AIX@. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 > is required to bootstrap on AIX 5@. The native AIX tools do > interoperate with GCC@. > > What's the downside of not using the native AIX tools at all (assembler > and linker)? FWIW, we've recently made this choice/switch for GNAT at AdaCore, which allows us in particular to use dwarf-2/3 debug info. Arno ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-25 9:24 ` Arnaud Charlet @ 2011-10-25 15:14 ` David Edelsohn 2011-10-25 16:05 ` Arnaud Charlet 0 siblings, 1 reply; 13+ messages in thread From: David Edelsohn @ 2011-10-25 15:14 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Richard Guenther, Perry Smith, gcc On Tue, Oct 25, 2011 at 4:15 AM, Arnaud Charlet <charlet@adacore.com> wrote: >> I wonder if it might make sense to more strongly suggest to use GNU as >> on AIX? The install manual currently says >> >> The native @command{as} and @command{ld} are recommended for >> bootstrapping >> on AIX@. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 >> is required to bootstrap on AIX 5@. The native AIX tools do >> interoperate with GCC@. >> >> What's the downside of not using the native AIX tools at all (assembler >> and linker)? > > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which > allows us in particular to use dwarf-2/3 debug info. Is AdaCore maintaining GNU Binutils on AIX? I do not believe that Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1. Using Binutils means someone keeping it up to date with AIX. On the other hand, if there is enough external interest in GNU Binutils, IBM may lose control of the toolchain for its platform. Thanks, David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-25 15:14 ` David Edelsohn @ 2011-10-25 16:05 ` Arnaud Charlet 2011-11-08 18:44 ` David Edelsohn 0 siblings, 1 reply; 13+ messages in thread From: Arnaud Charlet @ 2011-10-25 16:05 UTC (permalink / raw) To: David Edelsohn; +Cc: Richard Guenther, Perry Smith, gcc, Tristan Gingold > > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which > > allows us in particular to use dwarf-2/3 debug info. > > Is AdaCore maintaining GNU Binutils on AIX? We're "maintaining" it sufficiently for our needs, yes. > I do not believe that > Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1. That's quite possible. Currently we support AIX 5.2 and 5.3, so haven't encountered AIX 6.x or 7.x specific issues. Do you know if these toolchain changes are significant? Arno ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AIX library issues 2011-10-25 16:05 ` Arnaud Charlet @ 2011-11-08 18:44 ` David Edelsohn 0 siblings, 0 replies; 13+ messages in thread From: David Edelsohn @ 2011-11-08 18:44 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Richard Guenther, Perry Smith, gcc, Tristan Gingold On Tue, Oct 25, 2011 at 10:26 AM, Arnaud Charlet <charlet@adacore.com> wrote: >> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which >> > allows us in particular to use dwarf-2/3 debug info. >> >> Is AdaCore maintaining GNU Binutils on AIX? > > We're "maintaining" it sufficiently for our needs, yes. > >> I do not believe that >> Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1. > > That's quite possible. Currently we support AIX 5.2 and 5.3, so haven't > encountered AIX 6.x or 7.x specific issues. > > Do you know if these toolchain changes are significant? AIX now supports DWARF debugging with XCOFF object files. XCOFF also has a new XCOFF_DEP_EXEMPT flag to override the default stack execution disabled. There are a lot of little changes for new AIX features. The bigger problem is GDB no longer is able to debug cc1plus on the trunk and GCC now builds as C++ by default. Thanks, David ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-11-08 16:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-18 4:48 AIX library issues Perry Smith 2011-10-18 8:30 ` Jonathan Wakely 2011-10-18 10:28 ` Jonathan Wakely 2011-10-18 15:37 ` David Edelsohn 2011-10-24 0:59 ` Perry Smith 2011-10-24 2:36 ` David Edelsohn 2011-10-24 9:45 ` Perry Smith [not found] ` <5FB999D3-E0FA-4AC7-A26A-DAA4397D833F@gmail.com> 2011-10-25 6:31 ` David Edelsohn 2011-10-25 9:13 ` Richard Guenther 2011-10-25 9:24 ` Arnaud Charlet 2011-10-25 15:14 ` David Edelsohn 2011-10-25 16:05 ` Arnaud Charlet 2011-11-08 18:44 ` David Edelsohn
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).