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]



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.047