Re: PGI Compiler patch for cygwin

[Christopher Hulbert]

I get this error compiling libtool.  It looks like it's trying to
extract the symbols from libltdl/.libs/libltdl.lax/loadlibrary.lib,
but the symbols look like they have paths associated with it and thus
can't extract them because the path doesn't exist.  I guess this is
because the library is created using pgcc which uses the MS hack for
an archiver (lib).  Any ideas?



/bin/sh ./libtool --tag=CC --mode=link pgcc  -g -no-undefined  -o
libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info
7:0:0 -dlpreopen libltdl/loadlibrary.la 
libltdl/loaders/libltdl_libltdl_la-preopen.lo
libltdl/libltdl_libltdl_la-lt__alloc.lo
libltdl/libltdl_libltdl_la-lt_dlloader.lo
libltdl/libltdl_libltdl_la-lt_error.lo
libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo
argz.lo lt__strl.lo
libtool: link: rm -f libltdl/.libs/libltdl.nm
libltdl/.libs/libltdl.nmS libltdl/.libs/libltdl.nmT
libtool: link: creating libltdl/.libs/libltdlS.c
libtool: link: extracting global C symbols from `libltdl/.libs/loadlibrary.lib'
libtool: link: (cd libltdl/.libs && pgcc -g -c  "libltdlS.c")
libtool: link: rm -f "libltdl/.libs/libltdlS.c"
"libltdl/.libs/libltdl.nm" "libltdl/.libs/libltdl.nmS"
"libltdl/.libs/libltdl.nmT"
libtool: link: (cd libltdl/.libs/libltdl.lax/loadlibrary.lib && ar x
/cygdrive/c/cygwin/home/chulbert/libtool-build/libltdl/.libs/loadlibrary.lib)
libltdl/loaders/.libs/loadlibrary.o: No such file or directory
make[2]: *** [libltdl/libltdl.la] Error 1
make[2]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build'
make: *** [all] Error 2


bash-3.00$ lib -list libltdl/.libs/loadlibrary.lib
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

libltdl/loaders/.libs/loadlibrary.o

bash-3.00$ ar t libltdl/.libs/loadlibrary.lib
libltdl/loaders/.libs/loadlibrary.o




On 2/21/06, Ralf Wildenhues <address@hidden> wrote:
> * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET:
> > On 2/21/06, Ralf Wildenhues <address@hidden> wrote:
> > > * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET:
> > > >
> > > > I looked at the failure for fcdemo.  It
> > > > looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI
> > > > libraries because they are wrapped in single quotes, i.e.
> > > > '-Lc:\Program Files\PGI/nt86/6.0/lib'.
> > >
> > > Hmpf.  That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT
> > > and also all the way through Autoconf and Libtool so the embedded space
> > > isn't killed (or the path broken in two arguments).
> >
> > Not sure what's going on here.  I use the AC_FC_LIBRARY_LDFLAGS in my
> > configure.ac and I don't get that problem.  libtool's configure must
> > be quoting each of these arguments??? I should note that I had to
> > patch fortran.m4 (a long time ago) to handle a case where the library
> > was butted up against a single quote such as 'blah blah -lm'.  I
> > thought I sent that info to the autoconf list a while ago???
>
> The issue you sent to the Autoconf list was slightly different, and the
> patch I posted to fix it matched very narrowly (to lessen the chance of
> interfering with other compilers' output, or so I must have thought back
> then).
>
> You should also note that, if you use the nightly tarballs, they are
> bootstrapped with Autoconf 2.59, but aforementioned patch was added to
> Autoconf after 2.59.  Hopefully, Autoconf 2.60 will be out soon.
>
> > > Also I think we need to stick `-Mnomain' in Fortran archive_cmds
> > > otherwise fcdemo will fail again.
> >
> > Well, that depends on how you link.  I link my C code against the
> > archived fortran code separately so without forcing automake to use
> > LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the
> > use of AC_FC_LIBRARY_LDFLAGS).
>
> Oh.  Ok.  But I think libtool has always tried not to emit a dependency
> to the Fortran main function into the shared libraries it creates.  I
> believe it would only be consistent if we continued to do this now.
> Does it break anything?

I don't think it would break anything, but I don't think the fortran
compiler puts in a main when creating shared libraries.  Are you
trying to avoid the DllMain routine?  If so you want -Mnopgdllmain. 
The doc says that the latest version of the PGI DllMain are included
in the release notes and must be included for proper functioning of
the dll. I would think under windows unless the user gives a specific
entry point or tells libtool not to use the DllMain, you may want to
leave that. Just my opinion though.

>
> Cheers,
> Ralf
>