Re: libtool rearranging library paths

[Christopher Hulbert]

On 12/2/05, Ralf Wildenhues <address@hidden> wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Fri, Dec 02, 2005 at 01:29:52PM CET:
> > On 12/2/05, Ralf Wildenhues <address@hidden> wrote:
>
> > No I don't think it's a libtool problem.   Basiclly  I call the
> > AC_FC_LIBRARY_LDFLAGS macro to get the fortran  libraries to link with.
> > Due to the behavior of  pgf90, it either  puts the libso (for PIC code)
> > first  or the lib directory first.  Both directories contain the same
> > libraries just compiled differently.  So, I have to set LDFLAGS=-fpic before
> > calling configure so that in the macro it passes the -fpic flags to
> > pgcc/pgf90 and I get the libso directory first.  Autoconf doesn't use
> > libtool to get that information.
>
> Ahh, now I understand what you mean.
>
> Do I gather correctly that ideally
> - you don't want to use LDFLAGS=-fpic at all,
> - you do it because otherwise libtool will try to put the non-PIC
>   objects of /usr/local/pgi/linux86-64/6.0/lib into a shared library,
>   because the AC_FC_LIBRARY_LDFLAGS causes this path to appear early in
>   an `-L' argument?

Exactly.  I don't mind using -fpic, I just figured if libtool went
through all the trouble of abstracting PIC from me I should try to
stick with that.  Otherwise I just have to use -fpic or -fPIC which
most compilers I think I'll ever use will accept

>
> Then, my line of thought would be: libtool may not trust the result of
> AC_FC_LIBRARY_LDFLAGS here.  We have fixing of _LT_SYS_HIDDEN_LIBDEPS
> for Fortran (both F77 and FC) on the TODO list anyway.
>
> *time passes, testing a bit*
>
> This issue is a bit more complicated:
>
> - If we change libtool.m4 to do the detection itself, it will
>   (hopefully) decide to use the /../libso directory.  But will pgf90
>   also be smart enough to link against the shared libs in there
>   (libpgf90.so etc) rather than putting the PIC objects frm libpgf90.a
>   etc into the library?  Testing says: yes.

They're not all shared objects in there.  Looks like they have PIC
static and shared.  I was able to move the shared objects to another
directory and compile successfully and the shared object runs.

>
> - Testing also reveals: the PGI driver adds rpath arguments for both
>   paths.  Oh well. :-/
>
> - One remaining question is whether creating a program that links
>   against our new shared library will, independent of the -L flags
>   given, use the shared libpgf90.so etc.  If not, you get issues with
>   duplicate symbols.  And possible version skew issues later on.
>   Testing reveals that the rpaths added by PGI depend on whether you
>   link with -fPIC or not.  Which set of objects or libs you link in
>   depends on the -L paths (libso first?) given.  Hrmpf, so this may
>   lead to possible subtle breakage, or even duplicate symbols during
>   linking.
>
> Oh my.  I wish PGI had an extra option to specify whether to link
> against the non-PIC or PIC archives or the shared libs.
>
> Well, this is yet another problem setting which calls for an Autoconf/
> Libtool effort to provide portable ways to decide whether shared or
> static runtime libraries, and of what flavor if more than one, should be
> used for creating some code (see some discussions about -static-libgcc,
> or -lstdc++ vs. -lsupc++, for example; or Solaris -lCstd -lCrun..).
>
> At the moment I think no such thing exists -- the available macros are
> incomplete at best and inconsistent at worst, as you had to learn.
>
> I must say that I don't feel up to this task at the moment, not only by
> time constraints.  So, unless somebody feels brave, I guess you'll have
> to live with the workaround for now:
>
> > LDLFAGS=-fpic ./configure
>
> By the way, Autoconf suggests to pass also the variable settings as
> arguments to configure: that way it can know for sure which ones you
> have set:
>   ./configure LDFLAGS=-fpic
>
> (If that workaround in fact does not work for you, maybe because you
> don't want or can't use -fpic for other reasons, you should still be
> able to set the bunch of libraries manually, as in
>   ./configure FLIBS='...'
> or
>   ./configure FCLIBS='...
> to get things working as desired)
>
> >  -L/usr/local/pgi/linux86-64/6.0/libso -L/usr/local/pgi/linux86-64/6.0/lib
> > -L/usr/lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.0 -lpgmp -lpgthread
> > -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc -lm
> >
> > ./configure
> >  -L/usr/local/pgi/linux86-64/6.0/lib -L/usr/local/pgi/linux86-64/6.0/libso
> > -L/usr/lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.0 -lpgmp -lpgthread
> > -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc -lm
>
> Cheers,
> Ralf
>

On another note, why does libtool add an entire static archive (.a) if
it wasn't created with libtool?  I did an nm on a convenience library
and it had a .a stuck in there and nm complained that it didn't know
what file type that was.  It was also missing the symbols from inside
that archive (the objects were in an archive in an archive).  I think
I also did this for a shared object and got the same results.