On Oct 3, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> ??? I'm advocating adding $pic_flag to the gcc that gets used to
> link. Considering that the SAME $pic_flag gets used to build the
> object files in the first place, I have trouble understanding how
> this breaks multi-libbed ABI.
Err... Indeed. :-)
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?
> 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?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
