How to ignore dependency_libs? (Was: Libtool adding libraries differently than needed with compiler wrappers)

2011-04-28 Thread John R. Cary 

So I have more information on this problem.

At the link time, the executables here are linked to
some static libtool-built libs.  They are picking up
the dependency_libs variable in the associate .la file.

I can prevent this by removing the .la file after installation
of those dependency libraries.

Is there a way to tell libtool to ignore dependency_libs value
in the .la files of any libraries that are linked in?

Thx.John Cary


On Fri, 22 Apr 2011, John R. Cary wrote:


We have a project using libtool on a Cray-XT4 using pathscale.
For compiling in parallel, we are supposed to use the compiler
wrapper, in this case ftn, that adds various libraries.  A particular
complexity is that one has to switch libraries between front and
back end nodes, and this is done with LD_LIBRARY_PATH.  We have
a problem, in that libtool seems to extract libraries from
the wrapper and put them at the end of the link line in a way
that the linker exits with an error.

System information
x86_64-unknown-linux-gnu
bash
ftn (wrapping pathf90)
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld
libtool (GNU libtool) 2.4
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1

The failure is

/bin/sh ../../libtool --tag=FC --tag=FC  --mode=link ftn 
-I../../interfaces/wrap -I../../interfaces/src 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/include 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/include 
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include 
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/include 
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore   -o runFlowShear runFlowShear.o libfmcfm.la 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf 
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf 
-lGYRO -lNEO -lTGLF 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib 
-llsode -lnlother -lr8slatec 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib 
-lrfftw -lfftw /opt/acml/4.2.0/pathscale64/lib/libacml.a 
/opt/acml/4.2.0/pathscale64/lib/libacml.a 
/opt/acml/4.2.0/pathscale64/lib/libacml_mv.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/lib 
-lezcdf -lvshdf5 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netcdf-4.1.1-par/lib 
-lnetcdf -lnetcdf_c++ 
-L/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/lib -lhdf5_fortran 
-lhdf5_hl -lhdf5 /global/common/franklin/usg/szip/2.1/lib/libsz.a -lz
libtool: link: ftn -I../../interfaces/wrap -I../../interfaces/src 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/include 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/include 
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include 
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/include 
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore -o runFlowShear runFlowShear.o  ./.libs/libfmcfm.a 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libglf23mpi.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libmmm95.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libifspppl.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libnclass.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libkapisn.a 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libGYRO.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libNEO.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libTGLF.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/liblsode.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/libnlother.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/libr8slatec.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib 
/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib/librfftw.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib/libfftw.a 
/opt

Libtool adding libraries differently than needed with compiler wrappers

2011-04-22 Thread John R. Cary 

We have a project using libtool on a Cray-XT4 using pathscale.
For compiling in parallel, we are supposed to use the compiler
wrapper, in this case ftn, that adds various libraries.  A particular
complexity is that one has to switch libraries between front and
back end nodes, and this is done with LD_LIBRARY_PATH.  We have
a problem, in that libtool seems to extract libraries from
the wrapper and put them at the end of the link line in a way
that the linker exits with an error.

System information
x86_64-unknown-linux-gnu
bash
ftn (wrapping pathf90)
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld
libtool (GNU libtool) 2.4
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1

The failure is

/bin/sh ../../libtool --tag=FC --tag=FC  --mode=link ftn  
-I../../interfaces/wrap -I../../interfaces/src 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/include 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/include 
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include 
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/include 
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore   -o runFlowShear runFlowShear.o libfmcfm.la 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf 
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf 
-lGYRO -lNEO -lTGLF 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib 
-llsode -lnlother -lr8slatec 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib 
-lrfftw -lfftw /opt/acml/4.2.0/pathscale64/lib/libacml.a 
/opt/acml/4.2.0/pathscale64/lib/libacml.a 
/opt/acml/4.2.0/pathscale64/lib/libacml_mv.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/lib 
-lezcdf -lvshdf5 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netcdf-4.1.1-par/lib 
-lnetcdf -lnetcdf_c++ 
-L/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/lib 
-lhdf5_fortran -lhdf5_hl -lhdf5 
/global/common/franklin/usg/szip/2.1/lib/libsz.a -lz
libtool: link: ftn -I../../interfaces/wrap -I../../interfaces/src 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/include 
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/include 
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include 
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/include 
-extend-source -byteswapio -fno-second-underscore -r8 -O2 
-fno-second-underscore -o runFlowShear runFlowShear.o  
./.libs/libfmcfm.a 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libglf23mpi.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libmmm95.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libifspppl.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libnclass.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1341-par/lib/pathf/libkapisn.a 
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libGYRO.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libNEO.a 
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196-par/lib/pathf/libTGLF.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/liblsode.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/libnlother.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12-r51-ser/lib/libr8slatec.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib 
/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib/librfftw.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/lib/libfftw.a 
/opt/acml/4.2.0/pathscale64/lib/libacml.a 
/opt/acml/4.2.0/pathscale64/lib/libacml_mv.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/lib 
/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/lib/libezcdf.a 
/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0.47-r114-par/lib/libvshdf5.a 
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netcdf-4.1.1-par/lib

Re: Libtool adding libraries differently than needed with compilerwrappers

2011-04-22 Thread John R. Cary 

Hi Nitin,

I take the link line output from libtool and throw it into a shell 
script, then

I remove those entries and run the script.

Thx...John

On 4/22/2011 10:25 AM, Kapoor, Nitin wrote:

Hi John,

How are you removing the following paths from you link:

/opt/fftw/3.2.2.1/lib/libfftw3.so /opt/fftw/3.2.2.1/lib/libfftw3f.so
/opt/cray/pmi/1.0-1..7901.22.1.ss/lib64/libpmi.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so

and

-lgcc_s


Are you hand editing the libtool script ?


Thanks

Nitin.

-Original Message-
From: libtool-bounces+nkapoor=sensis@gnu.org
[mailto:libtool-bounces+nkapoor=sensis@gnu.org] On Behalf Of John R.
Cary
Sent: Friday, April 22, 2011 9:17 AM
To: libtool@gnu.org
Subject: Libtool adding libraries differently than needed with
compilerwrappers

