Re: How to use compiler wrappers
Hello John, * John R. Cary wrote on Sun, Mar 22, 2009 at 04:50:20PM CET: I am in a situation where due to flakey compilers (pgi) I had to write a compiler wrapper such that if code does not compile, I reduce the optimization level, then try again. My way of dealing with this is to create a compiler wrapper as a wrapper.sh.in file with c...@cc@ and so forth so that at configure time it knows the real compilers. It's probably preferable if you use the wrapper at configure time already, but name it strictly after the compiler, but with a suffix. For example, name it pgf90-wrapper. The libtool configure macros will look for the compiler name, unfortunately. Alternatively, ... make CC=wrapper.sh /bin/sh ../libtool --mode=compile /project/projectdirs/facets/cary/facetsall-franklin/physics/nubeam/par/txutils/f90 -I../../include -I ../random -I ../old_xplasma -I ../xplasma2 -I ../ezcdf -I ../pspline -I ../rfxqlo -I ../plasma_state_kernel -I ../plasma_state -I ../xstraln -O -c -o nbi_types.lo ../../nubeam/nbi_types.f90 libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [nbi_types.lo] Error 1 From documentation I can find, I see that I need to add the flag AM_LIBTOOLFLAGS = --tag=FC Will this cause problems when the directory has C or C++ code as well? ... you can use this, or simply use a more recent Automake (1.9 or newer; 1.10.2 is current) that always adds a --tag argument by itself. BTW, setting the tag but using different compilers at configure and at make time can cause libtool to choose the one from configure time when it creates shared libraries. This may or may not be what you want. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Windows-style paths for dependency_libs in .la files
I have a package with a few libraries where some of the libraries depend on the others. I specify the dependent libraries in LIBADD as $(top_builddir)/liba/liba.la. In the dependency_libs of the .la in the build directory, the paths are expanded in a UNIX fashion. On cygwin, this causes minor issues when building (I say minor because my compiler, PGI, ignores the unrecognized file). After installing the package, the dependency_libs of the installed .la file is fixed so that all the libraries are in Windows path style. Would it be possible to have the .la file in the build directory have Windows-style paths as well? For example (note the first 2 entries): In the .la file in the build directory: dependency_libs=' /home/chulbert/ISLdevel/build-cygwin-x86/scats/libseke/libseke.la /home/chulbert/ISLdevel/build-cygwin-x86/scats/libscatsio/libscatsio.la -LC:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib -Lc:/cygwin/home/chulbert/software/x86/lib C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl_edb.la c:/cygwin/home/chulbert/software/x86/lib/libxml2.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libgctpc.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libislm.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl.la -lz' In the installed .la file: dependency_libs=' C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libseke.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libscatsio.la -LC:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib -Lc:/cygwin/home/chulbert/software/x86/lib C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl_edb.la c:/cygwin/home/chulbert/software/x86/lib/libxml2.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libgctpc.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libislm.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl.la -lz' Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to use compiler wrappers
Thanks, Ralf. Sounds like what I am doing is at least okay, since the wrapper just wraps the configured compiler. But on another note, I was using b0201.bassi$ automake --version automake (GNU automake) 1.10.2 and it seems that --tag showed up for f77 code, but not for f90 (--tag=FC). FYI. Thanks...John Ralf Wildenhues wrote: Hello John, * John R. Cary wrote on Sun, Mar 22, 2009 at 04:50:20PM CET: I am in a situation where due to flakey compilers (pgi) I had to write a compiler wrapper such that if code does not compile, I reduce the optimization level, then try again. My way of dealing with this is to create a compiler wrapper as a wrapper.sh.in file with c...@cc@ and so forth so that at configure time it knows the real compilers. It's probably preferable if you use the wrapper at configure time already, but name it strictly after the compiler, but with a suffix. For example, name it pgf90-wrapper. The libtool configure macros will look for the compiler name, unfortunately. Alternatively, ... make CC=wrapper.sh /bin/sh ../libtool --mode=compile /project/projectdirs/facets/cary/facetsall-franklin/physics/nubeam/par/txutils/f90 -I../../include -I ../random -I ../old_xplasma -I ../xplasma2 -I ../ezcdf -I ../pspline -I ../rfxqlo -I ../plasma_state_kernel -I ../plasma_state -I ../xstraln -O -c -o nbi_types.lo ../../nubeam/nbi_types.f90 libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [nbi_types.lo] Error 1 From documentation I can find, I see that I need to add the flag AM_LIBTOOLFLAGS = --tag=FC Will this cause problems when the directory has C or C++ code as well? ... you can use this, or simply use a more recent Automake (1.9 or newer; 1.10.2 is current) that always adds a --tag argument by itself. BTW, setting the tag but using different compilers at configure and at make time can cause libtool to choose the one from configure time when it creates shared libraries. This may or may not be what you want. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to use compiler wrappers
Hello John,
* John R. Cary wrote on Mon, Mar 23, 2009 at 08:02:43PM CET:
But on another note, I was using
b0201.bassi$ automake --version
automake (GNU automake) 1.10.2
and it seems that --tag showed up for f77 code, but not for f90 (--tag=FC).
Thanks for mentioning that. It looks like a bug in Automake. I'm
applying this patch to fix it, and putting you in automake/THANKS.
Cheers,
Ralf
Use --tag=FC with libtool also for .f90 files.
* automake.in: Set 'libtool_tag' for language `fc'.
* tests/fort5.test: Grep for the tag.
* THANKS: Update.
Report by John R. Cary.
diff --git a/automake.in b/automake.in
index 9367a08..c1321f0 100755
--- a/automake.in
+++ b/automake.in
@@ -920,6 +920,7 @@ register_language ('name' = 'fc',
'compiler' = 'FCCOMPILE',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'FC',
'lder' = 'FCLD',
'ld' = '$(FC)',
'pure' = 1,
diff --git a/tests/fort5.test b/tests/fort5.test
index d39bb21..4390711 100755
--- a/tests/fort5.test
+++ b/tests/fort5.test
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2006 Free Software Foundation, Inc.
+# Copyright (C) 2006, 2009 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -84,6 +84,9 @@ $AUTOCONF
# skip in this case:
grep LT_PREREQ configure Exit 77
+# Ensure we use --tag for f90, too.
+grep --tag=FC Makefile.in
+
# configure may Exit 77 if no compiler is found,
# or if the compiler cannot compile Fortran 90 files).
./configure
___
http://lists.gnu.org/mailman/listinfo/libtool
