Re: improve stlport4 check in libtool.m4

[Marc Glisse]

On Thu, 14 Aug 2008, Ralf Wildenhues wrote:

> > The point is that it is possible to use yet an other standard library
> > than stlport4 (indeed the kde on solaris effort is using the apache
> > stdcxx), in which case we also want to avoid "-library=Cstd". The
> > compiler flag that disables Cstd is -library=no%Cstd (-library=stlport4
> > is actually an alias for -library=no%Cstd,stlport4).
>
> What about -library=Crun?  Should it also be disabled upon encounter of
> -library=no%Cstd?

I think there is never any reason to disable -library=Crun. Well there is 
the prehistoric mode -compat=4 but we can ignore that. And the compiler 
provides an option -library=no%Crun to disable it, but even -library=%none 
disables everything but Crun. On the other hand, when people are not using 
Cstd, it is their responsability to link with the appropriate libraries. 
So I guess it does not really matter. When we create a shared object with 
-library=stlport4, it links with libstlport4 which is linked with Crun but 
it does not link directly with Crun, so I guess -library=Crun is still a 
useful addition there.

Proposition:
add -library=Crun unless there is -library=no%Crun
add -library=Cstd unless there is -library=stlport4 or -library=stlport4_dbg or 
-library=no%Cstd or -library=%none

This means ignoring the mode -compat=4 (most packages wouldn't compile 
anyway, so it does not matter) and ignoring that -library= can 
take several values separated by commas (it should be taken into account, 
but it makes the code a bit more complicated and I am not a shell expert).

I am not sure there is any point to the no%Crun case, but it shouldn't 
hurt.

> > Note that the variable could be renamed since it is also used on linux,
> > not only solaris, and with this patch would also be used with other
> > alternate C++ standard libraries, but that does not really matter.
>
> Oh, for maintainability this matters, though.  The variable should be
> renamed to lt_(cv_)suncxx_use_Cstd (with negated values), as far as I
> understand.  (The cv_ infix should be used if AC_CACHE_CHECK is used.)
>
> Care to provide a patch?  Bonus points for providing a testsuite
> addition also (which is fine to be SKIPped non non-Solaris, non-Sun
> compilers).

I have to admit that I am far from familiar with the code. I found the 
relevant piece of code after several calls to grep and guessed what it was 
doing. The following is completely untested, I modified only one of the 
occurences, I have no idea what to do with the cv_ infix you are 
mentionning. Handling the case where -library= has several comma-separated 
values is more complicated, it seems like libtool uses sed for this kind 
of thing.

--- old/libtool.m4      2008-08-15 02:59:15.270398067 +0200
+++ new/libtool.m4      2008-08-15 03:08:28.573045596 +0200
@@ -4031,12 +4031,20 @@
     # it if it's in CXXFLAGS. Ignore libCrun as
     # -library=stlport4 depends on it.
     case " $CXX $CXXFLAGS " in
-    *" -library=stlport4 "*)
-      solaris_use_stlport4=yes
+    *" -library=stlport4 "*|*" -library=stlport4_dbg "*|*" -library=no%Cstd "*|*" 
-library=%none "*)
+      lt_sunCC_use_Cstd=no
       ;;
     esac
-    if test "$solaris_use_stlport4" != yes; then
-      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
+    case " $CXX $CXXFLAGS " in
+    *" -library=no%Crun "*)
+      lt_sunCC_use_Crun=no
+      ;;
+    esac
+    if test "$lt_sunCC_use_Cstd" != no; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd'
+    fi
+    if test "$lt_sunCC_use_Crun" != no; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Crun'
     fi
     ;;
   esac

--
Marc Glisse