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.
