Re: g++ and -nostdlib

2013-11-08 Thread Bob Friesenhahn

On Fri, 8 Nov 2013, Peter Rosin wrote:


Hi!

There seem to be a longstanding complaint that libtool is using
-nostdlib when it links libraries using g++. It interferes with
-pthread and I think I have also seen other issues. No one can
give a satisfactory explanation why libtool does this, it seems


Isn't it because libtool wants to control the order of the linking and 
assure that all dependencies (including static) are tracked/known and 
applied at the correct times?  It wants to assure that static 
dependencies are linked into the dependent program rather than into 
some dependent shared library (and thus causing a problem).


It was common (and perhaps still is) for the GNU C++ library to be 
delivered as a static library for Windows/MinGW because C++ exceptions 
were not handled properly when thrown by DLLs.


Quite a lot of effort went into making this work the way it currently 
does.


First libtool tries to take away all of the libraries which would be 
added automatically and then it applies the libraries that GCC says it 
would use at the correct time.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



g++ and -nostdlib

2013-11-08 Thread Peter Rosin
Hi!

There seem to be a longstanding complaint that libtool is using
-nostdlib when it links libraries using g++. It interferes with
-pthread and I think I have also seen other issues. No one can
give a satisfactory explanation why libtool does this, it seems
like it is just the way it has always been and noone dares
changing it. To me, it all smells like something that was needed
once upon a time when g++ was still immature, and whatever issues
it solved we no longer need to worry about. So, just for thrills
I had a quick peek at the code, and it looks quite simple to
simply nix this obnoxious -nostdlib use.

I realize that the timing isn't the best with the alpha release
and all, but this probably needs to be tested a bit more before
it's pushed anyway, so I'm simply posting this as an RFC and
don't expect it to be committed until later.

Should it be listed as an incompatible change? Or simply a bug
fix?

BTW, it even appears to work, but please test, as I have only
done very light testing...

Oh well. Any thoughts?

Cheers,
Peter
>From a233b4562d4274053852bc0353e36931beeb4803 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 8 Nov 2013 19:01:24 +0100
Subject: [PATCH] libtool: Do not use -nostdlib when linking with g++.

Fixes part of bug#15646 and Debian bug 468555.

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [g++] 
: Drop -nostdlib, $predep_objects and
$postdep_objects.
* NEWS: Update.
---
 NEWS  |6 ++
 m4/libtool.m4 |   30 +++---
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index 0c85812..5717385 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Important incompatible changes:
+
+  - When linking shared libraries with g++, trust the compiler driver to
+interface correctly with the linker.  I.e., drop the -nostdlib
+option in this case. Fixes point 2 (and perhaps 3) in bug#15646, as
+well as Debian bug 468555.
 
 * Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc6b22..d13afc3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6046,8 +6046,8 @@ if test yes != "$_lt_caught_CXX_error"; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test yes = "$with_gnu_ld"; then
-_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
 
 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir'
 _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl--export-dynamic'
@@ -6073,7 +6073,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 # linker, instead of GNU ld.  If possible, this setting should
 # overridden to take advantage of the native linker features on
 # the platform it is being used on.
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $lib'
   fi
 
   # Commands to make compiler produce verbose output that lists
@@ -6296,7 +6296,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 
 	  if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	# If the export-symbols file already is a .def file, use it as
 	# is; otherwise, prepend EXPORTS...
 	_LT_TAGVAR(archive_expsym_cmds, $1)='if _LT_DLL_DEF_P([$export_symbols]); then
@@ -6305,7 +6305,7 @@ if test yes != "$_lt_caught_CXX_error"; then
   echo EXPORTS > $output_objdir/$soname.def;
   cat $export_symbols >> $output_objdir/$soname.def;
 fi~
-$CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $comp

Re: g++ and -nostdlib

2013-11-08 Thread Charles Wilson

On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:

Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times?  It wants to assure that static
dependencies are linked into the dependent program rather than into some
dependent shared library (and thus causing a problem).

It was common (and perhaps still is) for the GNU C++ library to be
delivered as a static library for Windows/MinGW because C++ exceptions
were not handled properly when thrown by DLLs.

Quite a lot of effort went into making this work the way it currently does.

First libtool tries to take away all of the libraries which would be
added automatically and then it applies the libraries that GCC says it
would use at the correct time.


One of my wishlist roundtuit items is to special-case this behavior for 
libtool + GNU toolchains.  For that combo, instead of the procedure Bob 
outlines, and then using $LD to linkjust use the compiler driver 
(e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1].  We're 
already passing the ABI-modifying -m and -f flags anyway, and it would 
really REALLY simplify libtool's logic...


[1] unless of course the end user put -nostdlib in $LDFLAGS or something.

--
Chuck





Re: g++ and -nostdlib

2013-11-08 Thread Richard PALO

Le 08/11/13 20:07, Charles Wilson a écrit :

On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:

Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times?  It wants to assure that static
dependencies are linked into the dependent program rather than into some
dependent shared library (and thus causing a problem).

It was common (and perhaps still is) for the GNU C++ library to be
delivered as a static library for Windows/MinGW because C++ exceptions
were not handled properly when thrown by DLLs.

Quite a lot of effort went into making this work the way it currently
does.

First libtool tries to take away all of the libraries which would be
added automatically and then it applies the libraries that GCC says it
would use at the correct time.


One of my wishlist roundtuit items is to special-case this behavior for
libtool + GNU toolchains.  For that combo, instead of the procedure Bob
outlines, and then using $LD to linkjust use the compiler driver
(e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1].  We're
already passing the ABI-modifying -m and -f flags anyway, and it would
really REALLY simplify libtool's logic...

[1] unless of course the end user put -nostdlib in $LDFLAGS or something.

--
Chuck





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!