Re: g++ and -nostdlib
Richard PALO <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.patches,gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] 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. cheers