Bug 6744 - --export-dynamic does nothing for Cygwin .exe's
Summary: --export-dynamic does nothing for Cygwin .exe's
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.20
: P2 normal
Target Milestone: ---
Assignee: Dave Korn
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-13 20:13 UTC by Yaakov Selkowitz
Modified: 2009-05-24 03:23 UTC (History)
2 users (show)

See Also:
Host: i686-pc-cygwin
Target: i686-pc-cygwin
Build: i686-pc-cygwin
Last reconfirmed:


Attachments
dlopen-self test case (280 bytes, text/plain)
2008-07-13 20:13 UTC, Yaakov Selkowitz
Details
Add warning and docs. (795 bytes, patch)
2009-04-01 18:16 UTC, Dave Korn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yaakov Selkowitz 2008-07-13 20:13:04 UTC
When linking a program with -Wl,--export-dynamic, no symbols are
exported.  The problem arises when the executable needs to either dlopen
itself, or when it has plugins which are "linked" against it.  Both
scenarios are not uncommon, particularly with GNOME software.

While this does work on Linux, it does not work on Cygwin with
--export-dynamic; only --export-all-symbols, an i386PE-specific flag,
will accomplish this.

I'm attaching a test case; it's a simplified version of the test used in
LT_SYS_DLOPEN_SELF (prev. AC_LIBTOOL_DLOPEN_SELF):

$ gcc -o test.exe dlopen-self.c && ./test.exe
status = 0

$ gcc -Wl,--export-dynamic -o test.exe dlopen-self.c && ./test.exe
status = 0

$ gcc -Wl,--export-all-symbols -o test.exe dlopen-self.c && ./test.exe
status = 1

Running 'objdump -p test.exe' will also show that the export table is
only generated in the last case.

