GNU bug report logs - #9535
sunpro and -library=stdcxx4

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9535 in the body.
You can then email your comments to 9535 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marc Glisse <marc.glisse <at> inria.fr>
To: bug-libtool <at> gnu.org
Subject: sunpro and -library=stdcxx4
Date: Sat, 17 Sep 2011 12:19:02 +0200 (CEST)

Hello,

there was a commit in 2006 to support the sunpro option -library=stlport4:

2006-08-01  Albert Chin <china <at> thewrittenword.com>

        * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]:
        Don't set $postdeps to "-lCstd -lCrun" if
        "-library=stlport4" set in CXXFLAGS as stlport4 C++
        library incompatible with Cstd C++ library. Use
        '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'.


This compiler now also supports one more alternative 
(solaris-only): -library=stdcxx4
I assume it should receive the same treatment as -library=stlport4 ?

-- 
Marc Glisse

Message #8 received at 9535 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Marc Glisse <marc.glisse <at> inria.fr>
Cc: 9535 <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Mon, 03 Oct 2011 12:56:52 -0500

[Message part 1 (text/plain, inline)]

On 09/17/2011 05:19 AM, Marc Glisse wrote:
> Hello,
>
> there was a commit in 2006 to support the sunpro option -library=stlport4:
>
> 2006-08-01 Albert Chin <china <at> thewrittenword.com>
>
> * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]:
> Don't set $postdeps to "-lCstd -lCrun" if
> "-library=stlport4" set in CXXFLAGS as stlport4 C++
> library incompatible with Cstd C++ library. Use
> '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'.
>
>
> This compiler now also supports one more alternative (solaris-only):
> -library=stdcxx4
> I assume it should receive the same treatment as -library=stlport4 ?
>

Is this all that's required?

Peter

[library_stdcxx4.patch (text/x-patch, attachment)]

Message #11 received at 9535 <at> debbugs.gnu.org (full text, mbox):

From: Marc Glisse <marc.glisse <at> inria.fr>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: 9535 <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Mon, 3 Oct 2011 20:11:00 +0200 (CEST)

On Mon, 3 Oct 2011, Peter O'Gorman wrote:

> On 09/17/2011 05:19 AM, Marc Glisse wrote:
>> Hello,
>> 
>> there was a commit in 2006 to support the sunpro option -library=stlport4:
>> 
>> 2006-08-01 Albert Chin <china <at> thewrittenword.com>
>> 
>> * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]:
>> Don't set $postdeps to "-lCstd -lCrun" if
>> "-library=stlport4" set in CXXFLAGS as stlport4 C++
>> library incompatible with Cstd C++ library. Use
>> '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'.
>> 
>> 
>> This compiler now also supports one more alternative (solaris-only):
>> -library=stdcxx4
>> I assume it should receive the same treatment as -library=stlport4 ?
>
> Is this all that's required?

I would guess so, but I don't currently have a solaris 11 handy to check. 
In any case it seems rather safe... (if user specifies -library=stdcxx4, 
don't add -library=Cstd which is incompatible)

The option is documented here:
http://download.oracle.com/docs/cd/E18659_01/html/821-1383/gkcai.html

-- 
Marc Glisse

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marc Glisse <marc.glisse <at> inria.fr>
To: bug-libtool <at> gnu.org
Subject: Re: sunpro and -library=stdcxx4
Date: Thu, 11 Dec 2014 17:24:09 +0100 (CET)

On Sat, 17 Sep 2011, Marc Glisse wrote:

> there was a commit in 2006 to support the sunpro option -library=stlport4:
>
> 2006-08-01  Albert Chin <china <at> thewrittenword.com>
>
>        * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]:
>        Don't set $postdeps to "-lCstd -lCrun" if
>        "-library=stlport4" set in CXXFLAGS as stlport4 C++
>        library incompatible with Cstd C++ library. Use
>        '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'.
>
>
> This compiler now also supports one more alternative (solaris-only): 
> -library=stdcxx4
> I assume it should receive the same treatment as -library=stlport4 ?

Looking at http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4 
the problem still seems present. Since then, several new ways of getting 
an incompatible ABI have appeared, the most important one being 
-std=c++11. Any -std=c++XX will give a gnu abi, as will -compat=g.

If you don't want to maintain complicated volatile conditions, it would be 
simpler to remove the whole block of code that tries to add -library=Cstd 
-library=Crun. It is easier for users to add -library=Cstd if they need it 
than remove it when it breaks things.

-- 
Marc Glisse

Message #17 received at 9535 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Marc Glisse <marc.glisse <at> inria.fr>
Cc: 9535 <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Fri, 12 Dec 2014 15:10:37 +0000

Hi Marc,

