Dlls @n symbols

Dlls @n symbols

[Suhaib M. Siddiqi]

I am trying to create GLIDE inputlib from glide2x.dll.

I am using dlltool -k --add-stdcall-alias -dllname glide2x.dll --ouput-lib
libglide2x.a

Though using -k and --add-stdcall-alias I still get the input library with
@n
symbols.  I am using it in Cygwin B 20.1.  The @n symbols are causing
undefined references
in the code.  I need the glide input libraries for the XFree X-server for
Cygwin.

I went through all  DLLs helpers documents from Mumit still could not figure
out why
@n symbols are not getting excluded or aliases.

Regards
Suhaib


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Dlls @n symbols

[Suhaib M. Siddiqi]

I am trying to create GLIDE inputlib from glide2x.dll.

I am using dlltool -k --add-stdcall-alias -dllname glide2x.dll --ouput-lib
libglide2x.a

Though using -k and --add-stdcall-alias I still get the input library with
@n
symbols.  I am using it in Cygwin B 20.1.  The @n symbols are causing
undefined references
in the code.  I need the glide input libraries for the XFree X-server for
Cygwin.

I went through all  DLLs helpers documents from Mumit still could not figure
out why
@n symbols are not getting excluded or aliases.

Regards
Suhaib


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

I solved most problems I had with generating clean (undecorated) exports 
tables for my DLLs thanks to the suggestions by Mumit.

For the special problem of forwarded symbols in the exports table, DJ 
suggested to compile the current binutils snapshot. I downloaded it but... 
ehm... could not compile (egcs 1.1.2/mingw32). But I browsed the code and 
now understand a bit more what the correct syntax should be for achiving 
that.

I'll make an example to let someone comment if I say something wrong, omit a 
necessary step or do something redundant.

Imagine I want to rewrite the NT's kernel32.dll. It is a good and easy 
example, because it forwards some symbols to ntdll.dll. That is (among the 
others):

HeapAlloc --> NTDLL.RtlAllocateHeap
HeapFree --> NTDLL.RtlFreeHeap
HeapReAlloc --> NTDLL.RtlReAllocateHeap
HeapSize --> NTDLL.RtlSizeHeap

Now I need writing two DEF files, one to build the import library 
(kernel32.def), and one to build the exports table (kernel32.edf).

Here is a possible kernel32.edf

LIBRARY KERNEL32
IMPORTS
RtlAllocateHeap=NTDLL.RtlAllocateHeap
RtlFreeHeap=NTDLL.RtlFreeHeap
RtlReAllocateHeap=NTDLL.RtlReAllocateHeap
RtlSizeHeap=NTDLL.RtlSizeHeap
...
EXPORTS
...
HeapAlloc=RtlAllocateHeap
HeapFree=RtlFreeHeap
HeapReAlloc=RtlReAllocateHeap
HeapSize=RtlSizeHeap
...

and here is the twin kernel32.def

LIBRARY KERNEL32
IMPORTS
RtlAllocateHeap=NTDLL.RtlAllocateHeap
RtlFreeHeap=NTDLL.RtlFreeHeap
RtlReAllocateHeap=NTDLL.RtlReAllocateHeap
RtlSizeHeap=NTDLL.RtlSizeHeap
...
EXPORTS
...
HeapAlloc@12=RtlAllocateHeap
HeapCompact@8
HeapCreate@12
HeapCreateTagsW@16
HeapDestroy@4
HeapExtend@16
HeapFree@12=RtlFreeHeap
HeapLock@4
HeapQueryTagW@20
HeapReAlloc@16=RtlReAllocateHeap
HeapSize@12=RtlSizeHeap
HeapSummary@12
HeapUnlock@4
HeapUsage@20
HeapValidate@12
HeapWalk@8
...

These files work fine even with the current bintools. This means the changes 
DJ reported are not in the parser. In fact, if I actually try to build a DLL 
with that DEF, I get

gcc \
        -specs=k32_specs \
        -mdll \
        -o junk.tmp \
        -Wl,--base-file,base.tmp \
        kernel32.o \
        ../ntdll/ntdll.a
