Bug reports for the GNU libtool shared library maintenance tool

headers Aquil H. Abdullah | 5 Aug 2008 21:34

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Hello Aquil,

Thanks for the bug report.

* Aquil H. Abdullah wrote on Tue, Aug 05, 2008 at 09:34:15PM CEST:
> I use a myriad of FORTRAN compilers, and libtool (to alleviate the myriad of
> headaches that come along with using a myriad of FORTRAN compilers).
> Libtool was generating lovely compilations until I moved to ifort 10.X.
> Intel has deprecated the -KPIC option and now only supports -fPIC option.

The git version of Libtool has already seen a couple of patches to this
end.  It would be nice if you could test it.  They will be part of
2.2.6.

Cheers,
Ralf

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Hello,

libtool.m4 contains a test that may set solaris_use_stlport4 and disable 
the addition of "-library=Cstd,Crun" (which is a useful addition when 
creating shared objects with the default standard library).

I would just like to replace the test:

*" -library=stlport4 "*)

by:

*" -library=stlport4 "* | *" -library=no%Cstd "*)

(note that this code occurs in 2 places in the file, both of which could 
be changed)

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

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.

--

-- 
Marc Glisse

Hello Marc,

* Marc Glisse wrote on Wed, Aug 13, 2008 at 06:50:42PM CEST:
>
> libtool.m4 contains a test that may set solaris_use_stlport4 and disable  
> the addition of "-library=Cstd,Crun" (which is a useful addition when  
> creating shared objects with the default standard library).

Yes.

> I would just like to replace the test:
>
> *" -library=stlport4 "*)
>
> by:
>
> *" -library=stlport4 "* | *" -library=no%Cstd "*)
>
> (note that this code occurs in 2 places in the file, both of which could  
> be changed)

One for Linux, one for Solaris.

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

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

Thanks,
Ralf

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
 <at>  <at>  -4031,12 +4031,20  <at>  <at> 
      # 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

Problem applies from 1.x upto current stable 2.2.4.
allow_undefined_flag and no_undefined_flag are not being
expanded correctly at least under AIX (5.3). Probably other
architectures are affected as well.
This is the last part of a library link line from a make -
  -lc -Wl,-bnoentry  -qmaxmem=20000 -qarch=ppc -Wl,-bE:.libs/libgmp.exp 
${wl}-berok
Another example (last part of link line) -
-lc -Wl,-bnoentry  -Wl,-bexpfull -Wl,-bE:.libs/libcob.exp ${wl}-bernotok

Roger While

Roger While wrote:
> 
> Problem applies from 1.x upto current stable 2.2.4.
> allow_undefined_flag and no_undefined_flag are not being
> expanded correctly at least under AIX (5.3). Probably other
> architectures are affected as well.
> This is the last part of a library link line from a make -
>  -lc -Wl,-bnoentry  -qmaxmem=20000 -qarch=ppc -Wl,-bE:.libs/libgmp.exp
> ${wl}-berok
> Another example (last part of link line) -
> -lc -Wl,-bnoentry  -Wl,-bexpfull -Wl,-bE:.libs/libcob.exp ${wl}-bernotok

Does the link fail?

Peter
--

-- 
Peter O'Gorman
http://pogma.com

In the first case yes, in the second case no but that is another story.
You get away with it because, after the shell has replaced ${wl} with nothing,
cc/xlc pass the resultant -berok/-bernotok to the linker.

Roger While

>Roger While wrote:
> >
> > Problem applies from 1.x upto current stable 2.2.4.
> > allow_undefined_flag and no_undefined_flag are not being
> > expanded correctly at least under AIX (5.3). Probably other
> > architectures are affected as well.
> > This is the last part of a library link line from a make -
> >  -lc -Wl,-bnoentry  -qmaxmem=20000 -qarch=ppc -Wl,-bE:.libs/libgmp.exp
> > ${wl}-berok
> > Another example (last part of link line) -
> > -lc -Wl,-bnoentry  -Wl,-bexpfull -Wl,-bE:.libs/libcob.exp ${wl}-bernotok
>
>Does the link fail?
>
>Peter
>--
>Peter O'Gorman
>http://pogma.com

Hello Roger,

* Roger While wrote on Sat, Aug 16, 2008 at 06:29:07AM CEST:
> In the first case yes, in the second case no but that is another story.
> You get away with it because, after the shell has replaced ${wl} with nothing,
> cc/xlc pass the resultant -berok/-bernotok to the linker.

Thanks.  Please post a full link command line, preferably also how you
invoked configure.

Cheers,
Ralf

2	June 2013
10	May 2013
10	April 2013
17	March 2013
1	February 2013
26	January 2013
8	December 2012
2	November 2012
15	October 2012
2	September 2012
11	August 2012
14	July 2012
2	June 2012
8	May 2012
7	April 2012
20	March 2012
19	February 2012
31	January 2012
23	December 2011
39	November 2011
50	October 2011
9	September 2011
32	August 2011
2	July 2011
2	June 2011
8	May 2011
49	April 2011
17	March 2011
16	February 2011
19	January 2011
22	December 2010
13	November 2010
35	October 2010
72	September 2010
51	August 2010
13	July 2010
94	June 2010
20	May 2010
14	April 2010
24	March 2010
38	February 2010
38	January 2010
56	December 2009
84	November 2009
15	October 2009
49	September 2009
16	August 2009
15	July 2009
24	June 2009
64	May 2009
31	April 2009
15	March 2009
19	February 2009
35	January 2009
48	December 2008
129	November 2008
39	October 2008
51	September 2008
33	August 2008
21	July 2008
45	June 2008
94	May 2008
170	April 2008
179	March 2008
35	February 2008
43	January 2008
19	December 2007
28	November 2007
15	October 2007
7	September 2007
25	August 2007
17	July 2007
10	June 2007
55	May 2007
25	April 2007
31	March 2007
39	February 2007
30	January 2007
11	December 2006
3	November 2006
16	October 2006
48	September 2006
30	August 2006
9	July 2006
36	June 2006
38	May 2006
16	April 2006
46	March 2006
15	February 2006
25	January 2006
19	December 2005
16	November 2005
44	October 2005
43	September 2005
55	August 2005
52	July 2005
29	June 2005
80	May 2005
88	April 2005
87	March 2005
28	February 2005
17	January 2005
61	December 2004
25	November 2004
35	October 2004
72	September 2004
62	August 2004
16	July 2004
15	June 2004
17	May 2004
48	April 2004
73	March 2004
79	February 2004
46	January 2004
12	December 2003
28	November 2003
13	October 2003
9	September 2003
11	August 2003
13	July 2003
12	June 2003
35	May 2003
25	April 2003
14	March 2003
15	February 2003
27	January 2003
24	December 2002
19	November 2002
12	October 2002
19	September 2002
9	August 2002
33	July 2002
14	June 2002
23	May 2002
16	April 2002
7	March 2002

-KPIC has been deprecated in new Intel FORTRAN Compilers (ifort)

Re: -KPIC has been deprecated in new Intel FORTRAN Compilers (ifort)

[libtool 2.2.4] testsuite: 28 45 62 70 72 failed

improve stlport4 check in libtool.m4

Re: improve stlport4 check in libtool.m4

Re: improve stlport4 check in libtool.m4

allow/no_undefined_flag

Re: allow/no_undefined_flag

Re: allow/no_undefined_flag

Re: allow/no_undefined_flag

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31