> On Dec 11, 2014, at 4:24 PM, Marc Glisse <marc.glisse <at> inria.fr> wrote:
> 
> On Sat, 17 Sep 2011, Marc Glisse wrote:
> 
>> there was a commit in 2006 to support the sunpro option -library=stlport4:
>> 
>> 2006-08-01  Albert Chin <china <at> thewrittenword.com>
>> 
>>       * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]:
>>       Don't set $postdeps to "-lCstd -lCrun" if
>>       "-library=stlport4" set in CXXFLAGS as stlport4 C++
>>       library incompatible with Cstd C++ library. Use
>>       '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'.
>> 
>> 
>> This compiler now also supports one more alternative (solaris-only): -library=stdcxx4
>> I assume it should receive the same treatment as -library=stlport4 ?
> 
> Looking at http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4 the problem still seems present. Since then, several new ways of getting an incompatible ABI have appeared, the most important one being -std=c++11. Any -std=c++XX will give a gnu abi, as will -compat=g.
> 
> If you don't want to maintain complicated volatile conditions, it would be simpler to remove the whole block of code that tries to add -library=Cstd -library=Crun. It is easier for users to add -library=Cstd if they need it than remove it when it breaks things.

Thanks for the reminder.

I applied this just now:

    http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b49ab52cb34a80aacf88698870649c7761e17c65

It doesn't change the logic of the 2006 patch, but it still seems wrong to me actually.

Shouldn't the generated libtool script be figuring out whether to add -lCstd -lCrun every
time it is called? Assuming the configure time CXX will be the only one ever used is not
ideal; and, worse, CXXFLAGS are not stored in libtool in any circumstance, and yet configure
determines the value of postdeps based on configure time CXXFLAGS contents.

Am I missing something, or is it better to move this machinery into libtool itself?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Message #20 received at 9535 <at> debbugs.gnu.org (full text, mbox):

From: Marc Glisse <marc.glisse <at> inria.fr>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: 9535 <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Fri, 12 Dec 2014 16:56:22 +0100 (CET)

On Fri, 12 Dec 2014, Gary V. Vaughan wrote:

> I applied this just now:
>
>    http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b49ab52cb34a80aacf88698870649c7761e17c65

Thanks.

> It doesn't change the logic of the 2006 patch, but it still seems wrong to me actually.

To me as well, but it seemed more likely to work if I only suggested a 
small change ;-)

> Shouldn't the generated libtool script be figuring out whether to add -lCstd -lCrun every
> time it is called? Assuming the configure time CXX will be the only one ever used is not
> ideal; and, worse, CXXFLAGS are not stored in libtool in any circumstance, and yet configure
> determines the value of postdeps based on configure time CXXFLAGS contents.
>
> Am I missing something, or is it better to move this machinery into libtool itself?

I guess it would be better to have it either completely in libtool (figure 
it out for each invocation) or completely in autoconf (let it add 
-library=Cstd to LDFLAGS for shared libraries), or not at all and let 
users specify CXX="CC -library=Cstd"... I don't have a strong opinion 
there.

-- 
Marc Glisse

Message #23 received at 9535 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Marc Glisse <marc.glisse <at> inria.fr>
Cc: 9535 <at> debbugs.gnu.org, close-9535 <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Fri, 12 Dec 2014 18:52:01 +0000

Hi Marc,

> On Dec 12, 2014, at 3:56 PM, Marc Glisse <marc.glisse <at> inria.fr> wrote:
> 
> On Fri, 12 Dec 2014, Gary V. Vaughan wrote:
> 
>> I applied this just now:
>> 
>>   http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b49ab52cb34a80aacf88698870649c7761e17c65
> 
> Thanks.
> 
>> It doesn't change the logic of the 2006 patch, but it still seems wrong to me actually.
> 
> To me as well, but it seemed more likely to work if I only suggested a small change ;-)

True enough.

Here's a better one given that you confirmed my fears of the original being brain damaged:

    http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=97f03a437983f106e41de45a0d1baf5a3ec5f04d

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Message #28 received at 9535-close <at> debbugs.gnu.org (full text, mbox):

From: Gary V. Vaughan <gary <at> gnu.org>
To: 9535-close <at> debbugs.gnu.org
Subject: Re: bug#9535: sunpro and -library=stdcxx4
Date: Fri, 12 Dec 2014 18:53:24 +0000

Hi Marc,

> On Dec 12, 2014, at 3:56 PM, Marc Glisse <marc.glisse <at> inria.fr> wrote:
> 
> On Fri, 12 Dec 2014, Gary V. Vaughan wrote:
> 
>> I applied this just now:
>> 
>>  http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b49ab52cb34a80aacf88698870649c7761e17c65
> 
> Thanks.
> 
>> It doesn't change the logic of the 2006 patch, but it still seems wrong to me actually.
> 
> To me as well, but it seemed more likely to work if I only suggested a small change ;-)

True enough.

Here's a better one given that you confirmed my fears of the original being brain damaged:

   http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=97f03a437983f106e41de45a0d1baf5a3ec5f04d

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.