This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs on AIX: native or gnu ld?
- To: Andrey Slepuhin <pooh at msu dot ru>
- Subject: Re: egcs on AIX: native or gnu ld?
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Fri, 17 Oct 97 17:47:00 -0400
- Cc: egcs at cygnus dot com
Most of your questions deal with G++ implementation issues which I
cannot address. I really do not know how -frepo works or about additional
files it creates and how linkers other than GNU ld are suppose to handle
them. It sounds like at least some of the features of G++ are relying
upon GNU ld or SVR4/ELF-like linkers.
The _GLOBAL__DI/_GLOBAL_DD symbols invoke the global constructors
and destructors for a shared object and are exported for AIX. Because
each shared object will contain those same entry points, they will be
duplicated and the AIX linker will warn about them. In AIX 4, the linker
now announced a lot more warnings about these type of issues which always
were produced by GCC.
>>>>> Andrey Slepuhin writes:
| 5) What about including support of shared libraries with native ld to the
| future snapshots of egcs? Now I am using hacked version of system script
| makeC++SharedLib, but it only needed for generating correct exports
| list. At least, I have no problems yet with shared libraries built with
| native ld.
To what type of support of shared libraries are you refering?
Specifically creating an export list? Because AIX's XCOFF object file
format has finer granularity about the visibility of symbols than ELF, it
takes more work to make it behave like other Unix systems where all global
symbols are visible outside the module.
I am not sure that the FSF would be allowed to include a modified
version of AIX XLC's makeC++SharedLib script, but if you were to
reimplement the functionality for G++ as makeG++SharedLib, it probably
could be included in the egcs distributions and installed automatically.
AIX 4.2 also has features like specifying symbols automatically to
be invoked as constructors and destructors upon loading, but it uses a
special header section populated from the commandline instead of ctor/dtor
or init/fini object file sections of SVR4/ELF. Also, the ordering of
invocation in the case of dependencies leaves something to be desired. I
am not sure if it is worth the implementation / compatibility headaches.
David