kernel32.o(.text+0x4bf):env.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x4d3):env.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x6a0):env.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x6cc):env.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x4870):dir.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x490d):dir.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x4a01):dir.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x4a9d):dir.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x5c83):find.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x5e87):find.c: undefined reference to `HeapFree@12'
make[1]: *** [kernel32.dll] Error 1

(the kernel32.dll rewriting is actually a real project).

This is an expected result, since the HeapXXX function were removed from the 
kernel32 sources.

The question is: the unresolved reference errors appear because of stdcall 
decoration, or because the dlltool (ld) can not handle forwarded symbols 
(assuming my DEFs are correct)?

Thank you in advance for any answer (in the list).

-e-


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

I solved most problems I had with generating clean (undecorated) exports 
tables for my DLLs thanks to the suggestions by Mumit.

For the special problem of forwarded symbols in the exports table, DJ 
suggested to compile the current binutils snapshot. I downloaded it but... 
ehm... could not compile (egcs 1.1.2/mingw32). But I browsed the code and 
now understand a bit more what the correct syntax should be for achiving 
that.

I'll make an example to let someone comment if I say something wrong, omit a 
necessary step or do something redundant.

Imagine I want to rewrite the NT's kernel32.dll. It is a good and easy 
example, because it forwards some symbols to ntdll.dll. That is (among the 
others):

HeapAlloc --> NTDLL.RtlAllocateHeap
HeapFree --> NTDLL.RtlFreeHeap
HeapReAlloc --> NTDLL.RtlReAllocateHeap
HeapSize --> NTDLL.RtlSizeHeap

Now I need writing two DEF files, one to build the import library 
(kernel32.def), and one to build the exports table (kernel32.edf).

Here is a possible kernel32.edf

LIBRARY KERNEL32
IMPORTS
RtlAllocateHeap=NTDLL.RtlAllocateHeap
RtlFreeHeap=NTDLL.RtlFreeHeap
RtlReAllocateHeap=NTDLL.RtlReAllocateHeap
RtlSizeHeap=NTDLL.RtlSizeHeap
...
EXPORTS
...
HeapAlloc=RtlAllocateHeap
HeapFree=RtlFreeHeap
HeapReAlloc=RtlReAllocateHeap
HeapSize=RtlSizeHeap
...

and here is the twin kernel32.def

LIBRARY KERNEL32
IMPORTS
RtlAllocateHeap=NTDLL.RtlAllocateHeap
RtlFreeHeap=NTDLL.RtlFreeHeap
RtlReAllocateHeap=NTDLL.RtlReAllocateHeap
RtlSizeHeap=NTDLL.RtlSizeHeap
...
EXPORTS
...
HeapAlloc@12=RtlAllocateHeap
HeapCompact@8
HeapCreate@12
HeapCreateTagsW@16
HeapDestroy@4
HeapExtend@16
HeapFree@12=RtlFreeHeap
HeapLock@4
HeapQueryTagW@20
HeapReAlloc@16=RtlReAllocateHeap
HeapSize@12=RtlSizeHeap
HeapSummary@12
HeapUnlock@4
HeapUsage@20
HeapValidate@12
HeapWalk@8
...

These files work fine even with the current bintools. This means the changes 
DJ reported are not in the parser. In fact, if I actually try to build a DLL 
with that DEF, I get

gcc \
        -specs=k32_specs \
        -mdll \
        -o junk.tmp \
        -Wl,--base-file,base.tmp \
        kernel32.o \
        ../ntdll/ntdll.a
kernel32.o(.text+0x4bf):env.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x4d3):env.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x6a0):env.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x6cc):env.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x4870):dir.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x490d):dir.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x4a01):dir.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x4a9d):dir.c: undefined reference to `HeapFree@12'
kernel32.o(.text+0x5c83):find.c: undefined reference to `HeapAlloc@12'
kernel32.o(.text+0x5e87):find.c: undefined reference to `HeapFree@12'
make[1]: *** [kernel32.dll] Error 1

(the kernel32.dll rewriting is actually a real project).

This is an expected result, since the HeapXXX function were removed from the 
kernel32 sources.

The question is: the unresolved reference errors appear because of stdcall 
decoration, or because the dlltool (ld) can not handle forwarded symbols 
(assuming my DEFs are correct)?

Thank you in advance for any answer (in the list).

-e-


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

[binutils snapshot]
>See http://sourceware.cygnus.com/binutils/
>Builds cleanly under Cygwin.
Downloaded: quite large! I'll look at the code, before building.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[DJ Delorie]

> Who are the developers of dlltool?

It's probably me, but Cygnus in general, plus whoever wants to
contribute.

> there is also the names in the exports table as "symbolic link"
> problem that still waits for a solution.

Try building the latest binutils and see if ld's built-in dll support
handles this correctly.  I don't remember if I put it in or not.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

On Mon, 5 Jul 1999, Emanuele ALIBERTI wrote:

> >Try building the latest binutils and see if ld's built-in dll support
> >handles this correctly.  I don't remember if I put it in or not.
> 
> Where can I get the last binutils snapshot?
> 

See http://sourceware.cygnus.com/binutils/

Builds cleanly under Cygwin.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>From: Mumit Khan <khan@xraylith.wisc.EDU>
>To: Emanuele ALIBERTI <ealiberti@hotmail.com>
>CC: cygwin@sourceware.cygnus.com
>Subject: Re: Dlls @n symbols
>Date: Sun, 27 Jun 1999 14:23:58 -0500

(sorry for the late reply: I was off line because of work)

>The reason to have "clean" names in the export list is simple -- so you
>can use LoadLibrary. If you only need to use LoadLibrary, then you can
>use the clean names. So have both in the export list! What's the big deal?

Since I am rewriting an existing library, it is a big deal. Not in general.

