[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #10 from Perry Smith pedzsan at gmail dot com 2013-01-31 05:50:00 UTC --- Can you keep the libraries like you have them with the functions and private structures for the functions coming from the library but just put the definition of __dso_handle in crt?
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #4 from Perry Smith pedzsan at gmail dot com 2012-12-09 04:45:47 UTC --- I can't remember much about this. Things may have changed since I reported it. Is the Makefile created as the last step? If not, then if something fails after the Makefile is created, then the next build will assume everything in that section completed successfully (which will be incorrect).
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #6 from Perry Smith pedzsan at gmail dot com 2012-12-09 05:40:28 UTC --- If it helps, here are the last messages from the make log: checking for powerpc-ibm-aix6.1.0.0-gcc... /usr/work/build/gcc.git/./gcc/xgcc -B/usr/work/build/gcc.git/./gcc/ -B /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/bin/ -B/gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/lib/ -isystem /gsa/ausgsa/projects/r/ruby/powerpc-ibm-aix6.1.0.0/include -isystem /gsa/ausgsa/projects/r/ruby/powerpc -ibm-aix6.1.0.0/sys-include -maix64 checking for C compiler default output file name... configure: error: in `/usr/work/build/gcc.git/powerpc-ibm-aix6.1.0.0/ppc64/libatomic': configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libatomic] Error 1 make[1]: Leaving directory `/usr/work/build/gcc.git' make: *** [all] Error 2 All's I know is after the error, a make would not finish the config processing and go down a different path.
[Bug c/55105] New: use of LD_LIBRARY_PATH incorrect for AIX -- cause trunk build to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105
Bug #: 55105
Summary: use of LD_LIBRARY_PATH incorrect for AIX -- cause
trunk build to fail
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pedz...@gmail.com
configure.ac has this:
# Decide which environment variable is used to find dynamic libraries.
case ${host} in
*-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
*-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
*-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
*) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
esac
Starting with AIX 6.1, LD_LIBRARY_PATH is used. I don't 100% understand the
intent of the code above. The environment variable mentioned (e.g.
LD_LIBRARY_PATH) is passed via the environment when (e.g.) libatomic is built.
With LD_LIBRARY_PATH in the environment, xgcc and cc1 no longer execute
properly because at the time they execute, LD_LIBRARY_PATH points to the bit
version being built -- not the bit version that xgcc was built for. There is a
longer description here: http://gcc.gnu.org/ml/gcc/2012-10/msg00386.html
I changed it to this:
# Decide which environment variable is used to find dynamic libraries.
case ${host} in
*-*-aix*) RPATH_ENVVAR=BOGUS ;;
*-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
*-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
*-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
*) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
esac
In theory, it should be LIBPATH but I'm sure that will cause the build to
fail as well. In essence, the logic needs to be reviewed. Perhaps other
platforms are different in their use of LD_LIBRARY_PATH / LIBPATH than AIX.
[Bug c/55083] New: failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 Bug #: 55083 Summary: failure while configuring libatomic is not cleaned up Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pedz...@gmail.com If something fails during the configuration phase of libatomic, a subsequent make will take a different path and not complete the configure processing. The error can be seen in the configure-target-libatomic: code of Makefile.in (at the top directory). Midway down, if the directory exists, exit 0 is called. If it does not exist, then it is created and configure for libatomic is called. But if configure fails, the directory is not removed. Subsequent make will assume that everything had been configured.
[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55083 --- Comment #2 from Perry Smith pedzsan at gmail dot com 2012-10-26 15:31:27 UTC --- To be clear, the error during configuration is not what the bug report is about. The discussion of the error can be seen here: http://gcc.gnu.org/ml/gcc/2012-10/msg00380.html cc1 is failing because LD_LIBRARY_PATH is set to the wrong value. What this bug report is addressing is the fact that a failure does not clean up. The test I'm doing may be a little hard to recreate but I am doing rm -r powerpc-ibm-aix6.1.0.0/libatomic make configure-target-libatomic but you will need to somehow cause your gcc/xgcc or gcc/cc1 to fail (or create some other way to cause the configure to fail).
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #4 from Perry Smith pedzsan at gmail dot com 2012-09-17 14:18:34 UTC --- (In reply to comment #3) To be included the patch needs to be against trunk. I don't mind trying to redo this against trunk but I need some help learning how to build against the trunk. I'm assume it is documented somewhere but I don't know where. I looked (e.g. site:gcc.gnu.org/onlinedocs build trunk) doesn't hit anything useful. The pdf does not have autoconf nor automake which I'm sure are needed. So I got stumped. Sorry.
[Bug c++/54601] New: AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601
Bug #: 54601
Summary: AIX uses atexit which causes unloading of shared
modules to break
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pedz...@gmail.com
Created attachment 28200
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28200
git diff -c of base 4.5.2 tarball against new files and changes
The bug was hit when using Apache httpd with a module called passenger.
passenger uses some c++ code. httpd does an unload of all of the modules that
it loads when it exits. The symptom is a core dump because by the time the
atexit is run, the TOC entries as well as the code to execute which are
registered as the DTORs have been unloaded.
Using the x1.cpp attached, I determined that the atexit is used to register a
DTOR for a static object with a non-trivial DTOR that is declared inside a
function. The DTOR is registered only if the function is called. (x1.cpp does
not demonstrate the problem. It was just used to educate me about when gcc
used the atexit service.)
I am also supplying a patch to the base 4.5.2 tarball that fixes the problem.
I stole the cxa_atexit and cxa_finialize from GNU's glibc-2.16.0
implementation. I believe I have removed glibc's locking and successfully
added back in the locking that gcc uses so that the file is built properly on
the four different platforms: 32 bit, 32 bit threaded, 64 bit and 64 bit
threaded.
The changes to the configure and makefiles will need to be ported to the real
files. I added references to the two new files introduced into the makefile
and changed the configure script to assume cxa_atexit is present on AIX systems
so that it will honor the --enable-__cxa_atexit configure option. The options
I used for configure are:
--with-gmp=${PUBLIC_BASE} \
--with-mpfr=${PUBLIC_BASE} \
--with-mpc=${PUBLIC_BASE} \
--disable-nls \
--enable-threads=aix \
--with-libiconv-prefix=/usr \
--enable-__cxa_atexit \
--enable-languages=c,c++
If all goes well, I propose to have --enable-__cxa_atexit be the default for
AIX.
The final big change is to collect2. The changes are rather large. I tried to
keep the proper style. There may be some debugging that can be removed. A new
c stub is created in the first link pass so that __dso_handle can be declared
to allow the first link to complete. I generalized a few things in the
process. I hope all that is ok.
I've used this new compiler for a month now but only on the original problem.
All seems to be working.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #1 from Perry Smith pedzsan at gmail dot com 2012-09-16 14:39:05 UTC --- Created attachment 28201 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28201 Educational program demonstrating when atexit is used. Run it without an argument, the function that declares the static is not called -- thus the DTOR is not registered. Run it with an argument to call the function that declares the static.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #2 from Perry Smith pedzsan at gmail dot com 2012-09-16 14:40:25 UTC --- Forgot to mention. A long thread discussing the issue, etc is here: http://www.mail-archive.com/gcc@gcc.gnu.org/msg65140.html
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #19 from Perry Smith pedzsan at gmail dot com 2011-04-07 12:55:19 UTC --- Yes. Thats the one. Dave, First, I believe this link is a public facing interface to Fix Central http://www.ibm.com/support/fixcentral/ (it came from google). If not, post back, and I'll try and find one. I *think* you can do instfix IZx or something to that effect and it will say yea or nah as to if you have the APAR. I don't know for sure. I usually go by fileset and VRMF levels like bos.foo 4.3.2.1. I assume you know that each TL has its own APAR for each problem so you have to look for sister APARs. Fix central is suppose to be smart enough to do that but I'm not sure about instfix. Also you did flip around some things. 5.3 TL10 SP03 has the problem SP05 has the first fix but not the second. For 5.3 TL12, SP02 has the first fix as IZ81341. Note that the two issues are very similar. The error number changed and that is what I key off of. You can do oslevel -s to get the service pack level that you have installed. The reason I put the link to fix central is IBM charges for support -- not updates. As far as I can tell, anyone can go to fix central and download any fix they want. Hope this helps
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #13 from Perry Smith pedzsan at gmail dot com 2011-03-23 13:26:10 UTC --- On Mar 23, 2011, at 2:47 AM, michael.haubenwallner at salomon dot at wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ? 5.3 -- something. I thought I put it in my update. I can check when I get to work. Seems like it was tl10 but a later SP than others reported. Does that help? Perry
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #15 from Perry Smith pedzsan at gmail dot com 2011-03-23 19:31:18 UTC --- Let me try and recap. The initial report was that 5.3 TL10 did *not* have the error. I discovered that 5.3 TL10 SP03 does. See [1]. APAR IZ81343[2] and its sister APARs addresses this issue. It is shipped (for example) in 5.3 TL10 SP05 as IZ81339. After you apply that APAR, you get a new issue where the linker now spews out: ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the assembler APAR. I tried two versions of GCC: 4.2.0 and 4.5.2. IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072#c7 [2] https://www-304.ibm.com/support/docview.wss?uid=isg1IZ81343
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #8 from Perry Smith pedzsan at gmail dot com 2011-03-18 17:10:32 UTC --- It appears that this not a gcc bug but an AIX bug. There is one change but more changes are needed. I'll try to update when I know more. Expect it to be a week or so.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #10 from Perry Smith pedzsan at gmail dot com 2011-03-18 18:57:07 UTC --- IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. The word I have presently is that that too is going to turn out to be an AIX assembler error.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Perry Smith pedzsan at gmail dot com changed: What|Removed |Added CC||pedzsan at gmail dot com --- Comment #7 from Perry Smith pedzsan at gmail dot com 2011-02-24 01:21:52 UTC --- This change must be within TL10 too. I'm at 5300-10-05-1036 and have the same issue. There are three APARs that came out in 5.3 TL10 SP02 that hit bind: IZ69311, IZ69515, and IZ70028. One APAR in SP03: IZ73713. And one in SP04: IZ82696.
[Bug c++/13682] Compile error with cstdio: fgetpos not declared on AIX
--- Comment #9 from pedzsan at gmail dot com 2010-05-17 20:05 --- The general reply to this was your GCC was not compiled for your system. That isn't the case. I have two compiles on two different systems. One if version 4.5.0 and the other version is 4.3.1 compiled on AIX 5.3 TL05 CSP. The 4.5.0 version I just finished compiling and it still has the problem. -- pedzsan at gmail dot com changed: What|Removed |Added CC||pedzsan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13682
