Re: Interix support for libtool

[Ralf Wildenhues]

I snipped all the stuff we have agreed upon or need further outside
input.

* Thorsten Glaser wrote on Sun, Jul 03, 2005 at 10:39:38PM CEST:
> Ralf Wildenhues dixit:
> 
> >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.

Yes, most certainly.  It was rather a bug in my head.

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

Just in case you did not know: The ~ in the *_cmds variables will just
effectively become && when executed.  Except the commands are printed
only right before they are executed.

> >> @@ -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*

So if this is MSVC, one could just put in our support for it .. once
we're through with _that_ patch.  :)
(Actually, I agree with you -- no need to support something nobody
uses.  I don't know.)

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

Again: what does broken mean?  What's listed in the predeps/postdeps?

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

OK.

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

Hmm.  :-/

Thanks,
Ralf