Bug 47390

-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.

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.)

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'

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.

okay, i'll let the upstreams of these packages know.

(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.

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.

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

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.