Re: Interix support for libtool

[Thorsten Glaser]

Ralf Wildenhues dixit:

>> @@ -3157,6 +3178,17 @@ case $host_os in
>>      ;;
>>      esac
>>      ;;
>> +  interix3*)
>> +    # 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.  It
>> +    # is ksh-specific code, but on Interix, the system /bin/sh is a pdksh.
>> +    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs 
>> $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,$((RANDOM % 
>> 16#1000 / 2 * 16#40000 + 16#50000000)) -o $lib'
>
>Hmm.  I'd prefer code which is not shell-dependent, on two grounds:
>first, at some point in the future a different shell might be en vogue
>there, second, it might eventually be achievable to cross-compile.

I talked to the Microsoft guys at LinuxTag 2005 (trying to get the
mirbsdksh "in there") but they said the base system won't change
that much.

Your cross-compiling is the better argument.

>Maybe something cheap like this?
>
># 4096 = 0x1000, 262144 = 0x40000, 83886080 = 0x5000000
>_LT_AC_TAGVAR(archive_cmds, $1)='img_base=`expr ${RANDOM-$$} % 4096 / 2 \* 
>262144 + 83886080`~
>                                 $CC -shared $pic_flag $libobjs $deplibs 
> $compiler_flags ${wl}-h,$soname ${wl}--image-base,$img_base -o $lib'

Eh... I'll pass onto this. You know how much of a ksh fan I am ;-)
But if the GNU Libtool maintainers prefer this, I would not veto
if your diff works.

>Would it maybe be beneficial if Libtool allowed to specify an image
>base?  (I'm not quite sure we want this -- unless a central authority
>hands out image bases to library authors, there'll hardly be any _real_
>gain).

In theory - yes. But in practice: how does Libtool handle target-specific
options? I mean, for example, on GNU/Linux with libc4 (a.out) you had
image bases as well (in contrast to BSD a.out with "real" shlibs);
for other systems, there are more machdep options. I thought libtool's
gain was to *hide* these.

>> +    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols 
>> >$output_objdir/$soname.expsym && $CC -shared $pic_flag $libobjs $deplibs 
>> $compiler_flags ${wl}-h,$soname 
>> ${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
>> ${wl}--image-base,$((RANDOM % 16#1000 / 2 * 16#40000 + 16#50000000)) -o $lib'
>
>Same here, also s/&&/~/.  Can't gcc use -version-script here?

I'll pass this on to Todd, since that part of the diff is from him.

>(BTW: gcc should be able to use -version-script in many cases on BSDs as
>well -- it'd be really cool if someone who knows BSD internals could
>sort out the corner cases!  Libtool using --retain-symbols-file is
>really a kludge.)

Sorry, not my special area... as for "my" BSD, we use binutils-mainline
from 2005 and gcc 3.4.5 (prerelease). No special treatment, I think.

>> +  case "$host_os" in
>
>(No quotes necessary here.)

Feel free to alter it.

>> +  interix3*)
>> +    # Interix 3.x installs completely hosed .la files for C++, so rather
>> +    # than hack all around it, let's just trust "g++" to DTRT.
>
>What does this mean?  In what way are the files hosed?
>(I'm asking because there might be a clean fix.)

Again, I'll pass this on to Todd.

>> @@ -4796,6 +4842,12 @@ AC_MSG_CHECKING([for $compiler option to
>>          ;;
>>      esac
>>      ;;
>> +      interix*)
>> +    # This is not gcc, but c89, which is MS Visual C++
>> +    # We do not support c89 in MirPorts, so for GNU Libtool
>> +    # special handling is needed. c89 does not support
>> +    # generation of shared libraries at all.
>> +    ;;
>
>So does that mean this special handling is still needed here?

I don't know.

For MirPorts, we use gcc exclusively. I think, no sane person would
ever use "c89" which is a (ksh!) wrapper around cl.exe and does not
handle shared libraries and much other stuff:
-r-xr-x--x  0 root  msdos  29100 Nov  8  2003 /nt/SFU/bin/c89*

>I have not checked your patch thoroughly: does it ensure, that in
>AC_LIBTOOL_PROG_LD_SHLIBS
>  _LT_AC_TAGVAR(ld_shlibs, $1)=no
>is set for interix/non-gcc?

I haven't even looked at the case for Interix/non-gcc, sorry.

>Does
>  test "$GCC" = yes
>not work on interix?   What motivated this comment?

Again, I only added the comment to point it out to the GNU Libtool
folks that this diff only handles the Interix/gcc case because I
know you want this ultimate portability we do not need/want.

>Same as above.

It's the same code ;) just two spaces more indentation.

>Another general comment: sometimes, the match is done for interix*,
>sometimes for interix3*.

I have tried to sort this out - NetBSD(R) started to match only
for interix3* after the discovery how broken the C++ .la files
and the shlibs are. I tried to write interix* where it is not
dependent on this brokenness (excuse my bad English).

>Restricting to 3 might
>hinder upward compatibility in case the next version has little relevant
>changes.

We hope that the next version will have at least some of the
breakage fixed. Looking at what became of PIC support in gcc
and the Interopsystems webfora, I think at least some of the
interix3* will become interix[34]* (but maybe not all).

>Yet another question: Is there incentive to fix gcc on interix, so that
>it can actually create PIC code?

As far as I heard (I'm not as deep into this as other people,
and docs are hard to find) there has been a company paid to do
the fix, but the efforts were never fed back to either Microsoft
or the gcc SC (which is only interested in gcc 4.1 diffs anyway).

>Out of curiosity: it'd be nice to know how much of the Libtool test
>suite actually passes on Interix with these patches applied.

Yeah, I know, I need a test box. I've only got one laptop at the moment...

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.              -- Coywolf Qi Hunt