Hi Christopher, * Christopher Hulbert wrote on Fri, Dec 02, 2005 at 01:29:52PM CET: > On 12/2/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > * Christopher Hulbert wrote on Fri, Dec 02, 2005 at 12:48:13PM CET: > > > > > The other problem I have is I have to set FCFLAGS to -fpic so when > > > autoconf gets the Fortran libraries to link with pgf90 puts the > > > libso first. Is there another way to do that?
> 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? 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. - 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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
