Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-25 Thread Ralf Wildenhues 
* Ethan Mallove wrote on Mon, Nov 24, 2008 at 09:27:28PM CET:
> On Sun, Nov/23/2008 09:19:12AM, Ralf Wildenhues wrote:
> > 
> > While I suppose your patch works, I think in similar situations, OpenMPI
> > has resorted to patching input files to configure (like aclocal.m4 or
> > ltmain.sh).  Search autogen.sh for instances of 'patch'.
> 
> I think I got it. I patch libtool.m4 in autogen.sh after libtoolize
> creates libtool.m4. How is the patch now?

This is what I had in mind, yes.

> > (This is merely an observation; I am not an OpenMPI developer.)

Cheers,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-24 Thread Jeff Squyres 

On Nov 24, 2008, at 2:01 PM, Ralf Wildenhues wrote:

More likely, one or more of the patches are not needed with the  
Libtool

version you're using, because they have already been integrated into
that version.


Correct.


Ergo, the advantage of patching input files here is that there is a
clean upgrade path.  Except for *.rej files (which autogen.sh could
clean up after itself, I guess).


I've known about this for a long time, but never bothered to add the  
"rm" into autogen.sh.  Easy enough to do if someone cares.


--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-24 Thread Ethan Mallove 
On Sun, Nov/23/2008 09:19:12AM, Ralf Wildenhues wrote:
> * Ethan Mallove wrote on Fri, Nov 21, 2008 at 09:01:56PM CET:
> > On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote:
> > > 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.
> 
> While I suppose your patch works, I think in similar situations, OpenMPI
> has resorted to patching input files to configure (like aclocal.m4 or
> ltmain.sh).  Search autogen.sh for instances of 'patch'.
> 

I think I got it. I patch libtool.m4 in autogen.sh after libtoolize
creates libtool.m4. How is the patch now?

-Ethan


> (This is merely an observation; I am not an OpenMPI developer.)
> 
> Cheers,
> 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])])

Index: autogen.sh
===
--- autogen.sh  (revision 19845)
+++ autogen.sh  (working copy)
@@ -541,6 +541,12 @@
 aclocal.m4 > aclocal.m4.new
 cp aclocal.m4.new aclocal.m4
 rm -f aclocal.m4.new
+
+# This patch fixes a bug in Libtool's detection of the Sun Studio
+# Fortran compiler. See the below e-mail thread for more details:
+#   http://www.open-mpi.org/community/lists/devel/2008/11/4920.php
+echo "   ++ patching for Sun Studio Fortran compilers"
+patch -N -p0 < config/lt-sun-fortran.diff > /dev/null 2>&1
 fi

 run_and_check $ompi_autoconf
Index: config/lt-sun-fortran.diff
===
--- config/lt-sun-fortran.diff  (revision 0)
+++ config/lt-sun-fortran.diff  (revision 0)
@@ -0,0 +1,26 @@
+--- config/libtool.m4.orig
 config/libtool.m4
+@@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
+   ;;
+   *)
+   case `$CC -V 2>&1 | sed 5q` in
+-  *Sun\ C*)
+-# Sun C 5.9
++  *Sun\ F* | *Sun*Fortran*)
++# Sun Fortran 8.3 passes all unrecognized flags to the linker
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+-_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++_LT_TAGVAR(lt_prog_compiler_wl, $1)=''
+ ;;
+-  *Sun\ F*)
+-# Sun Fortran 8.3 passes all unrecognized flags to the linker
++  *Sun\ C*)
++# Sun C 5.9
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+-_LT_TAGVAR(lt_prog_compiler_wl, $1)=''
++_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ ;;
+   esac
+   ;;

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-24 Thread Ralf Wildenhues 
Hello Ralph,

* Ralph Castain wrote on Mon, Nov 24, 2008 at 02:39:13PM CET:
> On Nov 23, 2008, at 1:19 AM, Ralf Wildenhues wrote:
>>
>> While I suppose your patch works, I think in similar situations,  
>> OpenMPI has resorted to patching input files to configure (like
>> aclocal.m4 or ltmain.sh).  Search autogen.sh for instances of
>> 'patch'.
>
> Interesting observation - I wonder if that would explain why I recently 
> started seeing an "aclocal.m4.rej" file every time I re-gen the trunk?
>
> Maybe one of those patches has an error in it?