We have a project using libtool on a Cray-XT4 using pathscale.
For compiling in parallel, we are supposed to use the compiler
wrapper, in this case ftn, that adds various libraries.  A particular
complexity is that one has to switch libraries between front and
back end nodes, and this is done with LD_LIBRARY_PATH.  We have
a problem, in that libtool seems to extract libraries from
the wrapper and put them at the end of the link line in a way
that the linker exits with an error.

System information
x86_64-unknown-linux-gnu
bash
ftn (wrapping pathf90)
-extend-source -byteswapio -fno-second-underscore -r8 -O2
-fno-second-underscore
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin
/ld
libtool (GNU libtool) 2.4
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1

The failure is

/bin/sh ../../libtool --tag=FC --tag=FC  --mode=link ftn
-I../../interfaces/wrap -I../../interfaces/src
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1
96-par/include
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-
r1341-par/include
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0
.47-r114-par/include
-extend-source -byteswapio -fno-second-underscore -r8 -O2
-fno-second-underscore   -o runFlowShear runFlowShear.o libfmcfm.la
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-
r1341-par/lib/pathf
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1
96-par/lib/pathf
-lGYRO -lNEO -lTGLF
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.
12-r51-ser/lib
-llsode -lnlother -lr8slatec
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/l
ib
-lrfftw -lfftw /opt/acml/4.2.0/pathscale64/lib/libacml.a
/opt/acml/4.2.0/pathscale64/lib/libacml.a
/opt/acml/4.2.0/pathscale64/lib/libacml_mv.a
-L/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0
.47-r114-par/lib
-lezcdf -lvshdf5
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netcdf-4.1.1-par
/lib
-lnetcdf -lnetcdf_c++
-L/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/lib
-lhdf5_fortran -lhdf5_hl -lhdf5
/global/common/franklin/usg/szip/2.1/lib/libsz.a -lz
libtool: link: ftn -I../../interfaces/wrap -I../../interfaces/src
-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1
96-par/include
-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-
r1341-par/include
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include
-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0
.47-r114-par/include
-extend-source -byteswapio -fno-second-underscore -r8 -O2
-fno-second-underscore -o runFlowShear runFlowShear.o
./.libs/libfmcfm.a
-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-
r1341-par/lib/pathf
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1
341-par/lib/pathf/libglf23mpi.a
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1
341-par/lib/pathf/libmmm95.a
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1
341-par/lib/pathf/libifspppl.a
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1
341-par/lib/pathf/libnclass.a
/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-r1
341-par/lib/pathf/libkapisn.a
-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1
96-par/lib/pathf
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196
-par/lib/pathf/libGYRO.a
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196
-par/lib/pathf/libNEO.a
/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r196
-par/lib/pathf/libTGLF.a
-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.
12-r51-ser/lib
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12
-r51-ser/lib/liblsode.a
/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.12
-r51-ser/lib/libnlother.a
/project/projectdirs/facets/franklin

Re: Libtool adding libraries differently than neededwith compilerwrappers

2011-04-22 Thread John R. Cary 

Hi Nitin,

I did go down this path before.

I added

AC_CONFIG_COMMANDS(rminterlibdeps,
  [
echo Executing rminterlibdeps
os_fc=`uname`-${FC};
case $os_fc in
  Linux-ftn)
echo Removing the inter-library dependencies;
sed -i.bak -e 's/postdeps=.*$/postdeps=/g' -e 
's/postdep_objects=.*$/postdep_objects=/g' -e 
's/link_all_deplibs=.*$/link_all_deplibs=no/g' libtool
sed -i.bak -e 's? -L/opt/fftw/3.2.[0-9]/lib ? ?g' -e 's? 
/opt/fftw/3.2.[0-9]/lib ? ?g' libtool

# The general one does not seem to work?
# sed -i.bak -e 's? -L/opt/fftw/3.2.[0-9].[0-9]/lib ? ?g' -e 
's? /opt/fftw/3.2.[0-9].[0-9]/lib ? ?g' libtool
sed -i.bak -e 's? -L/opt/fftw/3.2.2.1/lib ? ?g' -e 's? 
/opt/fftw/3.2.2.1/lib ? ?g' libtool

;;
esac
rm -f libtool.bak;
  ]
)

to my configure.ac, and I have:

nid00163.franklin$ grep fftw libtool
nid00163.franklin$

showing that all references to fftw in libtool have been removed, but I 
still get

the error.

ThxJohn



On 4/22/2011 10:38 AM, Kapoor, Nitin wrote:

I am having a similar issue where libtool is passing
(/usr/sfw/lib/libstdc++.so) to the linker.

libtool: link: g++ -g -O2 -D_REENTRANT -pthreads -o .libs/EnumVal
src/EnumVal/EnumVal.o  ../src/.libs/libxerces-c.so
/usr/sfw/lib/libstdc++.so -L/usr/sfw/lib -lnsl -lsocket -licuuc
-licudata -pthreads -Wl,-R -Wl,/usr/local/lib -Wl,-R -Wl,/usr/sfw/lib
ld: warning: file /usr/sfw/lib/libstdc++.so: attempted multiple
inclusion of file

I found out that it is because of the postdeps variable in the libtool
script. If you search the libtool script, you will find a similar entry
to this:-
postdeps=-lstdc++ -lm -lgcc_s -lgcc_s. If I remove -lstdc++, then I
get clean compile ( no multiple inclusion warning).

I do not know how to configure libtool to remove it by itself. This may
be your issue as well.

Thanks,

Nitin.




-Original Message-
From: libtool-bounces+nkapoor=sensis@gnu.org
[mailto:libtool-bounces+nkapoor=sensis@gnu.org] On Behalf Of John R.
Cary
Sent: Friday, April 22, 2011 12:28 PM
To: libtool@gnu.org
Subject: Re: Libtool adding libraries differently than neededwith
compilerwrappers

Hi Nitin,

I take the link line output from libtool and throw it into a shell
script, then
I remove those entries and run the script.

Thx...John

On 4/22/2011 10:25 AM, Kapoor, Nitin wrote:

Hi John,

How are you removing the following paths from you link:

/opt/fftw/3.2.2.1/lib/libfftw3.so /opt/fftw/3.2.2.1/lib/libfftw3f.so
 /opt/cray/pmi/1.0-1..7901.22.1.ss/lib64/libpmi.so
 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libstdc++.so

and

 -lgcc_s


Are you hand editing the libtool script ?


Thanks

Nitin.

