This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: allow PE executables to have an export table


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]