More likely, one or more of the patches are not needed with the Libtool
version you're using, because they have already been integrated into
that version.

Ergo, the advantage of patching input files here is that there is a
clean upgrade path.  Except for *.rej files (which autogen.sh could
clean up after itself, I guess).

Cheers,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-24 Thread Ralph Castain 


On Nov 23, 2008, at 1:19 AM, Ralf Wildenhues wrote:


* Ethan Mallove wrote on Fri, Nov 21, 2008 at 09:01:56PM CET:

On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote:

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.


While I suppose your patch works, I think in similar situations,  
OpenMPI

has resorted to patching input files to configure (like aclocal.m4 or
ltmain.sh).  Search autogen.sh for instances of 'patch'.



Interesting observation - I wonder if that would explain why I  
recently started seeing an "aclocal.m4.rej" file every time I re-gen  
the trunk?


Maybe one of those patches has an error in it?
Ralph






(This is merely an observation; I am not an OpenMPI developer.)

Cheers,
Ralf
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-23 Thread Ralf Wildenhues 
* Ethan Mallove wrote on Fri, Nov 21, 2008 at 09:01:56PM CET:
> On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote:
> > 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.

While I suppose your patch works, I think in similar situations, OpenMPI
has resorted to patching input files to configure (like aclocal.m4 or
ltmain.sh).  Search autogen.sh for instances of 'patch'.

(This is merely an observation; I am not an OpenMPI developer.)

Cheers,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-23 Thread Ralf Wildenhues 
[ Libtool list readers: this thread is
   ]

I'm applying this patch to Libtool master, to fix $wl for the Sun Ceres
Fortran compiler.

Cheers,
Ralf

Fix matching of Sun Fortran compiler on Linux.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also
match `Sun Ceres Fortran' compiler; reorder with C compiler
matching.
* THANKS: Update.
Report by Ethan Mallove.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 35d7d5c..bb2e6ef 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3941,17 +3941,17 @@ m4_if([$1], [CXX], [
;;
   *)
case `$CC -V 2>&1 | sed 5q` in
-   *Sun\ C*)
- # Sun C 5.9
+   *Sun\ F* | *Sun*Fortran*)
+ # Sun Fortran 8.3 passes all unrecognized flags to the linker
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
  ;;
-   *Sun\ F*)
- # Sun Fortran 8.3 passes all unrecognized flags to the linker
+   *Sun\ C*)
+ # Sun C 5.9
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
esac
;;

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-21 Thread Jeff Squyres 

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

2008-11-21 Thread Ethan Mallove 
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 and

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-21 Thread Ralf Wildenhues 
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

2008-11-21 Thread Terry Dontje 

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

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ethan Mallove 
On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote:
> Our previous mails overlapped, sorry about that.
> 
> * Ethan Mallove wrote on Thu, Nov 20, 2008 at 06:52:09PM CET:
> > 
> > The above appears to be looking for a Fortran version string from the
> > C compiler, but it wouldn't match our version string anyway:
> > 
> >   $ f90 -V
> >   f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28
> 
> 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?

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

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.

> Do you mind being added to libtool/THANKS (includes email address)?

I do not mind.

> > 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


> 
> Thanks,
> Ralf
> 
>   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also
> match `Sun Ceres Fortran' compiler; reorder with C compiler
>   matching.
>   * THANKS: Update.
>   Report by Ethan Mallove.
> 
> diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
> index 7fbf965..d90c4f4 100644
> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
>   ;;
>*)
>   case `$CC -V 2>&1 | sed 5q` in
> - *Sun\ C*)
> -   # Sun C 5.9
> + *Sun\ F* | *Sun*Fortran*)
> +   # Sun Fortran 8.3 passes all unrecognized flags to the linker
> _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
> _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
> -   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> +   _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
> ;;
> - *Sun\ F*)
> -   # Sun Fortran 8.3 passes all unrecognized flags to the linker
> + *Sun\ C*)
> +   # Sun C 5.9
> _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
> _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
> -   _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
> +   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> ;;
>   esac
>   ;;
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ralf Wildenhues 
Our previous mails overlapped, sorry about that.