>One way to achieve both is the following (and that's how MSVC developers
>do this in case you're interested): Have two different export def files,
>one for creating the DLL, and the other for creating the import library.
>When creating the DLL, use the aliasing mechanism to get only clean names;
>when creating the import library, using Foo@<n> etc and use -k to have
>@<n> linkable symbols that point to export symbol without the @<n>, ie.,
>the "clean" names.

I was going that way, but that seemed the last chance, because I would have 
to maintain two files. Probably I will write a simple preprocessor that 
generates the DEF with aliases from the traditional DEF. Thank you for the 
explanation of the real use of the -k option.

>Let me ask the same question I had the last time -- can you do what you
>want with MSVC? If so, how?

I don't know if it is possible: I use it only from the IDE, but the dll I 
build that way have a clean exports table.

>If you feel like it's not doing the right thing, please feel free to
>start digging into binutils sources and see if you can help improve
>it.

Who are the developers of dlltool? I don't know if I can contribute, but 
there is also the names in the exports table as "symbolic link" problem that 
still waits for a solution.

-e-


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>Try building the latest binutils and see if ld's built-in dll support
>handles this correctly.  I don't remember if I put it in or not.

Where can I get the last binutils snapshot?


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

[binutils snapshot]
>See http://sourceware.cygnus.com/binutils/
>Builds cleanly under Cygwin.
Downloaded: quite large! I'll look at the code, before building.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

On Mon, 5 Jul 1999, Emanuele ALIBERTI wrote:

> >Try building the latest binutils and see if ld's built-in dll support
> >handles this correctly.  I don't remember if I put it in or not.
> 
> Where can I get the last binutils snapshot?
> 

See http://sourceware.cygnus.com/binutils/

Builds cleanly under Cygwin.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>Try building the latest binutils and see if ld's built-in dll support
>handles this correctly.  I don't remember if I put it in or not.

Where can I get the last binutils snapshot?


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[DJ Delorie]

> Who are the developers of dlltool?

It's probably me, but Cygnus in general, plus whoever wants to
contribute.

> there is also the names in the exports table as "symbolic link"
> problem that still waits for a solution.

Try building the latest binutils and see if ld's built-in dll support
handles this correctly.  I don't remember if I put it in or not.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>From: Mumit Khan <khan@xraylith.wisc.EDU>
>To: Emanuele ALIBERTI <ealiberti@hotmail.com>
>CC: cygwin@sourceware.cygnus.com
>Subject: Re: Dlls @n symbols
>Date: Sun, 27 Jun 1999 14:23:58 -0500

(sorry for the late reply: I was off line because of work)

>The reason to have "clean" names in the export list is simple -- so you
>can use LoadLibrary. If you only need to use LoadLibrary, then you can
>use the clean names. So have both in the export list! What's the big deal?

Since I am rewriting an existing library, it is a big deal. Not in general.

>One way to achieve both is the following (and that's how MSVC developers
>do this in case you're interested): Have two different export def files,
>one for creating the DLL, and the other for creating the import library.
>When creating the DLL, use the aliasing mechanism to get only clean names;
>when creating the import library, using Foo@<n> etc and use -k to have
>@<n> linkable symbols that point to export symbol without the @<n>, ie.,
>the "clean" names.

I was going that way, but that seemed the last chance, because I would have 
to maintain two files. Probably I will write a simple preprocessor that 
generates the DEF with aliases from the traditional DEF. Thank you for the 
explanation of the real use of the -k option.

>Let me ask the same question I had the last time -- can you do what you
>want with MSVC? If so, how?

I don't know if it is possible: I use it only from the IDE, but the dll I 
build that way have a clean exports table.

>If you feel like it's not doing the right thing, please feel free to
>start digging into binutils sources and see if you can help improve
>it.

Who are the developers of dlltool? I don't know if I can contribute, but 
there is also the names in the exports table as "symbolic link" problem that 
still waits for a solution.

-e-


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> 
> >It turns out that Suhaib's problem is very different than yours.
> 
> It may be I misunderstood it.

Sorry, I should've been clearer. Suhaib and I had been communicating 
privately, and the problem has to do with incorrect prototyping of
__stdcall__ functions, nothing to do with DLLs.

> >What you're telling the dll tools is that you want to link with Bar@0, but
> >have the DLL export Bar; similarly with Foo. One way to get both in the
> >export list is the following:
> >
> >  LIBRARY sample
> >  EXPORTS
> >  Bar@0
> >  Bar=Bar@0
> >  Foo@24
> >  Foo=Foo@24
> >
> >Now sample.dll exports both Foo and Foo@24.
> 
> The goal for me is:
> 1. NOT having mangled names in the exports table
> 2. having an import library which lets ld lookup mangled names
> 3. having finally an application that imports UNmangled names
> 
> I succeeded only with step 1.

I don't understand (2) and (3). Could you please elaborate, with examples,
and then we can discuss if they're feasible or not. If these steps are 
not possible with MSVC or Borland, chances are it won't be easily doable 
or practical in GNU tools either.

One thing that MSVC does, and it's very handy, is the following:
  
  EXPORTS
    foo

where foo can be __cdecl__ (ie., just _foo) or __stdcall__ (ie., _foo@<n>)
and it'll do the right thing. This is quite impractical to do with dlltool,
but perhaps in the new ld that will support --shared directly.

> Thank you for answering and the URL.

Here's the correct URL.

  http://www.xraylith.wisc.edu/~khan/gnu-win32/dllhelpers.html

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> I had to face the same problem. But could not solve it completely yet. There 
> is also a mistake in the dlltool documentation, where it is told the figure 
> after @ is the function's ordinal number: it is actually the stack size the 
> exported function will add to the ESP on return (that's STDCALL).
> To make a clean exports table, now I use explicit aliasing in the .DEF file:

I'll take a look at the doc. I believe the docs refer the number "1" below
as the ordinal, not the @<n> number in foo@0.
  
  EXPORTS
    foo = foo@0 @ 1	; 1 is the ordinal number.

> ----------
> LIBRARY sample
> EXPORTS
> Bar=Bar@0
> Foo=Foo@24

It turns out that Suhaib's problem is very different than yours.

What you're telling the dll tools is that you want to link with Bar@0, but 
have the DLL export Bar; similarly with Foo. One way to get both in the
export list is the following:

 LIBRARY sample
 EXPORTS
 Bar@0
 Bar=Bar@0
 Foo@24
 Foo=Foo@24

> ----------
> but still fail to generate an import library which makes the application 
> dynamically link correctly. In the context of the previous example .DEF, I 
> get errors like "Loader could not find Foo@24 in sample.dll" (in fact 
> sample.dll exports now "Foo", not "Foo@24").

Now sample.dll exports both Foo and Foo@24.

dllwrap and dlltool both provide --add-stdcall-alias option just for this
so you don't have to do this manually. See my dllhelpers examples for more
info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Jim Roy]

from Mumit ??

> >dllwrap and dlltool both provide --add-stdcall-alias option just for this
> >so you don't have to do this manually. See my dllhelpers examples for more
> >info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

I couldn't get this url to work.  Is this the same file that is found at:

www.xraylith.wisc.edu/~kahn/software/gnu-win32/dllhelpers.html

Jim Roy

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

jim@nga.com (Jim Roy) writes:
> from Mumit ??
> 
> > >dllwrap and dlltool both provide --add-stdcall-alias option just for this
> > >so you don't have to do this manually. See my dllhelpers examples for more
> > >info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .
> 
> I couldn't get this url to work.  Is this the same file that is found at:
> 
> www.xraylith.wisc.edu/~kahn/software/gnu-win32/dllhelpers.html
> 

My apologies. Late night drowsiness ...

  http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>I am using dlltool -k --add-stdcall-alias -dllname glide2x.dll
>--ouput-lib libglide2x.a
>
>Though using -k and --add-stdcall-alias I still get the input
>library with @n symbols.  I am using it in Cygwin B 20.1.
>The @n symbols are causing undefined references in the code.
>I need the glide input libraries for the XFree X-server for
>Cygwin.
>
>I went through all  DLLs helpers documents from Mumit still
>could not figure out why @n symbols are not getting excluded
>or aliases.
>
I had to face the same problem. But could not solve it completely yet. There 
is also a mistake in the dlltool documentation, where it is told the figure 
after @ is the function's ordinal number: it is actually the stack size the 
exported function will add to the ESP on return (that's STDCALL).
To make a clean exports table, now I use explicit aliasing in the .DEF file:
----------
LIBRARY sample
EXPORTS
Bar=Bar@0
Foo=Foo@24
...
----------
but still fail to generate an import library which makes the application 
dynamically link correctly. In the context of the previous example .DEF, I 
get errors like "Loader could not find Foo@24 in sample.dll" (in fact 
sample.dll exports now "Foo", not "Foo@24").


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>I'll take a look at the doc. I believe the docs refer the number "1" below
>as the ordinal, not the @<n> number in foo@0.
>
>   EXPORTS
>     foo = foo@0 @ 1	; 1 is the ordinal number.

In the doc it is actually written `@ <number>', near --kill-at, with a space 
between @ and number. If not wrong, it is quite ambiguous: I didn't know 
spaces are allowed in symbols.

>It turns out that Suhaib's problem is very different than yours.

It may be I misunderstood it.

>What you're telling the dll tools is that you want to link with Bar@0, but
>have the DLL export Bar; similarly with Foo. One way to get both in the
>export list is the following:
>
>  LIBRARY sample
>  EXPORTS
>  Bar@0
>  Bar=Bar@0
>  Foo@24
>  Foo=Foo@24
>
>Now sample.dll exports both Foo and Foo@24.

The goal for me is:
1. NOT having mangled names in the exports table
2. having an import library which lets ld lookup mangled names
3. having finally an application that imports UNmangled names

I succeeded only with step 1.

>dllwrap and dlltool both provide --add-stdcall-alias option just for this
>so you don't have to do this manually. See my dllhelpers examples for more
>info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

Thank you for answering and the URL.

Best regards,
Emanuele


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

> > The goal for me is:
> > 1. NOT having mangled names in the exports table
> > 2. having an import library which lets ld lookup mangled names
> > 3. having finally an application that imports UNmangled names
> >
> > I succeeded only with step 1.
>
>I don't understand (2) and (3). Could you please elaborate, with examples,
>and then we can discuss if they're feasible or not. If these steps are
>not possible with MSVC or Borland, chances are it won't be easily doable
>or practical in GNU tools either.

Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
mangled names in the DEF file, they get defined, but appear also in the 
DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
ld creates the application, but its imports table contains mangled names, 
not clean names, so having a clean exports table in the DLL is useless!

--- calltest.c ---
#include <windows.h>
#include <stdio.h>

VOID
STDCALL
Foo(VOID);

LONG
STDCALL
Bar( int arg0, int arg1, int arg2, int arg3, int arg4, int arg5 );

main()
{
	Foo();
	printf("Bar = %d\n",Bar(1,2,3,4,5,6));
	return 0;
}
/* EOF */
--- dllmain.c ---
#include <windows.h>
INT
__stdcall
DllMain(
	PVOID	hinstDll,
	ULONG	dwReason,
	PVOID	reserved
	)
{
	switch (dwReason)
	{
		case DLL_PROCESS_ATTACH:
			break;
		case DLL_THREAD_ATTACH:
			break;
		case DLL_THREAD_DETACH:
			break;
		case DLL_PROCESS_DETACH:
			break;
	}
	return(1);
}
/* EOF */
--- dlltest.c ---
#include <windows.h>
#include <stdio.h>

VOID
STDCALL
Foo(VOID)
{
	printf("Hi, I am Foo()!\n");
}

LONG
STDCALL
Bar( int arg0, int arg1, int arg2, int arg3, int arg4, int arg5 )
{
	return
		(LONG) arg0
		+ (LONG) arg1
		+ (LONG) arg2
		+ (LONG) arg3
		+ (LONG) arg4
		+ (LONG) arg5;
}

/* EOF */
--- makefile ---
# mingw32
CC=gcc.exe -Wall -Wstrict-prototypes -O2
LD=ld.exe
NM=nm.exe
RM=erase
DLLTOOL=dlltool.exe
TARGET=test
DLLTARGET=$(TARGET).dll
DLLMAIN=dllmain.o
DLL_OBJECTS= $(DDLMAIN) dll$(TARGET).o

all: $(DLLTARGET) call$(TARGET).exe

clean:
	$(RM) *.o *.a *.sym *.tmp *.dll *.exe

$(TARGET).a: $(DLL_OBJECTS)
	$(AR) csr $(TARGET).a $(DLL_OBJECTS)

$(TARGET).dll: $(DLLMAIN) $(DLL_OBJECTS) $(TARGET).def
	$(LD) -r $(DLL_OBJECTS) -o $(TARGET).o
	$(DLLTOOL) \
		--dllname $(TARGET).dll \
		--def $(TARGET).def \
		--output-lib $(TARGET).a \
		--add-stdcall-alias \
		--kill-at
	$(CC) \
		-specs=$(TARGET)_specs \
		-mdll \
		-o junk.tmp \
		-Wl,--base-file,base.tmp \
		$(TARGET).o \
		-Wl,-lcrtdll
	- $(RM) junk.tmp
	$(DLLTOOL) \
		--dllname $(TARGET).dll \
		--base-file base.tmp \
		--output-exp temp.exp \
		--def $(TARGET).def \
		--add-stdcall-alias \
		--kill-at
	- $(RM) base.tmp
	$(CC) \
		-specs=$(TARGET)_specs \
		-mdll \
		-o $(TARGET).dll \
		$(TARGET).o \
		-Wl,--image-base,0x70000000 \
		-Wl,--file-alignment,0x1000 \
		-Wl,--section-alignment,0x1000 \
		-Wl,temp.exp \
		-Wl,-lcrtdll
	- $(RM) temp.exp
	$(NM) --numeric-sort $(TARGET).dll > $(TARGET).sym

call$(TARGET).exe: call$(TARGET).o dllmain.o
	$(CC) call$(TARGET).o dllmain.o \
		-o call$(TARGET).exe \
		-Wl,$(TARGET).a \
		-Wl,-lcrtdll
	$(NM) --numeric-sort call$(TARGET).exe > call$(TARGET).sym

# EOF
--- test.def ---
LIBRARY test
EXPORTS
;	Bar@24
	Bar			= Bar@24
;	Foo@0
	Foo			= Foo@0
;EOF
--- test_specs ---
*asm:


*asm_final:


*cpp:
-remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE}

*cc1:
%(cc1_spec)

*cc1plus:


*endfile:


*link:
%{mwindows:--subsystem windows} %{mdll:--dll -e _DllMainCRTStartup@12}

*lib:


*libgcc:
-lgcc

*startfile:


*switches_need_spaces:


*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
-Di386 -D_WIN32 -DWIN32 -D__WIN32__   -D__MINGW32__ -DWINNT  -D_X86_=1 
-D__STDC__=1  -D__stdcall=__attribute__((__stdcall__))   
_D_stdcall=__attribute__((__stdcall__))   
-D__cdecl=__attribute__((__cdecl__))   -D__declspec(x)=__attribute__((x))   
-Asystem(winnt) -Acpu(i386) -Amachine(i386)

*cross_compile:
1

*version:
egcs-2.91.57

*multilib:
. ;

*multilib_defaults:


*multilib_extra:


*multilib_matches:


*linker:
collect2

*cpp_486:
%{!ansi:-Di486} -D__i486 -D__i486__

*cpp_586:
%{!ansi:-Di586 -Dpentium} 	-D__i586 -D__i586__ -D__pentium -D__pentium__

*cpp_686:
%{!ansi:-Di686 -Dpentiumpro} 	-D__i686 -D__i686__ -D__pentiumpro 
-D__pentiumpro__

*cpp_cpu_default:
%(cpp_586)

*cpp_cpu:
-Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__ 
%{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)} 
%{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)} 
%{mcpu=pentiumpro:%(cpp_686)} 
%{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}

*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{mno-486:-mcpu=i386 -march=i386} 
%{m486:-mcpu=i486 -march=i486} %{mno-386:-mcpu=i486 -march=i486} 
%{mno-pentium:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} 
%{mno-pentiumpro:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}
--- EOF ---


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> > > The goal for me is:
> > > 1. NOT having mangled names in the exports table
> > > 2. having an import library which lets ld lookup mangled names
> > > 3. having finally an application that imports UNmangled names
> > >
> > > I succeeded only with step 1.
> >
> >I don't understand (2) and (3). Could you please elaborate, with examples,
> >and then we can discuss if they're feasible or not. If these steps are
> >not possible with MSVC or Borland, chances are it won't be easily doable
> >or practical in GNU tools either.
> 
> Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
> is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
> mangled names in the DEF file, they get defined, but appear also in the 
> DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
> ld creates the application, but its imports table contains mangled names, 
> not clean names, so having a clean exports table in the DLL is useless!

Again, I'm unsure as to what you're trying to achieve here. If you tell 
the import library NOT to have mangled names, your client code won't link.
That's how things work (and so does MSVC, which is the native reference
implementation on windows32).

The reason to have "clean" names in the export list is simple -- so you
can use LoadLibrary. If you only need to use LoadLibrary, then you can
use the clean names. So have both in the export list! What's the big deal?

One way to achieve both is the following (and that's how MSVC developers
do this in case you're interested): Have two different export def files,
one for creating the DLL, and the other for creating the import library.
When creating the DLL, use the aliasing mechanism to get only clean names;
when creating the import library, using Foo@<n> etc and use -k to have
@<n> linkable symbols that point to export symbol without the @<n>, ie.,
the "clean" names.

Let me ask the same question I had the last time -- can you do what you
want with MSVC? If so, how?

If you feel like it's not doing the right thing, please feel free to 
start digging into binutils sources and see if you can help improve
it.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> > > The goal for me is:
> > > 1. NOT having mangled names in the exports table
> > > 2. having an import library which lets ld lookup mangled names
> > > 3. having finally an application that imports UNmangled names
> > >
> > > I succeeded only with step 1.
> >
> >I don't understand (2) and (3). Could you please elaborate, with examples,
> >and then we can discuss if they're feasible or not. If these steps are
> >not possible with MSVC or Borland, chances are it won't be easily doable
> >or practical in GNU tools either.
> 
> Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
> is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
> mangled names in the DEF file, they get defined, but appear also in the 
> DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
> ld creates the application, but its imports table contains mangled names, 
> not clean names, so having a clean exports table in the DLL is useless!

Again, I'm unsure as to what you're trying to achieve here. If you tell 
the import library NOT to have mangled names, your client code won't link.
That's how things work (and so does MSVC, which is the native reference
implementation on windows32).

The reason to have "clean" names in the export list is simple -- so you
can use LoadLibrary. If you only need to use LoadLibrary, then you can
use the clean names. So have both in the export list! What's the big deal?

One way to achieve both is the following (and that's how MSVC developers
do this in case you're interested): Have two different export def files,
one for creating the DLL, and the other for creating the import library.
When creating the DLL, use the aliasing mechanism to get only clean names;
when creating the import library, using Foo@<n> etc and use -k to have
@<n> linkable symbols that point to export symbol without the @<n>, ie.,
the "clean" names.

Let me ask the same question I had the last time -- can you do what you
want with MSVC? If so, how?

If you feel like it's not doing the right thing, please feel free to 
start digging into binutils sources and see if you can help improve
it.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

> > The goal for me is:
> > 1. NOT having mangled names in the exports table
> > 2. having an import library which lets ld lookup mangled names
> > 3. having finally an application that imports UNmangled names
> >
> > I succeeded only with step 1.
>
>I don't understand (2) and (3). Could you please elaborate, with examples,
>and then we can discuss if they're feasible or not. If these steps are
>not possible with MSVC or Borland, chances are it won't be easily doable
>or practical in GNU tools either.

Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
mangled names in the DEF file, they get defined, but appear also in the 
DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
ld creates the application, but its imports table contains mangled names, 
not clean names, so having a clean exports table in the DLL is useless!

--- calltest.c ---
#include <windows.h>
#include <stdio.h>

VOID
STDCALL
Foo(VOID);

LONG
STDCALL
Bar( int arg0, int arg1, int arg2, int arg3, int arg4, int arg5 );

main()
{
	Foo();
	printf("Bar = %d\n",Bar(1,2,3,4,5,6));
	return 0;
}
/* EOF */
--- dllmain.c ---
#include <windows.h>
INT
__stdcall
DllMain(
	PVOID	hinstDll,
	ULONG	dwReason,
	PVOID	reserved
	)
{
	switch (dwReason)
	{
		case DLL_PROCESS_ATTACH:
			break;
		case DLL_THREAD_ATTACH:
			break;
		case DLL_THREAD_DETACH:
			break;
		case DLL_PROCESS_DETACH:
			break;
	}
	return(1);
}
/* EOF */
--- dlltest.c ---
#include <windows.h>
#include <stdio.h>

VOID
STDCALL
Foo(VOID)
{
	printf("Hi, I am Foo()!\n");
}

LONG
STDCALL
Bar( int arg0, int arg1, int arg2, int arg3, int arg4, int arg5 )
{
	return
		(LONG) arg0
		+ (LONG) arg1
		+ (LONG) arg2
		+ (LONG) arg3
		+ (LONG) arg4
		+ (LONG) arg5;
}

/* EOF */
--- makefile ---
# mingw32
CC=gcc.exe -Wall -Wstrict-prototypes -O2
LD=ld.exe
NM=nm.exe
RM=erase
DLLTOOL=dlltool.exe
TARGET=test
DLLTARGET=$(TARGET).dll
DLLMAIN=dllmain.o
DLL_OBJECTS= $(DDLMAIN) dll$(TARGET).o

all: $(DLLTARGET) call$(TARGET).exe

clean:
	$(RM) *.o *.a *.sym *.tmp *.dll *.exe

$(TARGET).a: $(DLL_OBJECTS)
	$(AR) csr $(TARGET).a $(DLL_OBJECTS)

$(TARGET).dll: $(DLLMAIN) $(DLL_OBJECTS) $(TARGET).def
	$(LD) -r $(DLL_OBJECTS) -o $(TARGET).o
	$(DLLTOOL) \
		--dllname $(TARGET).dll \
		--def $(TARGET).def \
		--output-lib $(TARGET).a \
		--add-stdcall-alias \
		--kill-at
	$(CC) \
		-specs=$(TARGET)_specs \
		-mdll \
		-o junk.tmp \
		-Wl,--base-file,base.tmp \
		$(TARGET).o \
		-Wl,-lcrtdll
	- $(RM) junk.tmp
	$(DLLTOOL) \
		--dllname $(TARGET).dll \
		--base-file base.tmp \
		--output-exp temp.exp \
		--def $(TARGET).def \
		--add-stdcall-alias \
		--kill-at
	- $(RM) base.tmp
	$(CC) \
		-specs=$(TARGET)_specs \
		-mdll \
		-o $(TARGET).dll \
		$(TARGET).o \
		-Wl,--image-base,0x70000000 \
		-Wl,--file-alignment,0x1000 \
		-Wl,--section-alignment,0x1000 \
		-Wl,temp.exp \
		-Wl,-lcrtdll
	- $(RM) temp.exp
	$(NM) --numeric-sort $(TARGET).dll > $(TARGET).sym

call$(TARGET).exe: call$(TARGET).o dllmain.o
	$(CC) call$(TARGET).o dllmain.o \
		-o call$(TARGET).exe \
		-Wl,$(TARGET).a \
		-Wl,-lcrtdll
	$(NM) --numeric-sort call$(TARGET).exe > call$(TARGET).sym

# EOF
--- test.def ---
LIBRARY test
EXPORTS
;	Bar@24
	Bar			= Bar@24
;	Foo@0
	Foo			= Foo@0
;EOF
--- test_specs ---
*asm:


*asm_final:


*cpp:
-remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE}

*cc1:
%(cc1_spec)

*cc1plus:


*endfile:


*link:
%{mwindows:--subsystem windows} %{mdll:--dll -e _DllMainCRTStartup@12}

*lib:


*libgcc:
-lgcc

*startfile:


*switches_need_spaces:


*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
-Di386 -D_WIN32 -DWIN32 -D__WIN32__   -D__MINGW32__ -DWINNT  -D_X86_=1 
-D__STDC__=1  -D__stdcall=__attribute__((__stdcall__))   
_D_stdcall=__attribute__((__stdcall__))   
-D__cdecl=__attribute__((__cdecl__))   -D__declspec(x)=__attribute__((x))   
-Asystem(winnt) -Acpu(i386) -Amachine(i386)

*cross_compile:
1

*version:
egcs-2.91.57

*multilib:
. ;

*multilib_defaults:


*multilib_extra:


*multilib_matches:


*linker:
collect2

*cpp_486:
%{!ansi:-Di486} -D__i486 -D__i486__

*cpp_586:
%{!ansi:-Di586 -Dpentium} 	-D__i586 -D__i586__ -D__pentium -D__pentium__

*cpp_686:
%{!ansi:-Di686 -Dpentiumpro} 	-D__i686 -D__i686__ -D__pentiumpro 
-D__pentiumpro__

*cpp_cpu_default:
%(cpp_586)

*cpp_cpu:
-Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__ 
%{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)} 
%{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)} 
%{mcpu=pentiumpro:%(cpp_686)} 
%{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}

*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{mno-486:-mcpu=i386 -march=i386} 
%{m486:-mcpu=i486 -march=i486} %{mno-386:-mcpu=i486 -march=i486} 
%{mno-pentium:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} 
%{mno-pentiumpro:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}
--- EOF ---


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> 
> >It turns out that Suhaib's problem is very different than yours.
> 
> It may be I misunderstood it.

Sorry, I should've been clearer. Suhaib and I had been communicating 
privately, and the problem has to do with incorrect prototyping of
__stdcall__ functions, nothing to do with DLLs.

> >What you're telling the dll tools is that you want to link with Bar@0, but
> >have the DLL export Bar; similarly with Foo. One way to get both in the
> >export list is the following:
> >
> >  LIBRARY sample
> >  EXPORTS
> >  Bar@0
> >  Bar=Bar@0
> >  Foo@24
> >  Foo=Foo@24
> >
> >Now sample.dll exports both Foo and Foo@24.
> 
> The goal for me is:
> 1. NOT having mangled names in the exports table
> 2. having an import library which lets ld lookup mangled names
> 3. having finally an application that imports UNmangled names
> 
> I succeeded only with step 1.

I don't understand (2) and (3). Could you please elaborate, with examples,
and then we can discuss if they're feasible or not. If these steps are 
not possible with MSVC or Borland, chances are it won't be easily doable 
or practical in GNU tools either.

One thing that MSVC does, and it's very handy, is the following:
  
  EXPORTS
    foo

where foo can be __cdecl__ (ie., just _foo) or __stdcall__ (ie., _foo@<n>)
and it'll do the right thing. This is quite impractical to do with dlltool,
but perhaps in the new ld that will support --shared directly.

> Thank you for answering and the URL.

Here's the correct URL.

  http://www.xraylith.wisc.edu/~khan/gnu-win32/dllhelpers.html

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

jim@nga.com (Jim Roy) writes:
> from Mumit ??
> 
> > >dllwrap and dlltool both provide --add-stdcall-alias option just for this
> > >so you don't have to do this manually. See my dllhelpers examples for more
> > >info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .
> 
> I couldn't get this url to work.  Is this the same file that is found at:
> 
> www.xraylith.wisc.edu/~kahn/software/gnu-win32/dllhelpers.html
> 

My apologies. Late night drowsiness ...

  http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Jim Roy]

from Mumit ??

> >dllwrap and dlltool both provide --add-stdcall-alias option just for this
> >so you don't have to do this manually. See my dllhelpers examples for more
> >info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

I couldn't get this url to work.  Is this the same file that is found at:

www.xraylith.wisc.edu/~kahn/software/gnu-win32/dllhelpers.html

Jim Roy

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>I'll take a look at the doc. I believe the docs refer the number "1" below
>as the ordinal, not the @<n> number in foo@0.
>
>   EXPORTS
>     foo = foo@0 @ 1	; 1 is the ordinal number.

In the doc it is actually written `@ <number>', near --kill-at, with a space 
between @ and number. If not wrong, it is quite ambiguous: I didn't know 
spaces are allowed in symbols.

>It turns out that Suhaib's problem is very different than yours.

It may be I misunderstood it.

>What you're telling the dll tools is that you want to link with Bar@0, but
>have the DLL export Bar; similarly with Foo. One way to get both in the
>export list is the following:
>
>  LIBRARY sample
>  EXPORTS
>  Bar@0
>  Bar=Bar@0
>  Foo@24
>  Foo=Foo@24
>
>Now sample.dll exports both Foo and Foo@24.

The goal for me is:
1. NOT having mangled names in the exports table
2. having an import library which lets ld lookup mangled names
3. having finally an application that imports UNmangled names

I succeeded only with step 1.

>dllwrap and dlltool both provide --add-stdcall-alias option just for this
>so you don't have to do this manually. See my dllhelpers examples for more
>info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

Thank you for answering and the URL.

Best regards,
Emanuele


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Mumit Khan]

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> I had to face the same problem. But could not solve it completely yet. There 
> is also a mistake in the dlltool documentation, where it is told the figure 
> after @ is the function's ordinal number: it is actually the stack size the 
> exported function will add to the ESP on return (that's STDCALL).
> To make a clean exports table, now I use explicit aliasing in the .DEF file:

I'll take a look at the doc. I believe the docs refer the number "1" below
as the ordinal, not the @<n> number in foo@0.
  
  EXPORTS
    foo = foo@0 @ 1	; 1 is the ordinal number.

> ----------
> LIBRARY sample
> EXPORTS
> Bar=Bar@0
> Foo=Foo@24

It turns out that Suhaib's problem is very different than yours.

What you're telling the dll tools is that you want to link with Bar@0, but 
have the DLL export Bar; similarly with Foo. One way to get both in the
export list is the following:

 LIBRARY sample
 EXPORTS
 Bar@0
 Bar=Bar@0
 Foo@24
 Foo=Foo@24

> ----------
> but still fail to generate an import library which makes the application 
> dynamically link correctly. In the context of the previous example .DEF, I 
> get errors like "Loader could not find Foo@24 in sample.dll" (in fact 
> sample.dll exports now "Foo", not "Foo@24").

Now sample.dll exports both Foo and Foo@24.

dllwrap and dlltool both provide --add-stdcall-alias option just for this
so you don't have to do this manually. See my dllhelpers examples for more
info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html .

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Dlls @n symbols

[Emanuele ALIBERTI]

>I am using dlltool -k --add-stdcall-alias -dllname glide2x.dll
>--ouput-lib libglide2x.a
>
>Though using -k and --add-stdcall-alias I still get the input
>library with @n symbols.  I am using it in Cygwin B 20.1.
>The @n symbols are causing undefined references in the code.
>I need the glide input libraries for the XFree X-server for
>Cygwin.
>
>I went through all  DLLs helpers documents from Mumit still
>could not figure out why @n symbols are not getting excluded
>or aliases.
>
I had to face the same problem. But could not solve it completely yet. There 
is also a mistake in the dlltool documentation, where it is told the figure 
after @ is the function's ordinal number: it is actually the stack size the 
exported function will add to the ESP on return (that's STDCALL).
To make a clean exports table, now I use explicit aliasing in the .DEF file:
----------
LIBRARY sample
EXPORTS
Bar=Bar@0
Foo=Foo@24
...
----------
but still fail to generate an import library which makes the application 
dynamically link correctly. In the context of the previous example .DEF, I 
get errors like "Loader could not find Foo@24 in sample.dll" (in fact 
sample.dll exports now "Foo", not "Foo@24").


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com