-Original Message-
From: libtool-bounces+nkapoor=sensis@gnu.org
[mailto:libtool-bounces+nkapoor=sensis@gnu.org] On Behalf Of John

R.

Cary
Sent: Friday, April 22, 2011 9:17 AM
To: libtool@gnu.org
Subject: Libtool adding libraries differently than needed with
compilerwrappers

We have a project using libtool on a Cray-XT4 using pathscale.
For compiling in parallel, we are supposed to use the compiler
wrapper, in this case ftn, that adds various libraries.  A particular
complexity is that one has to switch libraries between front and
back end nodes, and this is done with LD_LIBRARY_PATH.  We have
a problem, in that libtool seems to extract libraries from
the wrapper and put them at the end of the link line in a way
that the linker exits with an error.

System information
x86_64-unknown-linux-gnu
bash
ftn (wrapping pathf90)
-extend-source -byteswapio -fno-second-underscore -r8 -O2
-fno-second-underscore


/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin

/ld
libtool (GNU libtool) 2.4
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1

The failure is

/bin/sh ../../libtool --tag=FC --tag=FC  --mode=link ftn
-I../../interfaces/wrap -I../../interfaces/src


-I/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1

96-par/include


-I/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-

r1341-par/include
-I/opt/cray/hdf5-parallel/1.8.3.1/hdf5-parallel-pathscale/include


-I/project/projectdirs/facets/franklin/contrib-path-3.2/fciowrappers-1.0

.47-r114-par/include
-extend-source -byteswapio -fno-second-underscore -r8 -O2
-fno-second-underscore   -o runFlowShear runFlowShear.o libfmcfm.la


-L/project/projectdirs/facets/franklin/internal-path-3.2/ntcc_transport-

r1341-par/lib/pathf
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn


-L/project/projectdirs/facets/franklin/internal-path-3.2/ga_transport-r1

96-par/lib/pathf
-lGYRO -lNEO -lTGLF


-L/project/projectdirs/facets/franklin/contrib-path-3.2/netlib_lite-1.0.

12-r51-ser/lib
-llsode -lnlother -lr8slatec


-L/project/projectdirs/facets/franklin/contrib-path-3.2/fftw-2.1.5-ser/l

ib
-lrfftw -lfftw /opt/acml/4.2.0/pathscale64/lib/libacml.a
/opt/acml/4.2.0/pathscale64/lib/libacml.a
/opt/acml/4.2.0/pathscale64/lib/libacml_mv.a


-L

Problem with libtool adding -pthread

2010-11-28 Thread John R. Cary 

I am tring to link with libtool using the compiler
wrappers on a Cray and with pgi.

At final link, libtool inserts the flag, -pthread, which
causes the compiler to fail.  This is shown below.
Is there some way around this?

Also, while the original link line contains
  -L/opt/fftw/3.2.2/lib -lfftw3 -lfftw3f
  -L/opt/cray/pmi/1.0-1..7901.22.1.ss/lib64 -lpmi

libtool converts the -l flags to full paths,
  /opt/fftw/3.2.2/lib/libfftw3.so /opt/fftw/3.2.2/lib/libfftw3f.so \
  /opt/cray/pmi/1.0-1..7901.22.1.ss/lib64/libpmi.so

and then the linker complains with