* Ethan Mallove wrote on Thu, Nov 20, 2008 at 06:52:09PM CET:
> 
> The above appears to be looking for a Fortran version string from the
> C compiler, but it wouldn't match our version string anyway:
> 
>   $ f90 -V
>   f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28

Ah, ok.  Please try the patch below instead of yours, thanks.
Do you mind being added to libtool/THANKS (includes email address)?

> 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?

Thanks,
Ralf

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also
match `Sun Ceres Fortran' compiler; reorder with C compiler
matching.
* THANKS: Update.
Report by Ethan Mallove.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7fbf965..d90c4f4 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [
;;
   *)
case `$CC -V 2>&1 | sed 5q` in
-   *Sun\ C*)
- # Sun C 5.9
+   *Sun\ F* | *Sun*Fortran*)
+ # Sun Fortran 8.3 passes all unrecognized flags to the linker
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
  ;;
-   *Sun\ F*)
- # Sun Fortran 8.3 passes all unrecognized flags to the linker
+   *Sun\ C*)
+ # Sun C 5.9
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
- _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
esac
;;

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ralf Wildenhues 
Hello Ethan,

* Ethan Mallove wrote on Wed, Nov 19, 2008 at 09:24:16PM CET:
> 
> I'm seeing the same issue with the faulty "wl" Libtool
> variable in 2.2.6 with Linux SunStudio:

That's really weird, because this change should have fixed that:


>   make[5]: Entering directory `ompi/mpi/f90'
>   /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
> -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
> -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
> mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
> mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
> mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
>   libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
> -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  ../../../ompi/.libs/libmpi.so 
> /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
>  opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
> -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
[...]

Please post the output of
  f90 -V

and the output of
  ./libtool --tag=FC --config

to see what's going on.

Thanks,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-20 Thread Ethan Mallove 
On Wed, Nov/19/2008 03:24:16PM, Ethan Mallove wrote:
> On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote:
> > On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> > > Hello Ethan,
> > > 
> > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > > > There are a couple issues with SunStudio and Libtool:
> > > 
> > > Which Libtool version are you using?  If not 2.2.2 or newer, then please
> > > retry with 2.2.6.  If the problem persists, then we should fix Libtool
> > > rather than patching OpenMPI.  That way, other packages benefit from the
> > > fix as well.
> > > 
> > 
> > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
> > 2.2.6.
> > 
> 
> I'm seeing the same issue with the faulty "wl" Libtool
> variable in 2.2.6 with Linux SunStudio:
> 
>   ...
>   make[5]: Entering directory `ompi/mpi/f90'
>   /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
> -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
> -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
> mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
> mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
> mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
>   libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
> -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  -Wl,-rpath 
> -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
>  
> -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
>  ../../../ompi/.libs/libmpi.so 
> /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
>  opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
> -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored 
> otherwise
>   f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, 
> ignored otherwise
>  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld 
> is invoked, ignored otherwise
>  f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored 
> otherwise
>  f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, 
> ignored otherwise
>   /usr/bin/ld: unrecognized option '-Wl,-rpath'
>  /usr/bin/ld: use the --help option for usage information
>   make[5]: *** [libmpi_f90.la] Error 1
>  make[5]: Leaving directory `ompi/mpi/f90'
>   make[4]: *** [install-recursive] Error 1
>   make[4]: Leaving directory `ompi/mpi/f90'
>   make[3]: *** [install] Error 2
>  make[3]: Leaving directory `ompi/mpi/f90'
>   make[2]: *** [install-recursive] Error 1
>   make[2]: Leaving directory `ompi'
>   make[1]: *** [install] Error 2
>   make[1]: Leaving directory `ompi'
>   make: *** [install-recursive] Error 1
> 
> The wl var in auto-generated libtool script should be set to
> "".

I think I found a potential problem. I see this in configure:

case `$CC -V 2>&1 | sed 5q` in
*Sun\ C*)
  # Sun C 5.9
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl='-Wl,'
  ;;
*Sun\ F*)
  # Sun Fortran 8.3 passes all unrecognized flags to the linker
  lt_prog_compiler_pic='-KPIC'
  lt_prog_compiler_static='-Bstatic'
  lt_prog_compiler_wl=''
  ;;
esac
;;

The above appears to be looking for a Fortran version string from the
C compiler, but it wouldn't match our version string anyway:

  $ f90 -V
  f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28

