Building shared libraries on Interix

Building shared libraries on Interix (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum

Message

mkoeppe -> Building shared libraries on Interix (Oct. 14, '06, 7:26:58 PM)

Just a short memo what I found about building shared libraries on Interix, mostly extracted from libtool 1.5.22, file libtool.m4:

The good news: If a package uses libtool 1.5.22 to build the shared libraries, all will work automagically. Only make sure the architecture string contains "interix3", such as "i586-pc-interix3.5", as libtool matches for "interix3*". Use configure option --build to override on SUA:


$ ./configure --build=i586-pc-interix3.5

If you want to or must compile manually:

1) Compile without -fPIC, because -fPIC doesn't work on Interix. It's said to generate broken code.

2a) To simply link a shared lib, use


$ gcc -shared -o lib.so *.o

2b) To include $SONAME as soname in the lib, add gcc option -Wl,-h,$SONAME
Don't use linker option --soname (note the double dash) as on Linux, it does not work on Interix.


$ gcc -shared -Wl,-h,$SONAME ...

2c) If you use the dlopen linker option --export-dynamic for linking on Linux, translate that to -E on Interix.


$ gcc -shared -Wl,-E ...

2d) For hardcoding library names use linker option -rpath $LIBDIR instead of --rpath on Linux:


$ gcc -shared -Wl,-rpath,$LIBDIR ...

2e) For optimizing the loading time you may add a random --image-base, libtool uses:


$ gcc -shared -Wl,--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` ...

3) make sure the resulting *.so* file is executable, otherwise Interix's dynamic linker /lib/ld.so.1 cannot load it:


$ chmod a+x *.so*

4) look if the soname has been set correctly with:


$ objdump -p lib.so

Bottom line: use libtool!

Rodney -> RE: Building shared libraries on Interix (Oct. 14, '06, 10:45:07 PM)
Most of this has been posted before, but not all in one posting. HOWEVER, don't do (2e) !! There are fixed spots for many libraries already. They are set to line up nicely. With the above random method you can get programs that cannot load. It's best to pick a location. I've gone through this before while porting. There is a list that I maintain that anyone can submit additions to. I'm hoping to have this list added to the Vista release. Then libtool can be changed to use it which will result in better layouts.

mkoeppe -> RE: Building shared libraries on Interix (Oct. 15, '06, 12:38:24 PM)
Hi Rodney, in libtool.m4 I found the following: # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc. # Instead, shared libraries are loaded at an image base (0x10000000 by # default) and relocated if they conflict, which is a slow very memory # consuming and fragmenting process. To avoid this, we pick a random, # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link # time. Moving up from 0x10000000 also allows more sbrk(2) space. I didn't test the relocation, though. Does it work as mentioned? I simply thought it would, and the random number would just decrease the probability of a conflict, but of course never eliminate it. Where can your --image-base list be obtained? Does it conflict with libtool's current random values?

Rodney -> RE: Building shared libraries on Interix (Oct. 15, '06, 1:44:38 PM)
The specification for the image base works. That is not in question. And the note is correct that the default value is 0x10000000. You can even see this value when you use "objdump -p". The "real fix" is that work needs to be done in the loader (ld.so) to be better about locationing/relocating. That's what can trip up the random assignment method. I'll come back to this with a longer explanation later today (I have to go to a meeting right now). But in short no, the random values don't decrease the chance of conflict because how ld.so currently works. The random values do not conflict with what ships with SFU or other currently assigned values. later...

Rodney -> RE: Building shared libraries on Interix (Oct. 16, '06, 6:07:23 AM)
An attempt is made to load each library at the image base location that is specified. The default is 0x10000000 if no other location is provided. If a conflict happens with a previously loaded library then another location is chosen. This adds some extra time to the loading. If the 0x10000000 is hit over and over then more loading time is taken. So having specific loading locations means no conflicts, means faster loading. However if the size of a library being loaded is larger than the slice of memory address space then the load fails. The libraries with pre-assigned locations have enough space to not overflow into another library's space. In fact there's a bit extra which helps cover future versions being a bit larger. So preassigned libraries won't need relocation & won't overflow. With the randomly assigned locations the location value, even for the same library, will be different for each configure/build. While unlikely, it is possible for the same random number to be generated for more than one library. The loader will do a relocation, but that negates the purpose of the random choice in the first place (minor point). More important is that the size of the library plays no role versus the locations of other randomly assigned locations -- an overflow into another library can happen. It may not happen with build A or B, but happen with C. The builder isn't going to know why. The program just won't load. Since it works with A and B then it not working with C will appear flakey/mysterious. The default location, if not specified, should likely be a higher number to keep a larger single memory space available. And the loader should be changed to deal with overflow (or be better with locating period). The latter is more important.

Page: [1]

0.047