/usr/bin/ld: attempted static link of dynamic object 
`/opt/cray/pmi/1.0-1..7901.22.1.ss/lib64/libpmi.so'


Again - is there some way around this?

ThxJohn Cary

/bin/sh ../../libtool --tag=CXX --tag=FC  --mode=link CC 
-I/project/projectdirs/facets/cary/facetsall/fmcfm/interfaces/cppwrap/ 
-I../../interfaces/wrap/ -I../../interfaces/wrap -I../../interfaces/src 
-I/project/projectdirs/facets/franklin/internal-pgi-10.8/ga_transport-r192-par/include 
-I/project/projectdirs/facets/franklin/internal-pgi-10.8/ntcc_transport-r1339-par/include 
-I/opt/cray/hdf5-parallel/1.8.2/hdf5-parallel-pgi/include 
-I/project/projectdirs/facets/franklin/contrib-pgi-10.8/fciowrappers-1.0.44-r107-par/include 
-fast -Munroll -silent --no_using_std -DMPICH_IGNORE_CXX_SEEK -fPIC   -o 
testKapisncxx -L.libs -lfmcfmcxx -lfmcfm -L/opt/fftw/3.2.2/lib 
-L/opt/cray/pmi/1.0-1..7901.22.1.ss/lib64 
-L/opt/cray/mpt/5.1.0/xt/seastar/mpich2-pgi/lib 
-L/opt/cray/mpt/5.1.0/xt/seastar/sma/lib64 
-L/opt/xt-libsci/10.4.8/pgi/lib -L/opt/xt-xcpe/2.2.48B/lib 
-L/opt/xt-pe/default/lib -L/opt/xt-xcpe/2.2.48B/lib/snos64 
-L/opt/xt-pe/default/lib/snos64 
-L/opt/cray/xt-sysroot/2.2.20091207/usr/lib64 
-L/opt/cray/xt-sysroot/2.2.20091207/lib64 
-L/opt/cray/xt-sysroot/2.2.20091207/usr/lib/alps -L/usr/lib/alps 
-L/opt/pgi/10.8.0/linux86-64/10.8/libso 
-L/opt/pgi/10.8.0/linux86-64/10.8/lib 
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2 -lfftw3 -lfftw3f 
-lsci_quadcore_mp -lmpichf90 -lmpich -lrt -lsma -lportals -lpmi 
-lalpslli -lalpsutil -lpthread -lm -lpgmp -lpgbind -lpgf90 -lpgf90_rpm1 
-lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc 
-L/opt/cray/mpt/5.1.0/xt/seastar/mpich2-pgi/lib 
-L/project/projectdirs/facets/franklin/internal-pgi-10.8/ntcc_transport-r1339-par/lib/pgf 
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn 
-L/project/projectdirs/facets/franklin/internal-pgi-10.8/ga_transport-r192-par/lib/pgf 
-lGYRO -lNEO -lTGLF 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/netlib_lite-1.0.9-r47-ser/lib 
-llsode -lnlother -lr8slatec 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/fftw-2.1.5-ser/lib 
-lrfftw -lfftw /opt/acml/default/pgi64/lib/libacml.a 
/opt/acml/default/pgi64/lib/libacml.a 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/fciowrappers-1.0.44-r107-par/lib 
-lezcdf -lvshdf5 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/netcdf-4.1.1-ser/lib 
-lnetcdf -L/opt/cray/hdf5-parallel/1.8.2/hdf5-parallel-pgi/lib 
-lhdf5_fortran -lhdf5_hl -lhdf5  -lz  testKapisncxx.o -L.libs -lfmcfmcxx 
-lfmcfm -L/opt/fftw/3.2.2/lib 
-L/opt/cray/pmi/1.0-1..7901.22.1.ss/lib64 
-L/opt/cray/mpt/5.1.0/xt/seastar/mpich2-pgi/lib 
-L/opt/cray/mpt/5.1.0/xt/seastar/sma/lib64 
-L/opt/xt-libsci/10.4.8/pgi/lib -L/opt/xt-xcpe/2.2.48B/lib 
-L/opt/xt-pe/default/lib -L/opt/xt-xcpe/2.2.48B/lib/snos64 
-L/opt/xt-pe/default/lib/snos64 
-L/opt/cray/xt-sysroot/2.2.20091207/usr/lib64 
-L/opt/cray/xt-sysroot/2.2.20091207/lib64 
-L/opt/cray/xt-sysroot/2.2.20091207/usr/lib/alps -L/usr/lib/alps 
-L/opt/pgi/10.8.0/linux86-64/10.8/libso 
-L/opt/pgi/10.8.0/linux86-64/10.8/lib 
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2 -lfftw3 -lfftw3f 
-lsci_quadcore_mp -lmpichf90 -lmpich -lrt -lsma -lportals -lpmi 
-lalpslli -lalpsutil -lpthread -lm -lpgmp -lpgbind -lpgf90 -lpgf90_rpm1 
-lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc 
-L/opt/cray/mpt/5.1.0/xt/seastar/mpich2-pgi/lib 
-L/project/projectdirs/facets/franklin/internal-pgi-10.8/ntcc_transport-r1339-par/lib/pgf 
-lglf23mpi -lmmm95 -lifspppl -lnclass -lkapisn 
-L/project/projectdirs/facets/franklin/internal-pgi-10.8/ga_transport-r192-par/lib/pgf 
-lGYRO -lNEO -lTGLF 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/netlib_lite-1.0.9-r47-ser/lib 
-llsode -lnlother -lr8slatec 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/fftw-2.1.5-ser/lib 
-lrfftw -lfftw /opt/acml/default/pgi64/lib/libacml.a 
/opt/acml/default/pgi64/lib/libacml.a 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/fciowrappers-1.0.44-r107-par/lib 
-lezcdf -lvshdf5 
-L/project/projectdirs/facets/franklin/contrib-pgi-10.8/netcdf-4.1.1-ser/lib 
-lnetcdf -L/opt/cray/hdf5-parallel/1.8.2/hdf5-parallel-pgi/lib 
-lhdf5_fortran -lhdf5_hl -lhdf5  -lz
libtool: link: CC 
-I/project/projectdirs/facets/cary/facetsall/fmcfm/interfaces/cppwrap/ 
-I../../interfaces/wrap/ -I../../interfaces/wrap -I../../interfaces/src

Re: Problem with libtool adding -pthread

2010-11-28 Thread John R. Cary 

On 11/28/10 10:25 AM, Ralf Wildenhues wrote:

Hello John,

* John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET:

I am tring to link with libtool using the compiler
wrappers on a Cray and with pgi.

At final link, libtool inserts the flag, -pthread, which
causes the compiler to fail.  This is shown below.

Uh, that's probably because one of the installed libtool libraries you
link against was compiled with GCC and with -pthread, so it has that
flag in its inherited_linker_flags.  Easiest workaround would be to
remove that from the *.la file.

And yes, this is a libtool bug.  It should translate -pthread to the
spelling that your compiler uses for enabling threads.

Thanks for the report,
Ralf



Thanks, Ralf.  Unfortunately, I cannot apply your suggested fix,
as the library is a system library.

For now I have a workaround that I just drop back to the
the non libtool way for linking C++ code that links in a fortran
library.

Thx.John


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Disabling library dependency tracking?

2009-12-25 Thread John R. Cary 

So I got it to work by stripping stuff out of libtool:

AC_CONFIG_COMMANDS(rminterlibdeps,
 [
   echo Removing the inter-library dependencies;
   os_fc=`uname`-${FC};
   case $os_fc in
 Linux-ftn)
   cp libtool libtool.1;
   sed -e s/postdeps=.*$/postdeps=/g -e 
s/postdep_objects=.*$/postdep_objects=/g -e 
s/link_all_deplibs=.*$/link_all_deplibs=no/g libtool.1 libtool.2;
   sed -e s?-L/opt/fftw/3.2.1/lib??g -e 
s?/opt/fftw/3.2.1/lib??g libtool.2 libtool;

   ;;
   esac
   rm -f libtool.1 libtool.2;
 ]
)

Happy holidays to all!

John Cary

John R. Cary wrote:

I see lots of traffic on this subject, but I
do not know how to solve my particular situation.

On the Cray XT4 we use compiler wrappers to handle
to cross-compile situation, where one cannot have
static libs on the back-end nodes.  My understanding
is that the wrapper
takes care of the need for mostly static on the back
end nodes, with the systems libraries explicitly
not having an rpath so that upon submission the
system can change to libraries appropriate for
the back end nodes.


The final link using libtool-2.2.6b fails for an executable:

/bin/sh ../../libtool --tag=F77 --tag=FC  --mode=link ftn  
-ffixed-line-length-132 -fpic -O2 -DMPICH_IGNORE_CXX_SEEK -fPIC-o 
time_loop time_loop.o stripx.o ../../glf23/src/glf_include_mod.lo 
../../glf23/src/libGLF23.la
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3.la' was 
moved.
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3f.la' was 
moved.
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3.la' was 
moved.
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3f.la' was 
moved.
libtool: link: ftn -ffixed-line-length-132 -fpic -O2 
-DMPICH_IGNORE_CXX_SEEK -fPIC -o time_loop time_loop.o stripx.o 
../../glf23/src/glf_include_mod.o  ../../glf23/src/.libs/libGLF23.a 
/opt/fftw/3.2.1/lib/libfftw3.so /opt/fftw/3.2.1/lib/libfftw3f.so 
/opt/gcc/4.4.1/snos/lib/gcc/x86_64-suse-linux/4.4.1/libgfortranbegin.a 
/opt/gcc/4.4.1/snos/lib/../lib64/libgfortran.so -lm -pthread 
-Wl,-rpath -Wl,/opt/fftw/3.2.1/lib -Wl,-rpath 
-Wl,/opt/gcc/4.4.1/snos/lib/../lib64 -Wl,-rpath 
-Wl,/opt/fftw/3.2.1/lib -Wl,-rpath -Wl,/opt/gcc/4.4.1/snos/lib/../lib64

/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: linux target is being used
/usr/bin/ld: attempted static link of dynamic object 
`/opt/fftw/3.2.1/lib/libfftw3.so'