The result is that lt_prog_compiler_wl never gets set to '', and it
should. See attached (untested) patch.

> 
> Less sure about the Cstd/stlport4 issue, though it does
> appear from the below thread that the issue was already
> tackled at some point:
> 
>   http://lists.gnu.org/archive/html/libtool/2008-02/msg00024.html
> 
> The thread says the Cstd/stlport4 issue was fixed in 2006.

I'm still

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Ethan Mallove 
On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote:
> On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> > Hello Ethan,
> > 
> > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > > There are a couple issues with SunStudio and Libtool:
> > 
> > Which Libtool version are you using?  If not 2.2.2 or newer, then please
> > retry with 2.2.6.  If the problem persists, then we should fix Libtool
> > rather than patching OpenMPI.  That way, other packages benefit from the
> > fix as well.
> > 
> 
> I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
> 2.2.6.
> 

I'm seeing the same issue with the faulty "wl" Libtool
variable in 2.2.6 with Linux SunStudio:

  ...
  make[5]: Entering directory `ompi/mpi/f90'
  /bin/sh ../../../libtool   --mode=link f90 -I../../../ompi/include 
-I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90  -m32 -xO5  
-export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo 
mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo 
mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil  -lm
  libtool: link: f90 -G  .libs/mpi.o .libs/mpi_sizeof.o 
.libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o 
.libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o 
.libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   -Wl,-rpath -Wl,ompi/.libs 
-Wl,-rpath 
-Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
 -Wl,-rpath 
-Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
 -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib 
-L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs
 
-L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs
 ../../../ompi/.libs/libmpi.so 
/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so
 opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm  -m32   -mt -Wl,-soname 
-Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0
  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
otherwise
  f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored 
otherwise
  f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
otherwise
 f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, 
ignored otherwise
 f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
otherwise
 f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, 
ignored otherwise
 f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored 
otherwise
 f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld 
is invoked, ignored otherwise
 f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored 
otherwise
 f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, 
ignored otherwise
  /usr/bin/ld: unrecognized option '-Wl,-rpath'
 /usr/bin/ld: use the --help option for usage information
  make[5]: *** [libmpi_f90.la] Error 1
 make[5]: Leaving directory `ompi/mpi/f90'
  make[4]: *** [install-recursive] Error 1
  make[4]: Leaving directory `ompi/mpi/f90'
  make[3]: *** [install] Error 2
 make[3]: Leaving directory `ompi/mpi/f90'
  make[2]: *** [install-recursive] Error 1
  make[2]: Leaving directory `ompi'
  make[1]: *** [install] Error 2
  make[1]: Leaving directory `ompi'
  make: *** [install-recursive] Error 1

The wl var in auto-generated libtool script should be set to
"".

Less sure about the Cstd/stlport4 issue, though it does
appear from the below thread that the issue was already
tackled at some point:

  http://lists.gnu.org/archive/html/libtool/2008-02/msg00024.html

The thread says the Cstd/stlport4 issue was fixed in 2006.

-Ethan


> Thanks,
> Ethan
> 
> 
> > Thanks,
> > Ralf
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Terry Dontje 

Ethan Mallove wrote:

On Wed, Nov/19/2008 10:05:55AM, George Bosilca wrote:
  
We're still using STL ? I was pretty much sure that we removed this 
dependency a while ago ?



Open MPI is now set up to use either of Solaris's two versions of STL. The
problem is that if libtool links in libCrun/libCstd, then bad things happen if
the user code contains code for the other STL version. (Not sure if I got that
100% right.) Dan overhauled Open MPI's handling of STL a while ago (r17448,
r17418, r17409, ...). 


-Ethan


  
I think what Ethan is trying to say is that even though OMPI does not 
require libCrun/libCstd libtool insists on adding one of them.  If I 
recall this thread correctly I think Ralf suggested we try a later 
version of autotools to see if this still exists.


--td

  george.

On Nov 19, 2008, at 09:11 , Ethan Mallove wrote:




WHAT: Add patch-libtool-for-sun-studio.pl script


WHY:

There are a couple issues with SunStudio and Libtool:

   1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by
  libtool, which can lead to STL incompatibilities on Solaris
   2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux 
Sun

  Studio)

