Re: How can I keep -lstdc++ out of $postdeps?

On 23/02/17 05:55 PM, Thomas Jahns wrote:
> On 02/23/2017 05:01 PM, Jack Bates wrote:
>> On 22/02/17 12:16 PM, Mike Frysinger wrote:
>>> On 22 Feb 2017 10:32, Jack Bates wrote:
>>>> How can I avoid dynamically linking with libstdc++?
>>>> or, how can I keep -lstdc++ out of $postdeps?
>>>
>>> let's back up.  what is it you're actually trying to do ?
>>> you want to create a statically linked C++ program ?
>>> you want to link a C program ?
>>> something else ?
>>
>> Well, I'm asking for a friend [1]. It sounds like he's got one version
>> of libstdc++ in his build infrastructure and another (older) version on
>> his production machines. He wants to avoid using the older version (I
>> think because of an issue with the STL) which is why he's trying to keep
>> -lstdc++ out of the linker arguments.
>>
>> Regardless of whether -static-libstdc++ is the solution he ultimately
>> runs with, I think he's confused about _LT_SYS_HIDDEN_LIBDEPS -- as am
>> I. The underlying compiler/linker seems to do a more refined job of
>> adding/not adding these dependencies? Is there a recommended way to
>> disable _LT_SYS_HIDDEN_LIBDEPS?
>
> I think the path of least resistance is still to install the newer
> libstc++ (CentOS can use newer developer tools [1] and has corresponding
> library packages to my knowledge).

Yes -- I don't know why he prefers to statically link, instead of 
upgrading the production machines -- although I've heard there are 1,000 
production machines, and I suspect there's a corporate policy limiting 
what's installed on them, whereas a statically linked binary is 
acceptable ... ¯\_(ツ)_/¯

Regardless, I'm curious why _LT_SYS_HIDDEN_LIBDEPS adds -lstdc++ etc. 
itself, instead of deferring to the compiler/linker -- Is this behavior 
obsolete? Is there a recommended way to disable it? It's surprising that 
the -static-libstdc++ option is broken, no?

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool