Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: What do path/to/config.guess and CC=/opt/ibmcmp/xlc/bg/9.0/bin/bgcc path/to/config.guess 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. Hi Ralf and John, on the BG/P system in Garching (http://www.rzg.mpg.de/computing/hardware/BGP) config.guess outputs always powerpc64-unknown-linux-gnu. It tried with several CC settings. Cheers, Christian ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.5.2* problem
Hey, I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Is it a known behavior with that version of libtool ? Note that there is no problem with libtool 2.2.* thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
On Thu, 16 Apr 2009, Lorenzo Bettini wrote: Never try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release. what I don't understand is the not binary compatible: if I use, say 1.0 for the release flag (and the version number correctly as stated in the manual), and release another implementation of the library with the incremented version number but with the same release number, why won't it be binary compatible? Or does not binary compatible apply only if I increment also the release number? I sense some confusion. :-) The -release option specifies part of the base naming for your library so that it becomes part of the base library name. For example, libfoo-1.0.so and libfoo-2.0.so. To the operating system these libraries are completely different and might have well been named libfoo.so and libbar.so. The libraries might otherwise be entirely the same and could be binary compatible but the operating system won't know it. Very few packages use the -release option. The -version-info option specifies library versioning information that the operating system will use when deciding which similarly named library to use. On most Unix systems, this forms the numeric part in the library file name after .so. Different systems use different rules when deciding how to treat this version information. Assuming that libraries are from the same release, the correct library will be used as long as you follow the libtool rules when updating the -version-info argument. There are many forms of binary compatible. For example, a newer library might add a new function but otherwise be the same so an already existing application (using an older library) can safely use it. A newer application depending on the newer library could not safely use the older library since it might be using the new function the new function might not be present. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.2* problem
On Thu, 16 Apr 2009, Vincent Torri wrote: I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Other than libtool convenience libraries (which are not used like a normal library) it is not supported to link static libraries when creating a DLL. Any static libraries need to be applied when linking programs which depend on the DLL. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.2* problem
Hello Vincent, * Vincent Torri wrote on Thu, Apr 16, 2009 at 01:04:00PM CEST: I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Is it a known behavior with that version of libtool ? Note that there is no problem with libtool 2.2.* Most likely your 1.5.2* is from Debian which, on GNU/Linux, enables link_all_deplibs=no which the FSF version doesn't do. Hmm, maybe some old FSF version did, but then backed that out again, I don't remember. You can find out with ./libtool --config | grep ^link_all_deplibs= Or I completely misunderstood the question and Bob didn't. :-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.2* problem
On Thu, 16 Apr 2009, Ralf Wildenhues wrote: Hello Vincent, * Vincent Torri wrote on Thu, Apr 16, 2009 at 01:04:00PM CEST: I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Is it a known behavior with that version of libtool ? Note that there is no problem with libtool 2.2.* Most likely your 1.5.2* is from Debian which, on GNU/Linux, enables link_all_deplibs=no which the FSF version doesn't do. Hmm, maybe some old FSF version did, but then backed that out again, I don't remember. it's indeed a debian. You can find out with ./libtool --config | grep ^link_all_deplibs= i get: link_all_deplibs=unknown Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Fortran libraries on the Blue Gene with mpi
* Christian Rössel wrote on Thu, Apr 16, 2009 at 10:41:38AM CEST: Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: What do path/to/config.guess and CC=/opt/ibmcmp/xlc/bg/9.0/bin/bgcc path/to/config.guess 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. on the BG/P system in Garching (http://www.rzg.mpg.de/computing/hardware/BGP) config.guess outputs always powerpc64-unknown-linux-gnu. It tried with several CC settings. Hmm. What is the output of these commands? uname -mrsv uname -p uname -X /bin/arch /usr/bin/arch -k /usr/convex/getsysinfo /usr/bin/hostinfo /bin/machine /usr/bin/oslevel /bin/universe (We still need answers for the remaining question from my previous mail, BTW.) Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
Bob Friesenhahn wrote: On Thu, 16 Apr 2009, Lorenzo Bettini wrote: Never try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release. what I don't understand is the not binary compatible: if I use, say 1.0 for the release flag (and the version number correctly as stated in the manual), and release another implementation of the library with the incremented version number but with the same release number, why won't it be binary compatible? Or does not binary compatible apply only if I increment also the release number? I sense some confusion. :-) well... :-) The -release option specifies part of the base naming for your library so that it becomes part of the base library name. For example, libfoo-1.0.so and libfoo-2.0.so. To the operating system these libraries are completely different and might have well been named libfoo.so and libbar.so. The libraries might otherwise be entirely the same and could be binary compatible but the operating system won't know it. Very few packages use the -release option. OK, so they would be different because they'd have a different name; but if I used the same release number (e.g., only the major number for example 1, instead of 1.1) they'd still be compatible, wouldn't they? I mean not binary compatible in the documentation refers only to different names The -version-info option specifies library versioning information that the operating system will use when deciding which similarly named library to use. On most Unix systems, this forms the numeric part in the library file name after .so. Different systems use different rules when deciding how to treat this version information. Assuming that libraries are from the same release, the correct library will be used as long as you follow the libtool rules when updating the -version-info argument. There are many forms of binary compatible. For example, a newer library might add a new function but otherwise be the same so an already existing application (using an older library) can safely use it. A newer application depending on the newer library could not safely use the older library since it might be using the new function the new function might not be present. so would you suggest to use only version info and no release info, am I right? I was only concerned about the fact that the release number of the library is not visible anywhere and that it would force the use to specify a name together with the number... thanks Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
* Lorenzo Bettini wrote on Thu, Apr 16, 2009 at 09:30:43PM CEST: Bob Friesenhahn wrote: The -release option specifies part of the base naming for your library so that it becomes part of the base library name. For example, libfoo-1.0.so and libfoo-2.0.so. To the operating system these libraries are completely different and might have well been named libfoo.so and libbar.so. The libraries might otherwise be entirely the same and could be binary compatible but the operating system won't know it. Very few packages use the -release option. OK, so they would be different because they'd have a different name; Yep. but if I used the same release number (e.g., only the major number for example 1, instead of 1.1) they'd still be compatible, wouldn't they? If their -version-info is also compatible, yes. I mean not binary compatible in the documentation refers only to different names This sentence seems to be confused. so would you suggest to use only version info and no release info, am I right? Yes, definitely. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: version and release number
On Thu, 16 Apr 2009, Lorenzo Bettini wrote: so would you suggest to use only version info and no release info, am I right? I was only concerned about the fact that the release number of the library is not visible anywhere and that it would force the use to specify a name together with the number... There are a few reasons for using release info. Some projects don't care about binary compatibility or updates to libraries so they could use release info to differentiate between releases. Other projects maintain parallel branches of the software (e.g. older and newer) and want an easy way to allow the multiple branches to be distributed without fear that they will collide with other branch's version info and end up producing shared libraries with the same names. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Fortran libraries on the Blue Gene with mpi
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