Benefits of the fix:

   1. Anyone can easily build Open MPI using SunStudio
   2. Nightly MTT Linux/SunStudio runs will pass
   3. We can remove (most) of the Open MPI SunStudio building FAQ:
  http://www.open-mpi.org/faq/?category=building#build-sun-compilers


WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
configure.ac


WHEN: Soon


TIMEOUT: Later



One concern is that there's no precedent in Open MPI for patching libtool
*after* configure (we only patch libtool beforehand in autogen.sh). The
problem is that this particular libtool "patch" should only be used in the
case of Sun Studio which is not known until configure-time, and there does
not seem to be a generic patch that we could apply before configure.

-Ethan
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Ethan Mallove 
On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote:
> Hello Ethan,
> 
> * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> > There are a couple issues with SunStudio and Libtool:
> 
> Which Libtool version are you using?  If not 2.2.2 or newer, then please
> retry with 2.2.6.  If the problem persists, then we should fix Libtool
> rather than patching OpenMPI.  That way, other packages benefit from the
> fix as well.
> 

I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try
2.2.6.

Thanks,
Ethan


> Thanks,
> Ralf
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Ethan Mallove 
On Wed, Nov/19/2008 10:05:55AM, George Bosilca wrote:
> We're still using STL ? I was pretty much sure that we removed this 
> dependency a while ago ?

Open MPI is now set up to use either of Solaris's two versions of STL. The
problem is that if libtool links in libCrun/libCstd, then bad things happen if
the user code contains code for the other STL version. (Not sure if I got that
100% right.) Dan overhauled Open MPI's handling of STL a while ago (r17448,
r17418, r17409, ...). 

-Ethan


>
>   george.
>
> On Nov 19, 2008, at 09:11 , Ethan Mallove wrote:
>
>> 
>> WHAT: Add patch-libtool-for-sun-studio.pl script
>>
>> 
>> WHY:
>>
>> There are a couple issues with SunStudio and Libtool:
>>
>>1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by
>>   libtool, which can lead to STL incompatibilities on Solaris
>>2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux 
>> Sun
>>   Studio)
>>
>> Benefits of the fix:
>>
>>1. Anyone can easily build Open MPI using SunStudio
>>2. Nightly MTT Linux/SunStudio runs will pass
>>3. We can remove (most) of the Open MPI SunStudio building FAQ:
>>   http://www.open-mpi.org/faq/?category=building#build-sun-compilers
>>
>> 
>> WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
>> configure.ac
>>
>> 
>> WHEN: Soon
>>
>> 
>> TIMEOUT: Later
>>
>> 
>>
>> One concern is that there's no precedent in Open MPI for patching libtool
>> *after* configure (we only patch libtool beforehand in autogen.sh). The
>> problem is that this particular libtool "patch" should only be used in the
>> case of Sun Studio which is not known until configure-time, and there does
>> not seem to be a generic patch that we could apply before configure.
>>
>> -Ethan
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Ralf Wildenhues 
Hello Ethan,

* Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET:
> There are a couple issues with SunStudio and Libtool:

Which Libtool version are you using?  If not 2.2.2 or newer, then please
retry with 2.2.6.  If the problem persists, then we should fix Libtool
rather than patching OpenMPI.  That way, other packages benefit from the
fix as well.

Thanks,
Ralf

Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread George Bosilca 
We're still using STL ? I was pretty much sure that we removed this  
dependency a while ago ?


  george.

On Nov 19, 2008, at 09:11 , Ethan Mallove wrote:



WHAT: Add patch-libtool-for-sun-studio.pl script


WHY:

There are a couple issues with SunStudio and Libtool:

   1. The SunStudio libCrun/libCstd C++ libs get linked into Open  
MPI by

  libtool, which can lead to STL incompatibilities on Solaris
   2. Libtool uses the wrong linker flags for C++ and Fortran (on  
Linux Sun

  Studio)

Benefits of the fix:

   1. Anyone can easily build Open MPI using SunStudio
   2. Nightly MTT Linux/SunStudio runs will pass
   3. We can remove (most) of the Open MPI SunStudio building FAQ:
  http://www.open-mpi.org/faq/?category=building#build-sun-compilers


WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
configure.ac


WHEN: Soon


TIMEOUT: Later



