http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623
--- Comment #8 from Michael Haubenwallner <michael.haubenwallner at salomon dot
at> 2012-03-22 20:33:01 UTC ---
I'm still grafting some RFC for gcc-ml with more background info for the
not-so-experienced ones, however I don't mind to discuss that here - eventually
resulting in a better RFC if still needed afterwards.
This is how I'm successfully using Import Files already, to provide the soname
feature with runtime linking enabled:
* Create the list of exported symbols from object files.
but with extra "weak" keyword, for the import file later.
* Create shr.o using -G linker flag, using that list of exported symbols.
* Set F_LOADONLY on shr.o.
* Create shr.imp, where
first line is the "soname": #! libNAME.so.1(shr.o)
second line is the bitwidth: # 32
rest is list of symbols: symbol
eventually flagged as weak: weak_symbol weak
* Create libNAME.so.1 as archive, containing shr.o and shr.imp
* Create symlink libNAME.so -> libNAME.so.1
The reason I do this with -brtl only is that this variant doesn't allow to
statically link shr.o any more, so I cannot create libNAME.a this way.
While I do not use multilib here, the file format still allows for the AIX way
of multilib, with these differences to the above for 64bit:
* Create shr_64.o
* Create shr_64.imp
* Specify "# 64" in shr_64.imp
Finally, libNAME.so.1 would contain:
shr.o
shr.imp
shr_64.o
shr_64.imp
The name of the archive members is just some convention to avoid confusion, AIX
would allow for more than one archive member with identical name, especially if
they are shared objects with different bitwidth, using the -X32 and -X64
toolchain flags.
What /really/ matters is the second line in the import file to read:
# 64
You're welcome to read the history on how I've sorted out this variant:
http://bugs.gentoo.org/213277
