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