I would appreciate your input on this issue.
Comment 1 Yaakov Selkowitz 2008-07-13 20:13:55 UTC
Created attachment 2826 [details]
dlopen-self test case
Comment 2 Dave Korn 2009-03-23 13:12:19 UTC
--export-dynamic is an ELF format option, and --export-all-symbols is the PE
equivalent.  We could reasonably make --export-dynamic a synonym for PE, I expect.
Comment 3 Yaakov Selkowitz 2009-03-24 02:02:14 UTC
(In reply to comment #2)
> --export-dynamic is an ELF format option, and --export-all-symbols is the PE
> equivalent.

Dave, thanks for looking at this.  The ld texinfo docs say nothing about
--export-dynamic being ELF-specific, so if this is indeed the case, that should
be made clear.

> We could reasonably make --export-dynamic a synonym for PE, I expect.

Sounds like a good idea.

Comment 4 Dave Korn 2009-03-24 04:07:49 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > --export-dynamic is an ELF format option, and --export-all-symbols is the PE
> > equivalent.
> 
> Dave, thanks for looking at this.  The ld texinfo docs say nothing about
> --export-dynamic being ELF-specific, so if this is indeed the case, that should
> be made clear.

  Well it's strongly implied by the wording "When creating a dynamically linked
executable ..." that it's not going to apply to platforms that don't support
dynamically linked executables.  This may also imply that the scope is slightly
wider than my assumption of "just Elf", which means the docs maybe are OK as
they are.

  I'm a little (only a little) concerned that if we make it a synonym on PE For
--export-all-symbols, it might confuse people into thinking that other linker
options related to dynamic objects would also function as expected, but they
seem to all be clearly documented as to which platforsm they support.  It would
certainly be technically correct if libtool chose to use --e-a-s rather than
--e-d when linking for a cygwin target, since it's the target-specific equivalent.

  Why not post an RFC on the binutils list asking if anyone can see a downside
of making --e-d a synonym for --e-a-s?
Comment 5 Yaakov Selkowitz 2009-03-24 06:45:12 UTC
> It would certainly be technically correct if libtool chose to use --e-a-s 
> rather than --e-d when linking for a cygwin target, since it's the target-
> specific equivalent.

Good point, changing libtool would cover most, but not all, of the cases.

>   Why not post an RFC on the binutils list asking if anyone can see a downside
> of making --e-d a synonym for --e-a-s?

I don't follow the binutils list nowadays.
Comment 6 Nick Clifton 2009-04-01 14:43:17 UTC
Hi Guys,

  I would prefer not to make -export-dynamic a synonym for -export-all-symbols
for the reason that Dave mentioned.  I would not object to adding code to
generate a warning message saying something like: "--export-dynamic is not
supported for COFF/PE targets, did you mean --export-all-symbols ?".

Cheers
  Nick
Comment 7 Yaakov Selkowitz 2009-04-01 16:18:14 UTC
Chuck has pushed the corresponding libtool patch upstream, so this should handle
many cases where it would be used.  I suppose a warning would be appropriate, as
would clarification in the documentation on this flag.
Comment 8 Dave Korn 2009-04-01 17:41:09 UTC
I'm m(In reply to comment #7)
>  I suppose a warning would be appropriate, as
> would clarification in the documentation on this flag.

I'm working on a patch to do this right now.

Comment 9 Dave Korn 2009-04-01 18:16:22 UTC
Created attachment 3860 [details]
Add warning and docs.

This patch adds warnings to both PE and PE+ emulations, (which are the only
COFF emulations that implement --export-all-symbols).  It also mentions --e-a-s
in the --export-dynamic documentation.

Tested on cygwin so far, will cross-test to x86_64-mingw later but have to go
AFK for a few hours.  "make info" worked on the docs, but make html,pdf and dvi
are all currently broken for me, for what appear to be unrelated reasons.
Comment 10 Yaakov Selkowitz 2009-04-02 03:45:10 UTC
(In reply to comment #9)
> It also mentions --e-a-s in the --export-dynamic documentation.

"PE targets support a similar function to export all symbols from a DLL;"

or EXE, which is actually what I'm more concerned about here.
Comment 11 Dave Korn 2009-04-02 05:10:55 UTC
Thanks for proofreading.  Revised patch (also contains testcase) about to be posted.
Comment 12 Sourceware Commits 2009-04-02 14:42:59 UTC
Subject: Bug 6744

CVSROOT:	/cvs/src
Module name:	src
Changes by:	davek@sourceware.org	2009-04-02 14:42:41

Modified files:
	ld             : ld.texinfo ChangeLog 
	ld/emultempl   : pe.em pep.em 
	ld/testsuite/ld-pe: pe.exp 
	ld/testsuite   : ChangeLog 
Added files:
	ld/testsuite/ld-pe: export_dynamic_warning.d 
	                    export_dynamic_warning.s 

Log message:
	ld/ChangeLog
	
	PR ld/6744
	* ld.texinfo (--export-dynamic):  Mention --export-all-symbols.
	* emultempl/pe.em (gld_${EMULATION_NAME}_after_parse):  Issue
	warning if --export-dynamic was passed on command-line.
	* emultempl/pep.em (gld_${EMULATION_NAME}_after_parse):  Likewise.
	
	ld/testsuite/ChangeLog
	
	PR ld/6744
	* ld-pe/export_dynamic_warning.d:  New test control file.
	* ld-pe/export_dynamic_warning.s:  New test source file.
	* ld-pe/pe.exp:  Also run export_dynamic_warning dump test.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/ld.texinfo.diff?cvsroot=src&r1=1.236&r2=1.237
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=src&r1=1.1956&r2=1.1957
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em.diff?cvsroot=src&r1=1.147&r2=1.148
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/pep.em.diff?cvsroot=src&r1=1.24&r2=1.25
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-pe/export_dynamic_warning.d.diff?cvsroot=src&r1=NONE&r2=1.1
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-pe/export_dynamic_warning.s.diff?cvsroot=src&r1=NONE&r2=1.1
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-pe/pe.exp.diff?cvsroot=src&r1=1.9&r2=1.10
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1066&r2=1.1067

Comment 13 Dave Korn 2009-05-24 03:23:44 UTC
Closing out old PR.