[Bug driver/47390] New: Linking with -export-dynamic broken

[Bug driver/47390] New: Linking with -export-dynamic broken

[dirtyepic at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

           Summary: Linking with -export-dynamic broken
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dirtyepic@gentoo.org


When building gawk, -export-dynamic is added to LDFLAGS.  It seems current
trunk treats options starting with "-e" differently that previous versions. 
With 4.6 I get:

x86_64-unknown-linux-gnu-gcc  -O2 -march=native -g -pipe  -export-dynamic -o
gawk array.o awkgram.o builtin.o dfa.o ext.o field.o floatcomp.o gawkmisc.o
getopt.o getopt1.o io.o main.o msg.o node.o random.o re.o regex.o replace.o
version.o eval.o profile.o    -ldl -lm -lm

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0-pre9999/../../../../x86_64-unknown-linux-gnu/bin/ld:
warning: cannot find entry symbol xport-dynamic; defaulting to 00000000004034c0

This leads to a broken gawk:

$ gawk -V
(null): fatal: spec_setup: cp: can't allocate 2109862218 bytes of memory
(Success)

It could be that this is intentional and something like -Wl,-export-dynamic
should be used, but this mail indicates differently:

  http://osdir.com/ml/bug-gnu-utils-gnu/2010-10/msg00002.html

If it is intentional, it should be documented in release notes so we have
something to point upstreams at.


$ gcc-4.6.0-pre9999 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6.0-pre9999
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0-pre9999/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.6.0_pre9999/work/gcc-4.6.0-9999/configure
--prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.6.0-pre9999
--includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0-pre9999/include
--datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.6.0-pre9999
--mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.6.0-pre9999/man
--infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.6.0-pre9999/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0-pre9999/include/g++-v4
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--disable-altivec --disable-fixed-point --with-ppl --with-cloog
--disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl
--enable-lto --disable-nls --with-system-zlib --disable-werror
--enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp
--enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/4.6.0-pre9999/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,go
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo SVN'
Thread model: posix
gcc version 4.6.0-pre9999 20110121 (experimental) rev. 169076 (Gentoo SVN)

$ ld -v
GNU ld (GNU Binutils) 2.21

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.21 11:07:28
                 CC|                            |jsm28 at gcc dot gnu.org
   Target Milestone|---                         |4.6.0
            Summary|Linking with                |[4.6 Regression] Linking
                   |-export-dynamic broken      |with -export-dynamic broken
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-21 11:07:28 UTC ---
-export-dynamic is a linker option, you have to use -Wl,-export-dynamic to
pass it to the linker via the gcc driver.

Joseph - 4.5 handled -export-dynamic by passing it through to the linker
(not exactly sure why).  Can we restore this behavior to avoid regressions?
If not, can we diagnose this invalid option then?  It seems to be passed
as -e xport-dynamic to the linker now, resulting in an undefined symbol
for me with a trivial hello-world.

Currently neither behavior seems to be documented btw.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-24 23:37:39 UTC ---
On Fri, 21 Jan 2011, rguenth at gcc dot gnu.org wrote:

> Joseph - 4.5 handled -export-dynamic by passing it through to the linker
> (not exactly sure why).  Can we restore this behavior to avoid regressions?
> If not, can we diagnose this invalid option then?  It seems to be passed
> as -e xport-dynamic to the linker now, resulting in an undefined symbol
> for me with a trivial hello-world.

-export-dynamic was passed down by an accident of %{e*} in 
LINK_COMMAND_SPEC.  If you want this to continue to work then add

export-dynamic
Driver

to common.opt, and probably put a comment on LINK_COMMAND_SPEC saying that 
%{e*} deliberately covers -export-dynamic.  (Alternatively, I think using 
%{export-dynamic} %{e}, together with the common.opt change, will make the 
passed options explicit, and successfully pass to the linker (in separate 
argument form) -e options passed to the driver in either joined or 
separate form - but verify this before making that change.)

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[dirtyepic at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #3 from Ryan Hill <dirtyepic at gentoo dot org> 2011-02-08 01:23:27 UTC ---
looks like some packages also use --export-dynamic, which just flat out fails
now. 

x86_64-unknown-linux-gnu-gcc: error: unrecognized option '--export-dynamic'

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-02-08 01:35:49 UTC ---
On Tue, 8 Feb 2011, dirtyepic at gentoo dot org wrote:

> looks like some packages also use --export-dynamic, which just flat out fails
> now. 
> 
> x86_64-unknown-linux-gnu-gcc: error: unrecognized option '--export-dynamic'

As discussed in PR 46410, the -- versions of linker options were in fact 
quietly ignored before on link-only command lines, or produced errors on 
command lines that would actually have resulted in compilation, so 
--export-dynamic would never have had the intended effect.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[dirtyepic at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #5 from Ryan Hill <dirtyepic at gentoo dot org> 2011-02-08 02:15:13 UTC ---
okay, i'll let the upstreams of these packages know.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-08 14:36:34 UTC ---
(In reply to comment #2)
> On Fri, 21 Jan 2011, rguenth at gcc dot gnu.org wrote:
> 
> > Joseph - 4.5 handled -export-dynamic by passing it through to the linker
> > (not exactly sure why).  Can we restore this behavior to avoid regressions?
> > If not, can we diagnose this invalid option then?  It seems to be passed
> > as -e xport-dynamic to the linker now, resulting in an undefined symbol
> > for me with a trivial hello-world.
> 
> -export-dynamic was passed down by an accident of %{e*} in 
> LINK_COMMAND_SPEC.  If you want this to continue to work then add
> 
> export-dynamic
> Driver
> 
> to common.opt, and probably put a comment on LINK_COMMAND_SPEC saying that 
> %{e*} deliberately covers -export-dynamic.  (Alternatively, I think using 
> %{export-dynamic} %{e}, together with the common.opt change, will make the 
> passed options explicit, and successfully pass to the linker (in separate 
> argument form) -e options passed to the driver in either joined or 
> separate form - but verify this before making that change.)

Hm, I see.  The -e LINK_COMMAND_SPEC isn't documented in invoke.texi
"Link Options", do we generally not do this?  It seems to be a spec that
is always enabled.

We document -rdynamic as the way to pass down -export-dynamic, so if
the -e handling is on-purpose ...

Can we force -e options to be passed down in their original joined/non-joined
form?  At least for GNU ld -e xport-dynamic is not equal to -export-dynamic,
that a %{e*} spec exchanges a working pass-down variant for an unworking
is unfortunate(?)  We can't seem to easily exclude export-dynamic from
e* as to reject it either.

The situation seems to be a bit weird.  Probably a note in the changes.html
Caveats section regarding the stricter option handling is due.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-02-08 16:54:19 UTC ---
On Tue, 8 Feb 2011, rguenth at gcc dot gnu.org wrote:

> Hm, I see.  The -e LINK_COMMAND_SPEC isn't documented in invoke.texi
> "Link Options", do we generally not do this?  It seems to be a spec that
> is always enabled.

What's documented is pretty random - there are lots of undocumented 
options in specs.

> Can we force -e options to be passed down in their original joined/non-joined
> form?  At least for GNU ld -e xport-dynamic is not equal to -export-dynamic,
> that a %{e*} spec exchanges a working pass-down variant for an unworking
> is unfortunate(?)  We can't seem to easily exclude export-dynamic from
> e* as to reject it either.

You can force joined form by adding code like the OPT_L handling
    case OPT_L:
      /* Similarly, canonicalize -L for linkers that may not accept
         separate arguments.  */
      save_switch (concat ("-L", arg, NULL), 0, NULL, validated);
      return true;

although the explicit export-dynamic entry in common.opt for backwards 
compatibility would seem better to me.

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

--- Comment #8 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-02-17 18:35:44 UTC ---
Author: jsm28
Date: Thu Feb 17 18:35:41 2011
New Revision: 170253

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170253
Log:
    PR driver/47390
    * common.opt (export-dynamic): New Driver option.
    * gcc.c (LINK_COMMAND_SPEC): Add comment about %{e*}.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/common.opt
    trunk/gcc/gcc.c

[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-02-17 18:38:18 UTC ---
Fixed for 4.6, though I advise using -rdynamic or -Wl,-export-dynamic instead
of this backwards-compatibility support for a previous accident of the
implementation.