This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: allow PE executables to have an export table
- From: Christopher Faylor <cgf at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Sat, 21 Dec 2002 13:02:43 -0500
- Subject: Re: PATCH: allow PE executables to have an export table
- References: <3DFF4C1E000071BF@mail-2.tiscalinet.it>
- Reply-to: binutils at sources dot redhat dot com
I'm willing to check this in but there are a couple of problems.
1) No ChangeLog.
2) nonstandard formatting.
3) Don't know if it is large enough to require an assignment.
I can work around the first two but I need a ruling from Nick on 3.
cgf
On Sat, Dec 21, 2002 at 12:08:55PM +0100, fabrizio.ge@tiscali.it wrote:
>>-- Messaggio Originale --
>>From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
>>To: "Fabrizio Gennari" <fabrizio.ge@tiscalinet.it>,
>> <binutils@sources.redhat.com>
>>Subject: RE: PATCH: allow PE executables to have an export table
>>Date: Wed, 18 Dec 2002 02:01:51 +0100
>>
>>
>>> Current version of ld has a limitation: PE executables generated by ld
>never
>>> have an export table, although PE shared libraries (DLLs) have one. In
>fact,
>>> an export table in an executable file is perfectly legitimate
>>
>>Hi Fabrizio,
>>
>>allow me one question: for which cases should this be good ?
>>The advantage is that an application(1) could be linked to another
>>application(2) or dll(3), but makes this sense ?
>>I assume the windows runtime linker could not load the application (1),
>because
>>it does not contain the structure and the startup code, dll's usually have.
>>
>
>The idea is to have a Windows equivalent of --export-dynamic used with ELF
>files: if an application dlopen()s a DLL, the DLL is able to call the
>calling executable's exported functions. This way, a developer is able to
>write a portable application which uses --export-dynamic on Unix-like systems
>and an export table on Windows.
>
>Following Danny Smith's advice, I searched the mingw-users archive and found
>a very interesting post:
>
>>From: Tor Lillqvist <tml@ik...>
>> Exporting symbols from a .exe
>>2002-01-04 11:39
>> Andrew Begel writes:
>> > __declspec(dllexport) int main(int argc, char **argv) {
>>
>> > And I want to export main from the .exe. So I compile this using:
>>
>> (Export main? That sounds a bit odd to me. So you want to load a DLL
>> in the program, and then have the DLL call main recursively? But I
>> digress.)
>>
>> > gcc -o foobar.exe foobar.c
>>
>> > and the resulting executable doesn't export main (as reported dumpbin)!
>>
>> You have to first compile main.c with
>> gcc -c main.c
>> then run
>> dlltool --output-exp main.exp main.o
>> then link it
>> gcc -o main.exe main.o main.exp
>>
>> For some reason ld doesn't believe the __declspec(dllexport)
>> directives when building .exe files, but you have to create an .exp
>> file and link with that.
>
>So, it seems that current version of ld creates export tables (I didn't
>know!), but only if passed a .exp file: .def files and _declspec(dllexport)
>directives do not work. The patch just fills this gap.
>
>Regards
>Fabrizio
>
>
>
>__________________________________________________________________
>Tiscali ADSL. Scopri la fantastica promozione di Natale: tutto Gratis fino
>al 9 gennaio!
>Abbonati ora: prima ti abboni, pi? risparmi!
>http://point.tiscali.it/adsl/index.shtml
>
>