collect2: ld returned 1 exit status
make: *** [time_loop] Error 1

One can see that libtool has decide to add files to the
link line.  If I take them out, the executable links fine:

nid00011.franklin$  ftn -ffixed-line-length-132 -fpic -O2 
-DMPICH_IGNORE_CXX_SEEK -fPIC -o time_loop time_loop.o stripx.o 
../../glf23/src/glf_include_mod.o  ../../glf23/src/.libs/libGLF23.a

/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: linux target is being used

and can even be used to run the executable on the back end
nodes.

So I would like to disable the insertion of extra libraries
by libtool.  Is there a way to do this?

ThanksJohn Cary

PS - how does libtool decide to add these libraries?











--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572



___
http://lists.gnu.org/mailman/listinfo/libtool

Disabling library dependency tracking?

2009-12-24 Thread John R. Cary 

I see lots of traffic on this subject, but I
do not know how to solve my particular situation.

On the Cray XT4 we use compiler wrappers to handle
to cross-compile situation, where one cannot have
static libs on the back-end nodes.  My understanding
is that the wrapper
takes care of the need for mostly static on the back
end nodes, with the systems libraries explicitly
not having an rpath so that upon submission the
system can change to libraries appropriate for
the back end nodes.


The final link using libtool-2.2.6b fails for an executable:

/bin/sh ../../libtool --tag=F77 --tag=FC  --mode=link ftn  
-ffixed-line-length-132 -fpic -O2 -DMPICH_IGNORE_CXX_SEEK -fPIC-o 
time_loop time_loop.o stripx.o ../../glf23/src/glf_include_mod.lo 
../../glf23/src/libGLF23.la

libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3.la' was moved.
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3f.la' was 
moved.

libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3.la' was moved.
libtool: link: warning: library `/opt/fftw/3.2.1/lib/libfftw3f.la' was 
moved.
libtool: link: ftn -ffixed-line-length-132 -fpic -O2 
-DMPICH_IGNORE_CXX_SEEK -fPIC -o time_loop time_loop.o stripx.o 
../../glf23/src/glf_include_mod.o  ../../glf23/src/.libs/libGLF23.a 
/opt/fftw/3.2.1/lib/libfftw3.so /opt/fftw/3.2.1/lib/libfftw3f.so 
/opt/gcc/4.4.1/snos/lib/gcc/x86_64-suse-linux/4.4.1/libgfortranbegin.a 
/opt/gcc/4.4.1/snos/lib/../lib64/libgfortran.so -lm -pthread -Wl,-rpath 
-Wl,/opt/fftw/3.2.1/lib -Wl,-rpath -Wl,/opt/gcc/4.4.1/snos/lib/../lib64 
-Wl,-rpath -Wl,/opt/fftw/3.2.1/lib -Wl,-rpath 
-Wl,/opt/gcc/4.4.1/snos/lib/../lib64

/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: linux target is being used
/usr/bin/ld: attempted static link of dynamic object 
`/opt/fftw/3.2.1/lib/libfftw3.so'

collect2: ld returned 1 exit status
make: *** [time_loop] Error 1

One can see that libtool has decide to add files to the
link line.  If I take them out, the executable links fine:

nid00011.franklin$  ftn -ffixed-line-length-132 -fpic -O2 
-DMPICH_IGNORE_CXX_SEEK -fPIC -o time_loop time_loop.o stripx.o 
../../glf23/src/glf_include_mod.o  ../../glf23/src/.libs/libGLF23.a

/opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: linux target is being used

and can even be used to run the executable on the back end
nodes.

So I would like to disable the insertion of extra libraries
by libtool.  Is there a way to do this?

ThanksJohn Cary

PS - how does libtool decide to add these libraries?








--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath in later versions of libtool (fwd)

2009-08-09 Thread John R. Cary 

I forgot to cc the listJohn Cary

--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756

-- Forwarded message --
Date: Sat, 08 Aug 2009 15:14:54 -0600
From: John R. Cary c...@txcorp.com
To: Bob Friesenhahn bfrie...@simple.dallas.tx.us
Subject: Re: rpath in later versions of libtool

Bob Friesenhahn wrote:

 On Fri, 7 Aug 2009, John R. Cary wrote:
 
  I am trying to use libtool to make a static executable:
 
  /bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall 
  -Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la 
  ../uestat/.libs/libuestat.a ../uebase/libuebase.a 
  ../vshdf5/.libs/libvshdf5.a 
  -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl -lsidlstub_cxx 
  -lsidlstub_f90  -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath 
  /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp 
  -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -llapack -lblas 
  -lmpiuni/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a 
  /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
  /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a 
  /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack 
  /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath 
  /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl
 
  but it ends up not finding some libraries:

libatlas.so.3 = /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000)
 
  One can see that the -rpath on the link line is not generating anything

  like '-Wl,-rpath,...' on the g++ link line.

 Actually, we can't see that since you omitted the useful libtool output
 where it prints what it actually invoked.


Argh.  Here it is:

libtool: link: g++ -g -O2 -pipe -Wall -Wno-unused -o uecxxst ../uebase/uedge.o 
/usr/lib64/libblas.so  ./.libs/libuecxxst.a ../uestat/.libs/libuestat.a 
../uebase/libuebase.a ../vshdf5/.libs/libvshdf5.a 
-L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_cxx.a 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_f90.a 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.0 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidl.a 
/contrib/babel-1.4.0-r6662p1-static/lib/libchasmlite.a 
-L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp 
-lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -lblas -lmpiuni 
/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a 
/usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack 
-lgfortranbegin -lgfortran -lm -lz -ldl -pthread






  what am I doing wrong?

 My first guess is that there is a problem with supplying -rpath multiple
 times on the command line.  If this is the problem, perhaps libtool's output
 about what it is doing would include only
 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.0 since that is the last
 -rpath option supplied.

 The other possibility is that the problem libraries have not been registered
 with the system using 'ldconfig' and perhaps Linux needs that.


