Re: PGI Compiler patch for cygwin
On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:08:33PM CET: The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support? Thanks, Ralf pgi_patch_testsuite.tar.bz2 Description: BZip2 compressed data
Re: PGI Compiler patch for cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Hulbert on 2/22/2006 5:56 AM: Actually it seems the problem is that a unix-style path is passed to lib as the library name. This is probably not the correct fix, but what I did was add the following to the func_extract_archives function between the *-darwin* and * case. *-cygwin*) my_xdir=`cygpath -m $my_xdir` my_xabs=`cygpath -m $my_xabs` func_extract_an_archive $my_xdir $my_xabs ;; Missing some proper quoting - consider if my_xabs contained something like '/dir with 2 spaces/file'. Furthermore, I don't think this should this be done globally for cygwin because it penalizes compilers that do understand POSIX paths (gcc). When using cygwin as a compilation environment, but targetting a compiler that does not understand POSIX paths, it is usually better to wrap the compiler inside a script that does the command-line conversion, and use that script as the compiler. So you were correct that it is not the correct fix, but it is a good indication of the problem that needs to be resolved. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/w9L84KuGfSFAYARAreSAJ951956g75zOA+4VOy1D7ejXLOX5wCgvzj0 Oz2Q8wFWaDHgHs74Bzkefs0= =k4Ov -END PGP SIGNATURE-
Re: PGI Compiler patch for cygwin
* Eric Blake wrote on Fri, Feb 24, 2006 at 02:51:07PM CET: According to Christopher Hulbert on 2/22/2006 5:56 AM: Actually it seems the problem is that a unix-style path is passed to lib as the library name. This is probably not the correct fix, but what I did was add the following to the func_extract_archives function between the *-darwin* and * case. *-cygwin*) my_xdir=`cygpath -m $my_xdir` my_xabs=`cygpath -m $my_xabs` func_extract_an_archive $my_xdir $my_xabs ;; Missing some proper quoting - consider if my_xabs contained something like '/dir with 2 spaces/file'. Furthermore, I don't think this should this be done globally for cygwin because it penalizes compilers that do understand POSIX paths (gcc). Certainly all uses of `cygpath' in ltmain are best replaced with uses of the `fix_srcfile_path' variable. We may need more variables like that, to indicate the necessity of fixing for - the compiler - the archiver - maybe even the linker separately from the compiler (hopefully not), - possibly the name lister (NM). Cheers, Ralf
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET: Attached is the test outputs. Thanks. Unfortunately, I was not precise enough: Please configure Libtool with the Portland compilers, so that they are tested. E.g., like ./configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf95 duh, I feel braindead :)! Sorry about that. :-( Please note that the tarball you sent did not contain tests/testsuite.log. It appears make_check_local was misplaced: there is a duplicate, packed copy of make_check in there. It'd be great if you could send the testsuite.log file as well, and the other output with the above configuration. Yeah, got an error that I couldn't append to a compressed tar archive so that didn't make it :/. Not that it mattered since I used the wrong C compiler. But also see below: 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??? Probably it would currently be best (for Fortran users) to - either install the compiler under a path not containing spaces, or - create a config.site file for this compiler/system combination, with ac_cv_fc_libs pre-seeded with the right flags for Fortran, and alternate non-space path representations; on your system, that would be something like ac_cv_fc_libs='-Lc:/Progra~1/PGI/nt86/6.0/mingw/lib -Lc:/Progra~1/PGI/nt86/6.0/mingw/mingw32/lib -Lc:/Progra~1/PGI/nt86/6.0/mingw/lib/gcc-lib/mingw32/2.95.3-5 -Lc:/Progra~1/PGI/nt86/6.0/lib -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lpgc -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32' all on one line. See the Autoconf docs for config.site files. - Or do both of the above. 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). Cheers, Ralf On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support?
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 05:48:56PM CET: 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? Ah, ok. At this point we need a feature of the pending patches from Peter Ekberg: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 (but also see the part of this thread http://thread.gmane.org/gmane.comp.gnu.libtool.general/7182 that starts with 'msvs support' (sic)). It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. When that is applied, you will be able to configure with AR=link -lib or AR=lib and get the desired functionality. If someone (hint, hint) can get GNU binutils ar to do the one-by-one extraction nicely, or find some other nice way to achieve the extraction, I would not mind either.. I guess one way could be to collect the dirnames of all members from `ar t' and func_mkdir_p them.. or a nice subset of that.. then actually extract all members.. Sorry, I was thinking out loud. Cheers, Ralf /bin/sh ./libtool --tag=CC --mode=link pgcc -g -no-undefined -o libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info *snip* 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 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
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. :-( I did not know gmane expires attachments or hides them. This is the same article: http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html Cheers, Ralf I guess I should have replied syaing I checked that (after posting). I applied the patch but unfortunately some Hunks failed so I'm applying them by hand and testing them. For reference, here is the output of patch. Some of the failures are likely due to my PGI changes. bash-3.00$ patch -p0 ~/head-msys_msvc-13.patch patching file Makefile.am Hunk #1 succeeded at 406 (offset 28 lines). patching file libltdl/config/ltmain.m4sh Hunk #1 succeeded at 714 (offset 11 lines). Hunk #2 FAILED at 1054. Hunk #3 succeeded at 1355 (offset 35 lines). Hunk #4 succeeded at 2683 (offset 35 lines). Hunk #5 succeeded at 4170 (offset 43 lines). Hunk #6 succeeded at 4765 (offset 40 lines). Hunk #7 succeeded at 4794 (offset 40 lines). Hunk #8 succeeded at 5392 (offset 68 lines). Hunk #9 succeeded at 5626 with fuzz 2 (offset 99 lines). Hunk #10 succeeded at 5933 (offset 99 lines). Hunk #11 succeeded at 5989 (offset 99 lines). Hunk #12 succeeded at 6096 (offset 99 lines). Hunk #13 succeeded at 6274 (offset 99 lines). Hunk #14 succeeded at 6567 (offset 113 lines). 1 out of 14 hunks FAILED -- saving rejects to file libltdl/config/ltmain.m4sh.rej patching file libltdl/m4/libtool.m4 Hunk #1 succeeded at 1209 (offset 7 lines). Hunk #2 succeeded at 1271 (offset 7 lines). Hunk #3 succeeded at 2108 (offset 13 lines). Hunk #4 succeeded at 3027 (offset 39 lines). Hunk #5 succeeded at 3045 (offset 39 lines). Hunk #6 succeeded at 4026 (offset 84 lines). Hunk #7 succeeded at 4137 (offset 88 lines). Hunk #8 succeeded at 4330 (offset 103 lines). Hunk #9 FAILED at 4458. Hunk #10 FAILED at 4484. Hunk #11 succeeded at 5094 (offset 131 lines). Hunk #12 FAILED at 5470. Hunk #13 succeeded at 5497 with fuzz 2 (offset 132 lines). Hunk #14 succeeded at 5874 (offset 143 lines). 3 out of 14 hunks FAILED -- saving rejects to file libltdl/m4/libtool.m4.rej patching file tests/demo/foo.h patching file tests/depdemo/sysdep.h patching file tests/depdemo/l1/l1.h patching file tests/depdemo/l2/l2.h patching file tests/depdemo/l3/l3.h patching file tests/depdemo/l4/l4.h patching file tests/pdemo/foo.h
Re: PGI Compiler patch for cygwin
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 [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] 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
Re: PGI Compiler patch for cygwin
* Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] 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? Cheers, Ralf
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. :-( I did not know gmane expires attachments or hides them. This is the same article: http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html Cheers, Ralf I can't seem to shake this error. Attahed is the config.log and make output in a bzipped tar file. Chris pgi_patch_error.tar.bz2 Description: BZip2 compressed data
Re: PGI Compiler patch for cygwin
Yes, I can, but it will have to wait till tuesday when I go back to work. Chris On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:08:33PM CET: The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support? Thanks, Ralf
PGI Compiler patch for cygwin
The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. pgi.patch Description: Binary data
