[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: g++ and -nostdlib

From: Richard PALO
Subject: Re: g++ and -nostdlib
Date: Sat, 12 Apr 2014 08:02:12 +0200
User-agent: Mozilla/5.0 (X11; SunOS i86pc; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

Le 09/11/13 07:44, Richard PALO a écrit :
I believe Chuck is oriented in the right direction.

A good example is with -fstack-protector.

gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.

I doubt very much that libtool wants to figure out whether to add the
specific libraries necessary for SSP to the link command.
It *should* however pass through the provided flags to the compiler
driver, and not strip in this case '-fstack-protector'; object of:
Bug: linking shared libraries on Cygwin results in undefined
references to __stack_chck_guard for code compiled with -fstack-protector

In this particular "worst" case, '-fstack-protector' is stripped, and
even if it passed through, the g++ '-nostdlib' defeats the purpose!

Just a comment to keep this thread alive, I've been testing this patch since it came out adapted for solaris using libtool 2.4.2 on pkgsrc-current along with the following two patches:
[PATCH] Fix linking with -fstack-protector
bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris

The description is available on address@hidden in the thread: "libtool, -fstack-protector, -nostdlib, and while we're at it -Bdirect on SunOS"

Earlier issues with perl and cups involving '-fstack-protector' seem resolved and, as indicated elsewhere, '-pthread' as well (albeit already worked around in many pkgsrc packages or the distros themselves.

If there is/are any use case(s) that break with this patch (I believe as Bob feared) they should be explicitly detailed and examined for the cause, otherwise there seems to be more merit in pushing this patch than suffering the current side effects.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]