Thanks for your suggestions.  I see no -Wl,-rpath anywhere above.  As for 
ldconfig,
it that registration were necessary, I guess that would obviate the need for 
rpath?


ThxJohn Cary


--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572




___
http://lists.gnu.org/mailman/listinfo/libtool

rpath in later versions of libtool

2009-08-07 Thread John R. Cary 

I am running:

iter.cary$ autoconf --version; automake --version; libtool --version
autoconf (GNU Autoconf) 2.63
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
http://gnu.org/licenses/old-licenses/gpl-2.0.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
automake (GNU automake) 1.11
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
http://gnu.org/licenses/gpl-2.0.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey tro...@redhat.com
  and Alexandre Duret-Lutz a...@gnu.org.
iter.cary$ libtool --version
ltmain.sh (GNU libtool) 2.2.4
Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996

I am trying to use libtool to make a static executable:

/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall 
-Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la 
../uestat/.libs/libuestat.a ../uebase/libuebase.a 
../vshdf5/.libs/libvshdf5.a 
-L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl 
-lsidlstub_cxx -lsidlstub_f90  
-L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath 
/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes 
-lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 
-llapack -lblas -lmpiuni
/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a  
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a  
/usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack 
/usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath 
/usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl


but it ends up not finding some libraries:

iter.cary$ ldd uecxxst
   linux-vdso.so.1 =  (0x7fffad9ff000)
   libblas.so.3 = /usr/lib64/libblas.so.3 (0x7fb6a5685000)
   libpetscts.so = not found
   libpetscsnes.so = not found
   libpetscksp.so = not found
   libpetscdm.so = not found
   libpetscmat.so = not found
   libpetscvec.so = not found
   libpetsc.so = not found
   liblapack.so.3 = /usr/lib64/atlas/liblapack.so.3 
(0x7fb6a4ee7000)

   libgfortran.so.3 = /usr/lib64/libgfortran.so.3 (0x7fb6a4bfd000)
   libz.so.1 = /lib64/libz.so.1 (0x00393460)
   libdl.so.2 = /lib64/libdl.so.2 (0x003933a0)
   libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x00393920)
   libm.so.6 = /lib64/libm.so.6 (0x003933e0)
   libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x00393820)
   libpthread.so.0 = /lib64/libpthread.so.0 (0x00393420)
   libc.so.6 = /lib64/libc.so.6 (0x00393360)
   libf77blas.so.3 = /usr/lib64/atlas/libf77blas.so.3 
(0x7fb6a49dc000)

   libcblas.so.3 = /usr/lib64/atlas/libcblas.so.3 (0x7fb6a47bc000)
   /lib64/ld-linux-x86-64.so.2 (0x00393320)
   libatlas.so.3 = /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000)

On the libtool line I had both '-static' and '-rpath 
/usr/local/contrib/petsc-3.0.0-p7-ser/lib'

with the latter being where the libs are found:

iter.cary$ \ls /usr/local/contrib/petsc-3.0.0-p7-ser/lib
libmpiuni.a libpetscdm.so   libpetscsnes.a   libpetscvec.a
libpetsc.a  libpetscksp.a   libpetscsnes.so  libpetscvec.so
libpetsccontrib.a   libpetscksp.so  libpetsc.so  libsuperlu_3.1.a
libpetsccontrib.so  libpetscmat.a   libpetscts.a shared
libpetscdm.alibpetscmat.so  libpetscts.so

One can see that the -rpath on the link line is not generating anything
like '-Wl,-rpath,...' on the g++ link line.

what am I doing wrong?

This on

iter.cary$ uname -a
Linux iter.txcorp.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 
17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux


Thanks...John Cary







___
http://lists.gnu.org/mailman/listinfo/libtool

LD_RUN_PATH and openmpi's mpicxx

2009-08-04 Thread John R. Cary 

libtool uses LD_RUN_PATH on Linux to pass the runtime
link dirs.

Unfortunately, OpenMPI's mpicxx ignores the envvar, does
not pass it through to g++.

Is there a way around this on the libtool end?  E.g.,
some way of forcing use of -Wl,-rpath?

ThxJohn Cary

--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Fortran libraries on the Blue Gene with mpi

2009-04-18 Thread John R. Cary 

Ralf Wildenhues wrote:

login5.intrepid$ ./config.guess
./config.guess: unable to guess system type


[...]
  

config.guess timestamp = 2009-02-03

uname -m = 4400
uname -r = 4.0
uname -s = iainfo2
uname -v = 3.0



  

/bin/arch  = ppc64



  

UNAME_MACHINE = 4400
UNAME_RELEASE = 4.0
UNAME_SYSTEM  = iainfo2
UNAME_VERSION = 3.0



This looks pretty weird, as if the system hasn't fully been set up yet.
Where does that iainfo2 name come from?
  


I now see that after I downloaded config-master.tar.gz and untarred,
there was a 'uname' executable in the directory, so that was executed.

I moved that aside, and now I get

login1.intrepid$ uname -m; uname -r; uname -s; uname -v
ppc64
2.6.16.46-0.12-ppc64
Linux
#1 SMP Thu May 17 14:00:09 UTC 2007

and

login1.intrepid$ ./config.guess
powerpc64-unknown-linux-gnu


  
Thanks for the experiments.  Results:

- xlc links shared even without -qnostaticlink,
- bgxlc requires -qnostaticlink in order to link shared.
- both understand -R and -Wl,-rpath which is good.

Now can you try, for both xlc and bgxlc, whether a static library will
be accepted even with -qnostaticlink?  I.e., whether -qnostaticlink only
is prefer shared libraries over static ones or require shared
libraries, reject static ones?

bgxlc -c foo.c
ar cru libfoo.a foo.o
bgxlc -c main.c
bgxlc -o main main.o -qnostaticlink -L. -lfoo
./main
bgxlc -o main main.o -L. -lfoo
./main
  



Looks like it is prefer

login1.intrepid$ bgxlc -c foo.c
login1.intrepid$ ar cru libfoo.a foo.o
login1.intrepid$ bgxlc -c main.c
login1.intrepid$ bgxlc -o main main.o -qnostaticlink -L. -lfoo
login1.intrepid$ ./main
login1.intrepid$ bgxlc -o main main.o -L. -lfoo
login1.intrepid$ ./main
login1.intrepid$

John


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Fortran libraries on the Blue Gene with mpi

2009-04-16 Thread John R. Cary 

Hi Ralf,

Ralf Wildenhues wrote:

Hello John,


  


OK.  That's fairly easy to support in Libtool then: the only thing we
need to get right is to turn off shared library support completely for
BG/L.
  


I gave the wrong impression.  This is a BG/P.  My previous reference to the
compilers was because the BG/L compilers (I thought) are the same.


Can we assume bg* produces code for the compute nodes only?  Let's turn
the question around: how can we reliably detect that code is being
compiled for the compute nodes?
  


I don't know for sure, but the experiments at the end of this indicate that
bg compiled code works on the login nodes.

What do
  path/to/config.guess
  

login5.intrepid$ ./config.guess
./config.guess: unable to guess system type

This script, last modified 2009-02-03, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

and
 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD


If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to config-patc...@gnu.org in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-02-03

uname -m = 4400
uname -r = 4.0
uname -s = iainfo2
uname -v = 3.0

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  = ppc64
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = 4400
UNAME_RELEASE = 4.0
UNAME_SYSTEM  = iainfo2
UNAME_VERSION = 3.0


and
  CC=/opt/ibmcmp/xlc/bg/9.0/bin/bgcc path/to/config.guess
  

login5.intrepid$ CC=/opt/ibmcmp/vac/bg/9.0/bin/bgcc config.guess
././config.guess: unable to guess system type

This script, last modified 2009-02-03, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

and
 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD


If the version you run (././config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to config-patc...@gnu.org in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-02-03

uname -m = 4400
uname -r = 4.0
uname -s = iainfo2
uname -v = 3.0

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  = ppc64
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = 4400
UNAME_RELEASE = 4.0
UNAME_SYSTEM  = iainfo2
UNAME_VERSION = 3.0



output for the system triplets?  Please download the latest config.guess
and config.sub files from http://savannah.gnu.org/projects/config for
this test, and adjust CC so that it points to a C compiler (or MPI
wrapper compiler like mpixlc) defaulting to code for the compute nodes.

  




-dy instead of -dynamic (gcc)
-G instead of -qmkshrobj (xlc)
-qnostaticlink is for xlc/xlC, -Wl,-dy is for xlf*

It documents LD_LIBRARY_PATH as suitable for shlibpath_var.
No mention of hardcoding facilities.

I am unsure whether -dy/-dynamic/-qnostaticlink is the default mode of
operation.  Can you find this out for me, for both compiler suites?
(Create a shared library without an accompanying static one, link a
program with it and find out whether you need to pass the flag).
Untested:
  echo 'int foo () { return 0; }'  foo.c
  xlc -qpic -c foo.c
  xlc -qmkshrobj -o libfoo.so foo.o
  echo 'extern int foo (); int main () { return foo (); }'  main.c
  xlc -c main.c
  xlc -o main main.o -L. -lfoo  # without/with -qnostaticlink
  

Both link, neither runs

login5.intrepid$ xlc -o main main.o -L. -lfoo  # without/with -qnostaticlink
login5.intrepid$ ./main
./main: error while loading shared libraries: libfoo.so: cannot open 
shared object file: No such file or directory

login5.intrepid$ xlc -o main main.o -L. -lfoo  -qnostaticlink
login5.intrepid$ ./main
./main: error while loading shared libraries: libfoo.so: cannot open 
shared object file: No such file or directory


But with -R they do

login5.intrepid$ xlc -o main main.o -L. -lfoo  -R.
login5.intrepid$ ./main


Neither of these documents provide any indication as to hardcoding or
run paths into libraries or programs.  Can you find out whether the
runtime linker and the link editor have any kind of run path support?
You might need to look into the man pages for ld and ld.so (or whatever
its name is on this system) and search for run path, rpath,
DT_RPATH, -R, or similar names.
  


But I am doing all this for the xlc compilers, as in your example.  For 
the bg

compilers, it seems that the -qnostaticlink

Re: Fortran libraries on the Blue Gene with mpi

2009-04-14 Thread John R. Cary 

Ralf Wildenhues wrote:

Hello John,

* John R. Cary wrote on Mon, Apr 13, 2009 at 10:19:49PM CEST:
  

I am trying to link some Fortran code on the Blue Gene (P) using
the xl compilers.



Probably Libtool needs to be ported fully to this system first, or,
just the name matching be adjusted (libtool matches compilers by their
names).  Can you point us to documentation of the compiler and linker
suite of this system?  Would you be willing to go through the porting
effort with us (you'll have to answer a few questions and try out some
things on this system while we work on a patch).

Sure, I would be happy to do this.



First, the compilers are those at



http://www.alcf.anl.gov/support/usingALCF/bgl/appdocs.php



But I think it is the linking that gets to be a pain.  This is a 
cross-compile


situation, in which one compiles on 64-bit login nodes but runs on 32-bit

compute nodes.  The former can have shared objects, but the latter cannot.

The parallel compilers, e.g., mpixlf95_r, are wrappers over the

cross compilers, such as



login3.intrepid$ \ls /opt/ibmcmp/xlf/bg/11.1/bin/bg*

/opt/ibmcmp/xlf/bg/11.1/bin/bgf2003
/opt/ibmcmp/xlf/bg/11.1/bin/bgxlf2003_r


/opt/ibmcmp/xlf/bg/11.1/bin/bgf77  /opt/ibmcmp/xlf/bg/11.1/bin/bgxlf90

/opt/ibmcmp/xlf/bg/11.1/bin/bgf90  /opt/ibmcmp/xlf/bg/11.1/bin/bgxlf90_r

/opt/ibmcmp/xlf/bg/11.1/bin/bgf95  /opt/ibmcmp/xlf/bg/11.1/bin/bgxlf95

/opt/ibmcmp/xlf/bg/11.1/bin/bgfort77   /opt/ibmcmp/xlf/bg/11.1/bin/bgxlf95_r

/opt/ibmcmp/xlf/bg/11.1/bin/bgxlf  /opt/ibmcmp/xlf/bg/11.1/bin/bgxlf_r

/opt/ibmcmp/xlf/bg/11.1/bin/bgxlf2003



which are probably also wrappers that ensure that one generates

32-bit code and does not link   So in the end, I think these are all just

regular xl compilers.



My solution, btw, is simply to pull any '-R' args out after libtool:



AC_PROG_LIBTOOL

echo Cleaniing up FCLIBS for xlf

case $SERIALFC in

*mpixlf* | *bgxlf*)

  OLDFCLIBS=$FCLIBS

  unset FCLIBS

  for i in $OLDFCLIBS; do

