Re: Interix support for libtool

[Todd Vierling]

On Sun, 3 Jul 2005, Thorsten Glaser wrote:

> >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.

I'm fine with this; same reasoning.  Thorsten, if you have time to test,
please do; I'm about to go on a personal trip for a week and don't have time
for more code testing until then.

> >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 would very much desire that we not pursue passing an explicit image base
through Libtool.  The backflips necessary to make libtool-1.5 handle
Darwin's -framework is bad enough, and really, I don't want to encourage
*anyone* to choose fixed image base addresses for Interix.

RSS relocations for base address conflicts are a bit of a slowdown, yes, but
the ability to choose a random base address helps to relieve that stress
quite well without having every shlib with its own fixed base.

Supposedly, if Interix is further maintained in the future, the buggy PIC
support in its gcc will be fixed.

> >> +    _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.

Again, the expr variant above is fine with me, provided it tests out OK.

As for -version-script, I cannot guarantee that it would work at all.
(I've never used it directly, so if you have a testcase to determine if it
works properly, let me know.)

Interix's dynamic linker, though it *looks like* ELF in many respects, is
not ELF -- it is POSIX subsystem marked PE, with some embedded metadata to
emulate *some* features of ELF (such as rpath, soname, and DT_NEEDED).

> >(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.)

As with above, let me know if you have a testcase.

However, many of the BSDs still have very a.out-ish dynamic linkers (OpenBSD
in particular) so it cannot be assumed that an ELF system is truly "ELF
compliant".  NetBSD, for one, started over from scratch to implement ELF so
as not to have hidden a.out legacy gotchas....

> >> +  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.

I'll have to go retest once I get back from my trip, because I forget what
the problem was.

> >> + # 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.

I would presume it means "it's not handled currently"; the comment block
above is not mine.

> >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).

It should go back to interix3*.  Interix 2.2 is a very different beast, is
no longer maintained, and likely has lots of hidden gotchas for which the
libtool diffs would break horribly.

> >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).

Right.  Stick with what we know to work ("interix3*"), and change it later
when it's known to work on later versions properly.  Interix 3.x is sort of
in-between in gcc/linker functionality, so we can't assume that anything
will be compatible in later major versions.

> >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...

When I first wrote the diffs, I believe almost all of the testsuite passed,
which is why I declared it "stable".  I'd have to check again.

-- 
-- Todd Vierling <address@hidden> <address@hidden> <address@hidden>