Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Nov 21, 2008, at 6:55 AM, Terry Dontje wrote: I think Ethan's point above is important. We went through great lengths earlier this year to make Open MPI STL agnostic so an application can choose which STL it would like to link in. In other words there really should be no need to tie (link) libmpi to a specific STL thus allowing the application to do the actual linking to the STL it prefers. Put simply: OMPI's libmpi_cxx.* no longer uses the STL. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote: > Hello Ethan, all, > > * Ethan Mallove wrote on Thu, Nov 20, 2008 at 10:33:08PM CET: > > On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote: > > > > > > Ah, ok. Please try the patch below instead of yours, thanks. > > > > Your patch seems to work, though I get this: > > > >libtool: Version mismatch error. This is libtool 2.2.7a, but the > >libtool: definition of this LT_INIT comes from libtool 2.2.6. > >libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a > >libtool: and run autoconf again. > > > > I take it the above error will occur if I have two different libtools > > in my PATH? > > No. That means the macro files that were picked up were from Libtool > 2.2.6, while the ltmain.sh file is from 2.2.7a. > > > This comment could be a little misleading because the same is true for > > Sun Fortran 8.1 and 8.2: > > > > # Sun Fortran 8.3 passes all unrecognized flags to the linker > > OK. I think we simply didn't have any other version to test at the time > this was written. We usually list the version somewhere so we can check > for version-specific issues, should they later show up. > > I will update the comment to list '8.1 through 8.3', when I commit your > patch (sometime this weekend); thanks for testing it. > > > I don't know of a version of Sun Fortran that accepts -Wl the way GNU > > Fortran does. I will let you know if I find one. > > Thanks. > > > > > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is, > > > > this line appears in the libtool script: > > > > > > > > postdeps="-library=Cstd -library=Crun" > > > > > > Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS? > > > If not, then how can Libtool detect that you use stlport? > > > > Ok. When I use -library=stlport4, I get libstlport linked to > > libmpi_cxx, instead of libCstd. Doesn't that then lock the user into > > having to use stlport4 when we want them to be able to use either Cstd > > or stlport4? > > Hmm, yes, it does. It is a bit of a problem to let libtool avoid either > standard C++ library in general: with shared libraries or even > dlopen'able modules, this can result in undefined symbols at run time. > > As the code is currently written in libtool.m4, there is an undocumented > way which you can use to get the effects of adding neither library: set > solaris_use_stlport4=yes. You can use this, either as argument to > configure, or set it inside configure.ac (or a macro) so that it is > expanded before AC_PROG_LIBTOOL. > > However, as it is undocumented, there is no guarantee that it will > continue to work indefinitely. What Libtool should instead do future is > provide some configure flag to allow to specify that no C++ standard > library is to be linked in by default. That would help for a couple of > different setups with other compilers as well. IMHO OpenMPI can use > the solaris_use_stlport4=yes until such a functionality is in place. Nice. This workaround works. I don't suppose there's a similar workaround to unset "wl" in the FC libtool section? If not, I think we still need the heinous post-configure workaround script. Otherwise, since there won't be a stable Libtool that contains the Sun Fortran fix for a while, I propose the attached patch. Thanks, Ethan > > Cheers, and thanks, > Ralf > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel Index: configure.ac === --- configure.ac(revision 19845) +++ configure.ac(working copy) @@ -1071,6 +1076,12 @@ ompi_show_subtitle "Libtool configuration" +# Use the undocumented solaris_use_stlport4 libtool variable to turn off any +# Cstd/stlport4 linkage. This allows Open MPI to be C++ STL agnostic. +if test "x$ompi_cv_c_compiler_vendor" = "xsun"; then +solaris_use_stlport4="yes" +fi + dnl Not all versions of LT set the PACKAGE_VERSION m4_ifdef([LT_PACKAGE_VERSION], [], [m4_define([LT_PACKAGE_VERSION], [1.5.22])]) @@ -1356,3 +1367,10 @@ test/datatype/Makefile ]) AC_OUTPUT + +# Fix libtool script bug that passes -Wl to f90, which Sun f90 does not understand. +# (This can be removed if using Libtool 2.2.7 or higher) +ompi_patch_libtool_for_sun_studio="config/patch-libtool-for-sun-studio.pl" +if test "x$ompi_cv_c_compiler_vendor" = "xsun" -a -x "$ompi_patch_libtool_for_sun_studio"; then +$ompi_patch_libtool_for_sun_studio +fi Index: config/patch-libtool-for-sun-studio.pl === --- config/patch-libtool-for-sun-studio.pl (revision 0) +++ config/patch-libtool-for-sun-studio.pl (revision 0) @@ -0,0 +1,71 @@ +#!/usr/bin/env perl + +use strict; +use File::Basename; +use Data::Dumper; + +# Grab the name of this script +my $program = basename($0); + +# Call the main subroutine
[OMPI devel] SC08 slides
I'm putting all OMPI-related SC'08 slides up on the web site. Did you present anywhere at SC? If so, send me your slides (ppt; I'll convert to 1-up and 2-up PDF to post on the web site) and a short description: what booth you presented in, title, etc. I already have all the slides from the Cisco booth talks and the BOF. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
Hello Ethan, all, * Ethan Mallove wrote on Thu, Nov 20, 2008 at 10:33:08PM CET: > On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote: > > > > Ah, ok. Please try the patch below instead of yours, thanks. > > Your patch seems to work, though I get this: > >libtool: Version mismatch error. This is libtool 2.2.7a, but the >libtool: definition of this LT_INIT comes from libtool 2.2.6. >libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a >libtool: and run autoconf again. > > I take it the above error will occur if I have two different libtools > in my PATH? No. That means the macro files that were picked up were from Libtool 2.2.6, while the ltmain.sh file is from 2.2.7a. > This comment could be a little misleading because the same is true for > Sun Fortran 8.1 and 8.2: > > # Sun Fortran 8.3 passes all unrecognized flags to the linker OK. I think we simply didn't have any other version to test at the time this was written. We usually list the version somewhere so we can check for version-specific issues, should they later show up. I will update the comment to list '8.1 through 8.3', when I commit your patch (sometime this weekend); thanks for testing it. > I don't know of a version of Sun Fortran that accepts -Wl the way GNU > Fortran does. I will let you know if I find one. Thanks. > > > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is, > > > this line appears in the libtool script: > > > > > > postdeps="-library=Cstd -library=Crun" > > > > Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS? > > If not, then how can Libtool detect that you use stlport? > > Ok. When I use -library=stlport4, I get libstlport linked to > libmpi_cxx, instead of libCstd. Doesn't that then lock the user into > having to use stlport4 when we want them to be able to use either Cstd > or stlport4? Hmm, yes, it does. It is a bit of a problem to let libtool avoid either standard C++ library in general: with shared libraries or even dlopen'able modules, this can result in undefined symbols at run time. As the code is currently written in libtool.m4, there is an undocumented way which you can use to get the effects of adding neither library: set solaris_use_stlport4=yes. You can use this, either as argument to configure, or set it inside configure.ac (or a macro) so that it is expanded before AC_PROG_LIBTOOL. However, as it is undocumented, there is no guarantee that it will continue to work indefinitely. What Libtool should instead do future is provide some configure flag to allow to specify that no C++ standard library is to be linked in by default. That would help for a couple of different setups with other compilers as well. IMHO OpenMPI can use the solaris_use_stlport4=yes until such a functionality is in place. Cheers, and thanks, Ralf
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
Ethan Mallove wrote: I'm still running into the Cstd/stlport4 issue with 2.2.6. That is, this line appears in the libtool script: postdeps="-library=Cstd -library=Crun" Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS? If not, then how can Libtool detect that you use stlport? Ok. When I use -library=stlport4, I get libstlport linked to libmpi_cxx, instead of libCstd. Doesn't that then lock the user into having to use stlport4 when we want them to be able to use either Cstd or stlport4? Thanks, Ethan I think Ethan's point above is important. We went through great lengths earlier this year to make Open MPI STL agnostic so an application can choose which STL it would like to link in. In other words there really should be no need to tie (link) libmpi to a specific STL thus allowing the application to do the actual linking to the STL it prefers. --td
