On Sat, 2004-09-11 at 04:24 -0300, Alexandre Oliva wrote: > On Sep 8, 2004, Scott James Remnant <scott@netsplit.com> wrote: > > > The alternative method (file) isn't reliable enough, and consistently > > fails for huge numbers of shared libraries (such as GTK+). > > How does it fail in the cases you have in mind? > X includes several static libraries that contain PIC code. On ARM, libtool throws these out and won't link with them. http://buildd.debian.org/fetch.php?&pkg=kdelibs&ver=4%3A3.1.1-1&arch=arm&stamp=1049165170&file=log&as=raw > > While this patch isn't *quite* in the spirit of the option, > > It actually renders the option useless. Might as well remove it > completely and just let the linker error out for the user, rendering > the libtool abstraction useless in the process. > Unfortunately the option *is* useless. It's supposed to find out whether the library being linked is PIC or non-PIC, instead it's just checking whether it's a shared or static library. If that option is to be useful, it needs to check whether the actual code in the library is PIC or non-PIC and make the decision based on that. Simply looking at what kind of library you're linking against isn't sufficient. > Listing a non-shared library as a dependency of a libtool library is > not the right approach to create a shared library with libtool. > What happens when the non-shared library contains PIC code? What happens when the shared library you're happily linking with contains non-PIC code? > The right approach to creating libtool libraries out of archives is to > create libtool archives (AKA convenience libraries). This enables > libtool to make sure that only PIC is present in the input, and > generate a shared library, or to know that non-PIC is present, and > refrain from generating a shared library. > How would it know this when linking against software (X) that doesn't use Libtool? > I realize you're trying to be pragmatic here, and trying to find the > simplest solution for the big problem at hand, but I don't think > that's the right way to run a project. You should think of the > libtool design first, and then try to get packages to use it properly, > instead of forcing libtool to bend backwards to support abuses from > packages that should have known better. While some of these packages > might not actually be broken, others will be, and with this change > users may get confused and blame libtool for an error that is actually > theirs. > The error in this case is Libtool's. It refuses to link PIC code into a shared library because the test it uses to determine whether code is PIC or not doesn't actually do anything of the kind and is based on an incorrect assumption (static=non-PIC, shared=PIC). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part