case $i in

  -R*) ;;

  *) FCLIBS=$FCLIBS $i;;

esac

  done

  ;;

esac



John Cary















___
http://lists.gnu.org/mailman/listinfo/libtool

Fortran libraries on the Blue Gene with mpi

2009-04-13 Thread John R. Cary 

I am trying to link some Fortran code on the Blue Gene (P) using
the xl compilers.  My configure script uses

AC_PROG_LIBTOOL

and within that script I see

checking for Fortran libraries of mpixlf95_r...  
-L/opt/ibmcmp/xlsmp/bg/1.7/bglib -L/opt/ibmcmp/xlmass/bg/4.4/bglib 
-L/opt/ibmcmp/xlf/bg/11.1/bglib -R/opt/ibmcmp/lib/bg/bglib 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2/../../../../powerpc-bgp-linux/lib 
-lxlf90_r -lxlopt -lxlomp_ser -lxl -lxlfmath -lpthread -lm


The option, -R/opt/ibmcmp/lib/bg/bglib, is causing trouble with libtool,
as at the final link, I see:

/bin/sh ../../libtool --tag=FC --tag=FC  --mode=link mpixlf95_r -qfree 
-qsuffix=f=f90 -I../../interfaces/src  -w -qalign=natural -qpic -O2
-o testMmm testMmm.o ../../interfaces/test/libFMCFM.la 
/soft/apps/LAPACK/lapack_BGP.a /soft/apps/BLAS/blas_BGP.a 
-L/opt/ibmcmp/xlsmp/bg/1.7/bglib -L/opt/ibmcmp/xlmass/bg/4.4/bglib 
-L/opt/ibmcmp/xlf/bg/11.1/bglib -R/opt/ibmcmp/lib/bg/bglib 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2/../../../../powerpc-bgp-linux/lib 
-lxlf90_r -lxlopt -lxlomp_ser -lxl -lxlfmath -lpthread -lm
libtool: link: mpixlf95_r -qfree -qsuffix=f=f90 -I../../interfaces/src 
-w -qalign=natural -qpic -O2 -o testMmm testMmm.o  
../../interfaces/test/.libs/libFMCFM.a /soft/apps/LAPACK/lapack_BGP.a 
/soft/apps/BLAS/blas_BGP.a -L/opt/ibmcmp/xlsmp/bg/1.7/bglib 
-L/opt/ibmcmp/xlmass/bg/4.4/bglib -L/opt/ibmcmp/xlf/bg/11.1/bglib 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2 
-L/bgsys/drivers/ppcfloor/gnu-linux/lib/gcc/powerpc-bgp-linux/4.1.2/../../../../powerpc-bgp-linux/lib 
-lxlf90_r -lxlopt -lxlomp_ser -lxl -lxlfmath -lpthread -lm -rpath 
/opt/ibmcmp/lib/bg/bglib
/opt/ibmcmp/xlf/bg/11.1/bin/bgxlf95_r: 1501-216 (W) command option -ath 
is not recognized - passed to ld

ld: unrecognized -a option `th'


I.e., '-R' is converted to '-rpath', which  mpixlf95_r  does not like.  
It seems to separate

this into two args, one of which it keep, but then it dislikes -ath.

Am I doing something wrong?

Thanks...John Cary



___
http://lists.gnu.org/mailman/listinfo/libtool

Now --tag=F77 has disappeared

2009-03-25 Thread John R. Cary 
Thanks, Ralf, for your latest patch.  I applied this to 
automake-1.10.2.  Now

--tag=FC shows up for FC code, but there is no tag for F77 (.F, .f) code.

The F77 stanza looks analogous to the FC stanza, so not sure what is 
happening.

Perhaps only when a directory has bot F77 and FC code?

Not sureJohn Cary


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Now --tag=F77 has disappeared

2009-03-25 Thread John R. Cary 

Hi Ralf,

You minimal example works.  I will review our setup and see what I missed.

Thanks...John

Ralf Wildenhues wrote:

[ adding bug-automake ]

Hello John,

* John R. Cary wrote on Wed, Mar 25, 2009 at 05:07:17PM CET:
  
Thanks, Ralf, for your latest patch.  I applied this to automake-1.10.2.  
Now

--tag=FC shows up for FC code, but there is no tag for F77 (.F, .f) code.

The F77 stanza looks analogous to the FC stanza, so not sure what is  
happening.  Perhaps only when a directory has bot F77 and FC code?



Hmm.  The patch was written for git master, not 1.10.2, but it should
work there, too, if I read that correctly.  I cannot reproduce it with
master and the following minimal example.  Does it expose it for you?
If no, can you try to modify it so that it does?

Thanks,
Ralf

cat configure.ac 'EOF'
AC_INIT([fc-tags], [1], [/dev/null])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_F77
AC_PROG_FC
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

cat Makefile.am 'EOF'
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.f bar.f90 baz.F bla.F90
EOF

libtoolize --force
aclocal
autoconf
automake -a
grep  --tag Makefile.in   # looks ok to me

touch foo.f bar.f90 baz.F bla.F90
./configure
make# looks ok to me, too

  




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How to use compiler wrappers

2009-03-23 Thread John R. Cary 

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

How to use compiler wrappers

2009-03-22 Thread John R. Cary 

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.

Then at make time I do

make CC=wrapper.sh

to make the code.

When I do this, I get

/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?
I assume it will get the wrong tag?  (BTW, it seems to work, but
might that be by coincidence?)

If so, is there an easy fix?

I am using libtoolize (GNU libtool) 2.2.6.

ThanksJohn Cary


___
http://lists.gnu.org/mailman/listinfo/libtool