One concern is that there's no precedent in Open MPI for patching  
libtool
*after* configure (we only patch libtool beforehand in autogen.sh).  
The
problem is that this particular libtool "patch" should only be used  
in the
case of Sun Studio which is not known until configure-time, and  
there does

not seem to be a generic patch that we could apply before configure.

-Ethan
studio.diff>___

devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure

2008-11-19 Thread Ethan Mallove 

WHAT: Add patch-libtool-for-sun-studio.pl script


WHY: 

There are a couple issues with SunStudio and Libtool:

1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by
   libtool, which can lead to STL incompatibilities on Solaris
2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux Sun
   Studio)

Benefits of the fix: 

1. Anyone can easily build Open MPI using SunStudio
2. Nightly MTT Linux/SunStudio runs will pass
3. We can remove (most) of the Open MPI SunStudio building FAQ:
   http://www.open-mpi.org/faq/?category=building#build-sun-compilers


WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
configure.ac


WHEN: Soon


TIMEOUT: Later



One concern is that there's no precedent in Open MPI for patching libtool
*after* configure (we only patch libtool beforehand in autogen.sh). The
problem is that this particular libtool "patch" should only be used in the
case of Sun Studio which is not known until configure-time, and there does
not seem to be a generic patch that we could apply before configure.

-Ethan
Index: configure.ac
===
--- configure.ac(revision 19845)
+++ configure.ac(working copy)
@@ -1356,3 +1361,11 @@
 test/datatype/Makefile
 ])
 AC_OUTPUT
+
+# When building with Sun Studio, we need to tweak the libtool script to:
+#   1. Set wl variable so the linker flags work correctly (on Linux)
+#   2. Set postdeps variable to avoid linking libCstd/libCrun C++ libraries
+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,93 @@
+#!/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 and exit
+&update_libtool_script;
+exit;
+
+sub update_libtool_script {
+my ($file) = @_;
+print("update_libtool_script: got @_\n");
+
+# By default, patch the libtool script in the cwd
+$file = "./libtool" if (! -e $file);
+
+# Keep a backup copy of the file lying around for debugging
+# purposes
+my $cmd = "cp $file $file.orig\n";
+print($cmd);
+system($cmd);
+
+# Read in the libtool script file
+my $contents = Read($file);
+die("Couldn't Read $file!\n") if (!$contents);
+
+my $bad_pattern1 ='(\n# ### BEGIN LIBTOOL TAG CONFIG: FC.*)\n(wl="-Wl,")';
+my $good_pattern1 = "
+# $program has reassigned wl to \"\" because Sun Studio
+# f90 (for Linux) does not pass -Wl values to the GNU linker (/usr/bin/ld)
+wl=\"\"";
+
+my $bad_pattern2 ='(\n# ### BEGIN LIBTOOL TAG CONFIG: 
CXX.*)\n(postdeps="(?:-library=Cstd)\s*(?:-library=Crun)?")';
+my $good_pattern2 = "
+# $program has commented out postdeps so that libCstd.so
+# and libCrun.so are not linked in to libmpi_cxx.so. The autogen.sh patch for
+# this same issue was supposed to take care of this, but apparently
+# Autosomething-or-other has usurped that patch and thrown in the bad -library
+# flags.
+postdeps=\"\"
+";
+
+# From perldoc perlre, the "s" modifier in s///s:
+#   Treat string as single line. That is, change "." to match any character
+#   whatsoever, even a newline, which normally it would not match. Used
+#   together, as /ms, they let the "." match any character whatsoever,
+#   while still allowing "^" and "$" to match, respectively, just after and
+#   just before newlines within the string.
+
+# Grab uname OS string
+my $os = `uname -s`;
+chomp $os;
+if ($os =~ /Linux/i) {
+print("We need to patch $file for libmpi_f90.\n");
+
+# Set wl to "" for f90
+$contents =~ s/$bad_pattern1/$1\n# $2\n$good_pattern1/s;
+}
+
+# Comment this postdeps var out of CXX section
+# postdeps="-library=Cstd -library=Crun"
+print("Patching $file to avoid linking with libCstd and libCrun.\n");
+$contents =~ s/$bad_pattern2/$1\n# $2\n$good_pattern2/s;
+
+# Write changed file out
+Write($file, $contents);
+}
+
+sub Read {
+my ($file) = @_;
+
+my $contents;
+open (INPUT, $file) or warn "Can't