Re: Three problems with libtools

[Marc Espie]

On Tue, Oct 03, 2000 at 05:29:07AM -0200, Alexandre Oliva wrote:

> I recall having had trouble on SunOS 4 when adding some PIC flag to
> the command line that I used to create shared libraries.  But that was
> long before libtool existed, and I no longer have access to SunOS 4
> boxes to test again.

> But I guess we can give it a try.  As you say, it shouldn't break.
> Maybe I mis-remember.  Would you be so kind to post a patch to
> implement this change?

I can... you're aware I don't currently have a libtool assignment, nor
the way to test it on quite a few platforms ? what I'm going to do
is simple search for -shared, verify whether it looks like gcc/g++ -shared,
and add pic_flag.

> > libgcc *is* an exception, precisely because it will be pic/PIC.

> I see.  That's been true for GCC releases for the past 5-or-so years,
> so it's probably reasonable to assume it to be the case.  But it
> wouldn't hurt to check that the GCC version is 2.7 or newer before
> assuming libgcc is PIC.
> 
> What we really need is some way to tell for sure whether a certain
> library can be safely linked into a shared library.  Something like:
> 
> - extract the list of symbols defined in the library
> - compile a position-independent object file that references all of them
> - on platforms that don't allow_undefined,
>   . extract the list of symbols required by the library
>   . compile a position-independent object file that defines them all
> - attempt to link a shared library with them
> - cache the result?

I don't know. I think that solving the problem at hand (saying that libgcc
does work) would be quite enough for now.

As for the more general problem, I haven't looked too closely at libtool's
performance lately, but this looks like yet another instance of the
generic gnu gas-plant problem... trying to be very generic and compile on
everything is sometimes going to have the exact reverse effect of what you're
trying to accomplish. Specifically, 4000+ lines shell-scripts are not exactly
fast, which makes it hard to test on older, slower platforms. Also, the last
times I did have to tweak libtool and try to find what went wrong on OpenBSD,
it did take me five minutes to figure out what I wanted it to do, and two
hours to find out WHERE to effect the change in that jungle of
shell-scripts...

I ought to give a closer look at the current development version, but
having architecture cases all over the place instead of at one more or less
central place in the configure section is not that good...

-- 
        Marc Espie              
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'