Re: another darwin patch

[Alexandre Oliva]

On Mar  4, 2003, Robert Boehne <address@hidden> wrote:

> I wasn't around when the library dependency code was written,
> so I can't tell you why pass_all is used so widely.  

> Alexandre, do you have anything to add to this thread?

Sorry about the delay.  Here are my thoughts:

First, let me clear a mis-conception about libtool.  It's not about
creating shared libraries.  It's about creating libraries.  There's
some control given to the user in setting preferences on whether
libraries should be created as shared, static, or both.  Nowhere does
libtool offer any guarantees that it's possible to create shared
libraries at all, and it goes to a great extent in making sure that
every feature that is available through libtool on platforms that
support shared libraries is made available in the static-linking case
as well.  Even module loading is available, with the caveat that the
program has to pre-declare its intention to load the module at its
link time (with -dlopen).  If -dlopen is not used, and the module
you'd like to be able to dlopen isn't available for dynamic linking,
you lose, but libtool guarantees that, if you do use -dlopen, you'll
get the feature even in the static-linking case.


On to the pass_all issue: on a number of platforms, it is impossible
to add non-PIC to a shared library.  This may be because of
limitations of dynamic loaders, of dynamic relocations, of linkers, of
the way the compiler generates non-PIC, etc.  The point is that, if
you've got a piece of non-PIC code, if you try to link it into a
shared library, you'll get an error, either from the linker, or at
run-time.

On such platforms, when you request the creation of a library
including non-PIC, libtool, knowing it is not possible to do, goes
ahead and create a library as requested, with the caveat that, since
it can't be a shared library in this platform, only a static version
of the library is created.

If you abide to the libtool rules, and link everything using libtool,
specifying any dlopen dependencies when linking executables, you won't
notice the difference.

If you go ahead and assume that you'll get shared libraries anywhere
just because you happen to get a shared library on some platform in
which it is legal to have non-PIC in shared libraries, you get burned,
because, as I wrote before, there's no guarantee that even dynamic
linking is available everywhere.


Back to file_magic and pass_all: if it is always possible to link
non-PIC into a shared library, pass_all should be used.  Otherwise,
file_magic is a heuristics that libtool uses to tell whether a piece
of code is PIC or not.  Basically, if it looks like a shared library,
you'll get dynamic linking, so linking another shared library with it
is safe (on platforms that actually support dynamic dependencies of
shared libraries; some don't).  If it's not, it is assumed that it is
not PIC and can't be linked into a shared library, so libtool falls
back to the creation of static libraries only.  This heuristics fails
when we find say static archives containing PIC: we *could* go ahead
and create a shared library out of it, but we don't know that we can.
This is when the file_magic heuristics falls short.

Ideally, we'd have another heuristics that would attempt to create a
shared library and, if it succeeded, great, otherwise we'd fall back
to creating a static library just the same.  It could work on
platforms in which you'd get an error from the linker when attempting
to create a shared library with non-PIC.  On some, unfortunately,
you'd only get a run-time failure, so this is not an option for all
platforms.  But it would be an improvement for some.


Hope this helps clarify the issue,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 address@hidden, gcc.gnu.org}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist                Professional serial bug killer