Subject: bug#9535: sunpro and -library=stdcxx4

From: "Gary V. Vaughan" <[email-masked]>
Date: Fri, 12 Dec 2014 15:10:37 +0000

Hi Marc,

> On Dec 11, 2014, at 4:24 PM, Marc Glisse <[email-masked]> 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 <[email-masked]>
>> 
>>       * 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)