ld, dlls, and windows libraries

ld, dlls, and windows libraries

[John Fortin]

Hi,
    I have a quick question...

    Is there the equiv. of -mwindows for ld.  The trouble occurs when I
build a DLL which uses win32 api, I get a bunch of errors for unknown
symbols.  If I manually add ( by trial and error at this point )
-lkernel32 -lm and other libraries, I am able to finish the build of the
DLL.

    Is there a shortcut, or is there a list which indicates which
functions are in which libs.  I suppose I could use nm, but that seems
inefficient.

Thanks,

John Fortin
fortinj@ibm.net

Re: ld, dlls, and windows libraries

[Mumit Khan]

On Fri, 12 Feb 1999, John Fortin wrote:

>     Is there the equiv. of -mwindows for ld.  The trouble occurs when I
> build a DLL which uses win32 api, I get a bunch of errors for unknown
> symbols.  If I manually add ( by trial and error at this point )
> -lkernel32 -lm and other libraries, I am able to finish the build of the
> DLL.
>     Is there a shortcut, or is there a list which indicates which
> functions are in which libs.  I suppose I could use nm, but that seems
> inefficient.

Yes, use gcc! 

<gratuitous gripe mode> I frequently see folks using ld to build DLLs,
and run into all sorts of problems. Why use ld when gcc does all of
this and more?? Is it because Cygwin User Guide shows the most 
convoluted and error-prone way to build DLLs? Also interesting is the 
aversion to using the search facility in the mailing list where I and 
others have posted info on portably building DLLs many many times. 
<off now, whew!>

Here's a start:

  $ gcc -c foo1.c foo2.c
  $ dllwrap -o mydll.dll -mwindows --export-all foo1.o foo2.o

When DJ's excellent work on ld is released, you'll be able to do:

  $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o

The --export-all exports all the non-static symbols as done on most 
Unix systems. If you want to restrict the exports, you have two choices:
  
  - provide a DEF file via ``--def mydef.def'', or
  - use __attribute__((dllexport)) or alternatively __declspec(dllexport) 
    in your sources, 

instead of using --export-all. The option --add-stdcall-alias adds aliases
for STDCALL symbols without the trailing @<n> to be compatible with MSVC.

Regards,
Mumit

Re: ld, dlls, and windows libraries

[John Fortin]

Oops, your are definitely correct.  I should have checked the mail archives
first.
Sorry about that.  And yes, I was following in instructions in the users
guide.

Thanks for the info!!

John Fortin,
fortinj@ibm.net

Mumit Khan wrote:

> On Fri, 12 Feb 1999, John Fortin wrote:
>
> >     Is there the equiv. of -mwindows for ld.  The trouble occurs when I
> > build a DLL which uses win32 api, I get a bunch of errors for unknown
> > symbols.  If I manually add ( by trial and error at this point )
> > -lkernel32 -lm and other libraries, I am able to finish the build of the
> > DLL.
> >     Is there a shortcut, or is there a list which indicates which
> > functions are in which libs.  I suppose I could use nm, but that seems
> > inefficient.
>
> Yes, use gcc!
>
> <gratuitous gripe mode> I frequently see folks using ld to build DLLs,
> and run into all sorts of problems. Why use ld when gcc does all of
> this and more?? Is it because Cygwin User Guide shows the most
> convoluted and error-prone way to build DLLs? Also interesting is the
> aversion to using the search facility in the mailing list where I and
> others have posted info on portably building DLLs many many times.
> <off now, whew!>
>
> Here's a start:
>
>   $ gcc -c foo1.c foo2.c
>   $ dllwrap -o mydll.dll -mwindows --export-all foo1.o foo2.o
>
> When DJ's excellent work on ld is released, you'll be able to do:
>
>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
>
> The --export-all exports all the non-static symbols as done on most
> Unix systems. If you want to restrict the exports, you have two choices:
>
>   - provide a DEF file via ``--def mydef.def'', or
>   - use __attribute__((dllexport)) or alternatively __declspec(dllexport)
>     in your sources,
>
> instead of using --export-all. The option --add-stdcall-alias adds aliases
> for STDCALL symbols without the trailing @<n> to be compatible with MSVC.
>
> Regards,
> Mumit

Re: ld, dlls, and windows libraries

[Geoffrey Noer]

On Fri, Feb 12, 1999, Mumit Khan wrote:
[...]
> <gratuitous gripe mode> I frequently see folks using ld to build DLLs,
> and run into all sorts of problems. Why use ld when gcc does all of
> this and more?? Is it because Cygwin User Guide shows the most 
> convoluted and error-prone way to build DLLs? Also interesting is the 
> aversion to using the search facility in the mailing list where I and 
> others have posted info on portably building DLLs many many times. 
> <off now, whew!>

FYI, the example in the User's Guide now calls gcc instead of ld.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

Re[2]: ld, dlls, and windows libraries

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.edu> wrote:

[]

MK> When DJ's excellent work on ld is released, you'll be able to do:

MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o

  Wow! How long to wait for this?

MK> The --export-all exports all the non-static symbols as done on most 
MK> Unix systems. If you want to restrict the exports, you have two choices:

  And what about implibs? Is there a chance that they will be produced
with gcc too, so procedure and data exports will be properly
distinguished? That's the thing which causes most pain with gnu-win32
tools now, imho, - suffering an access violation when, due to automatically
produced def, which treats all exports as code, some fucnction fetches jump
instruction instead of data.


MK> Regards,
MK> Mumit



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua

Re: Re[2]: ld, dlls, and windows libraries

[Mumit Khan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:
> 
> MK> When DJ's excellent work on ld is released, you'll be able to do:
> 
> MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> 
>   Wow! How long to wait for this?

DJ is the person to ask.

> MK> The --export-all exports all the non-static symbols as done on most 
> MK> Unix systems. If you want to restrict the exports, you have two choices:
> 
>   And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.

I'm not exactly sure what you're asking, but I'll take a stab at it. 
Currently you can create implib with dllwrap directly when building the 
DLL:

  $ dllwrap --implib libfoo.a [rest of command line]

DJ's new ld has the same option:

  $ ld --shared --implib libfoo.a [rest of command line]

As for data vs code, that's a fundamental limitation of Windows32 DLLs;
you have to optionally tag data as exportable in the DLL and access it 
via __declspec(dllimport) to get the correct code, otherwise you get 
garbage.

eg., when building a DLL:
  
  int __declspec(dllexport) globalvar;

and when using the the DLL:
  
  int __declspec(dllimport) globalvar;

The DEF file entry is however the same for code and data. You can also
add the DATA keyword in DEF file, but I forget exactly what the
implications are.

The examples I distribute as part of dllhelpers package show how to do
data just as you would do for MSVC or other commercial compilers.

The thing to remember is that creating true shared libraries as one would
expect on most modern variants of Unix (eg., ELF) is just not possible on
windows32; Interix does it, but it is a very different beast.

If this is not what you're asking, please let me know. 

Regards,
Mumit

Re: ld, dlls, and windows libraries

[DJ Delorie]

> MK> When DJ's excellent work on ld is released, you'll be able to do:
> MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> 
>   Wow! How long to wait for this?

It's in our master sources, it's all a matter of when we do the next
full beta.  I'm not sure about the "--export-all" part; you may need
to do "-Wl,--export-all" as that's a linker-specific option.  Unless
someone wants to get it into egcs (hint).

> MK> The --export-all exports all the non-static symbols as done on most 

It's *supposed* to only export non-static functions, not non-static
data.

> MK> Unix systems. If you want to restrict the exports, you have two choices:
> 
>   And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.

The changes I did to ld allow the following cool new features:

* ld can produce a DLL instead of an EXE.

* ld can produce the implib at the same time it produces the dll.

* You can list .def files on the command lines just like objects when
  creating dlls, or the IMPORTS section can be used instead of linking
  against a dll (i.e. a def file's IMPORTS can replace an implib).

* You can tell ld to *produce* a .def file (for --export-all and
  attribute()) when it produces the dll.

* You can list a DLL on the command line just like a library (it
  synthesizes the implib internally).

* "ld --help" lists all the nt-specific options.

As far as data/code differences, you MUST tag all your imported data
as imported (attribute((dllimport))) in your header files for gcc to
produce the correct code to access them.  Even if ld did this right (I
don't think it does), it would only change your error from a segfault
to an unresolved external.

If anyone wants to test this ld, or submit additions to it, mail me
personally.  Please include a note about what you're thinking of
doing, too.

Re: ld, dlls, and windows libraries

[Mumit Khan]

DJ Delorie <dj@delorie.com> writes:
> It's in our master sources, it's all a matter of when we do the next
> full beta.  I'm not sure about the "--export-all" part; you may need
> to do "-Wl,--export-all" as that's a linker-specific option.  Unless
> someone wants to get it into egcs (hint).

I have it in my local sources, but I haven't submitted it yet. I'm trying
to figure out a way currently to have both the existing and the new method
coexist in the SPECS, and my conditionals came out wrong last time I
tried. Basically, it's a nested conditional based on whether '--dll' or
'--shared' is specified.

Any idea what I should call the --export-all option when invoked via GCC? 
Leave as is or something else like -mexport-all?? GCC specs will
essentially translate this to --export-all when calling the linker.

> It's *supposed* to only export non-static functions, not non-static
> data.

Ah, yes. Thanks.

Regards,
Mumit

Re[2]: ld, dlls, and windows libraries

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.EDU> wrote:

MK> DJ Delorie <dj@delorie.com> writes:
>> It's in our master sources, it's all a matter of when we do the next
>> full beta.  I'm not sure about the "--export-all" part; you may need
>> to do "-Wl,--export-all" as that's a linker-specific option.  Unless
>> someone wants to get it into egcs (hint).

[]

>> It's *supposed* to only export non-static functions, not non-static
>> data.

   But what about data? There's really LOT of libraries which use data
interface in API (most GNU libs do that too - just count: readline,
bfd...). It would be very nice if they can be seamlessly (without
changing source, adding defs, etc.) compiled as dll (and has correct
implib, too).

  What we have now:

Dlltool can automatically make .def file from objects which are
supposed to go to dll, but that def has no DATA keyword for data, so
all by default treated as code, which in result give incorrect imlib.

  What is going to be when DJ's work's out:

Ignoring data at all.


  But what I argue is that it's possible on object file level to
distinguish data and code and to produce correct implibs
automatically - just because COFF symbol has code/data attribute (not
counting that it may be inferred from the section symbol in).

  I'm sorry if I make incoreect implications and/or there're other
factors which make described impossible. I'd appreciate if you could
explain this or point to information about.

MK> Regards,
MK> Mumit



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua

Re: ld, dlls, and windows libraries

[DJ Delorie]

> >> It's *supposed* to only export non-static functions, not non-static
> >> data.
> 
>    But what about data? There's really LOT of libraries which use data
> interface in API (most GNU libs do that too - just count: readline,
> bfd...). It would be very nice if they can be seamlessly (without
> changing source, adding defs, etc.) compiled as dll (and has correct
> implib, too).

You just can't use the --export-all function for those.  *All* data
exported by the dll *must* be tagged as __attribute__((dllimport)) or
gcc will not produce the correct code for it.  If you're tagging it
anyway, ld will notice that and export it - even without the
--export-all option.  The only time --export-all would make a
difference with data is when it turns an undefined reference into an
incorrect reference.  You'd be better off without it!

Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS.  The linker can't
get it right without gcc's help, and if it has gcc's help, it doesn't
need --export-all to finish the job.

>   But what I argue is that it's possible on object file level to
> distinguish data and code and to produce correct implibs
> automatically - just because COFF symbol has code/data attribute (not
> counting that it may be inferred from the section symbol in).

True, but gcc will not use the implib correctly.  You don't understand
what gcc has to go through to access data in a dll - IT'S NOT A LINKER
PROBLEM.  Gcc has to produce *different* code depending on whether
data is local or imported - it can't use a link-time thunk like it can
for functions.  GCC MUST KNOW ABOUT IMPORTED DATA.  When it does, it
will tell the linker how to deal with it.  There is nothing the linker
can do about it, so there is no reason to provide linker-specific
options to automatically handle data.

Re[2]: ld, dlls, and windows libraries

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.edu> wrote:

[]

MK> When DJ's excellent work on ld is released, you'll be able to do:

MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o

  Wow! How long to wait for this?

MK> The --export-all exports all the non-static symbols as done on most 
MK> Unix systems. If you want to restrict the exports, you have two choices:

  And what about implibs? Is there a chance that they will be produced
with gcc too, so procedure and data exports will be properly
distinguished? That's the thing which causes most pain with gnu-win32
tools now, imho, - suffering an access violation when, due to automatically
produced def, which treats all exports as code, some fucnction fetches jump
instruction instead of data.


MK> Regards,
MK> Mumit



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua

Re: ld, dlls, and windows libraries

[DJ Delorie]

> >> It's *supposed* to only export non-static functions, not non-static
> >> data.
> 
>    But what about data? There's really LOT of libraries which use data
> interface in API (most GNU libs do that too - just count: readline,
> bfd...). It would be very nice if they can be seamlessly (without
> changing source, adding defs, etc.) compiled as dll (and has correct
> implib, too).

You just can't use the --export-all function for those.  *All* data
exported by the dll *must* be tagged as __attribute__((dllimport)) or
gcc will not produce the correct code for it.  If you're tagging it
anyway, ld will notice that and export it - even without the
--export-all option.  The only time --export-all would make a
difference with data is when it turns an undefined reference into an
incorrect reference.  You'd be better off without it!

Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS.  The linker can't
get it right without gcc's help, and if it has gcc's help, it doesn't
need --export-all to finish the job.

>   But what I argue is that it's possible on object file level to
> distinguish data and code and to produce correct implibs
> automatically - just because COFF symbol has code/data attribute (not
> counting that it may be inferred from the section symbol in).

True, but gcc will not use the implib correctly.  You don't understand
what gcc has to go through to access data in a dll - IT'S NOT A LINKER
PROBLEM.  Gcc has to produce *different* code depending on whether
data is local or imported - it can't use a link-time thunk like it can
for functions.  GCC MUST KNOW ABOUT IMPORTED DATA.  When it does, it
will tell the linker how to deal with it.  There is nothing the linker
can do about it, so there is no reason to provide linker-specific
options to automatically handle data.

Re: Re[2]: ld, dlls, and windows libraries

[Mumit Khan]

Paul Sokolovsky <paul-ml@is.lg.ua> writes:
> 
> MK> When DJ's excellent work on ld is released, you'll be able to do:
> 
> MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> 
>   Wow! How long to wait for this?

DJ is the person to ask.

> MK> The --export-all exports all the non-static symbols as done on most 
> MK> Unix systems. If you want to restrict the exports, you have two choices:
> 
>   And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.

I'm not exactly sure what you're asking, but I'll take a stab at it. 
Currently you can create implib with dllwrap directly when building the 
DLL:

  $ dllwrap --implib libfoo.a [rest of command line]

DJ's new ld has the same option:

  $ ld --shared --implib libfoo.a [rest of command line]

As for data vs code, that's a fundamental limitation of Windows32 DLLs;
you have to optionally tag data as exportable in the DLL and access it 
via __declspec(dllimport) to get the correct code, otherwise you get 
garbage.

eg., when building a DLL:
  
  int __declspec(dllexport) globalvar;

and when using the the DLL:
  
  int __declspec(dllimport) globalvar;

The DEF file entry is however the same for code and data. You can also
add the DATA keyword in DEF file, but I forget exactly what the
implications are.

The examples I distribute as part of dllhelpers package show how to do
data just as you would do for MSVC or other commercial compilers.

The thing to remember is that creating true shared libraries as one would
expect on most modern variants of Unix (eg., ELF) is just not possible on
windows32; Interix does it, but it is a very different beast.

If this is not what you're asking, please let me know. 

Regards,
Mumit

ld, dlls, and windows libraries

[John Fortin]

Hi,
    I have a quick question...

    Is there the equiv. of -mwindows for ld.  The trouble occurs when I
build a DLL which uses win32 api, I get a bunch of errors for unknown
symbols.  If I manually add ( by trial and error at this point )
-lkernel32 -lm and other libraries, I am able to finish the build of the
DLL.

    Is there a shortcut, or is there a list which indicates which
functions are in which libs.  I suppose I could use nm, but that seems
inefficient.

Thanks,

John Fortin
fortinj@ibm.net

Re: ld, dlls, and windows libraries

[Geoffrey Noer]

On Fri, Feb 12, 1999, Mumit Khan wrote:
[...]
> <gratuitous gripe mode> I frequently see folks using ld to build DLLs,
> and run into all sorts of problems. Why use ld when gcc does all of
> this and more?? Is it because Cygwin User Guide shows the most 
> convoluted and error-prone way to build DLLs? Also interesting is the 
> aversion to using the search facility in the mailing list where I and 
> others have posted info on portably building DLLs many many times. 
> <off now, whew!>

FYI, the example in the User's Guide now calls gcc instead of ld.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

Re[2]: ld, dlls, and windows libraries

[Paul Sokolovsky]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.EDU> wrote:

MK> DJ Delorie <dj@delorie.com> writes:
>> It's in our master sources, it's all a matter of when we do the next
>> full beta.  I'm not sure about the "--export-all" part; you may need
>> to do "-Wl,--export-all" as that's a linker-specific option.  Unless
>> someone wants to get it into egcs (hint).

[]

>> It's *supposed* to only export non-static functions, not non-static
>> data.

   But what about data? There's really LOT of libraries which use data
interface in API (most GNU libs do that too - just count: readline,
bfd...). It would be very nice if they can be seamlessly (without
changing source, adding defs, etc.) compiled as dll (and has correct
implib, too).

  What we have now:

Dlltool can automatically make .def file from objects which are
supposed to go to dll, but that def has no DATA keyword for data, so
all by default treated as code, which in result give incorrect imlib.

  What is going to be when DJ's work's out:

Ignoring data at all.


  But what I argue is that it's possible on object file level to
distinguish data and code and to produce correct implibs
automatically - just because COFF symbol has code/data attribute (not
counting that it may be inferred from the section symbol in).

  I'm sorry if I make incoreect implications and/or there're other
factors which make described impossible. I'd appreciate if you could
explain this or point to information about.

MK> Regards,
MK> Mumit



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua

Re: ld, dlls, and windows libraries

[Mumit Khan]

DJ Delorie <dj@delorie.com> writes:
> It's in our master sources, it's all a matter of when we do the next
> full beta.  I'm not sure about the "--export-all" part; you may need
> to do "-Wl,--export-all" as that's a linker-specific option.  Unless
> someone wants to get it into egcs (hint).

I have it in my local sources, but I haven't submitted it yet. I'm trying
to figure out a way currently to have both the existing and the new method
coexist in the SPECS, and my conditionals came out wrong last time I
tried. Basically, it's a nested conditional based on whether '--dll' or
'--shared' is specified.

Any idea what I should call the --export-all option when invoked via GCC? 
Leave as is or something else like -mexport-all?? GCC specs will
essentially translate this to --export-all when calling the linker.

> It's *supposed* to only export non-static functions, not non-static
> data.

Ah, yes. Thanks.

Regards,
Mumit

Re: ld, dlls, and windows libraries

[DJ Delorie]

> MK> When DJ's excellent work on ld is released, you'll be able to do:
> MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> 
>   Wow! How long to wait for this?

It's in our master sources, it's all a matter of when we do the next
full beta.  I'm not sure about the "--export-all" part; you may need
to do "-Wl,--export-all" as that's a linker-specific option.  Unless
someone wants to get it into egcs (hint).

> MK> The --export-all exports all the non-static symbols as done on most 

It's *supposed* to only export non-static functions, not non-static
data.

> MK> Unix systems. If you want to restrict the exports, you have two choices:
> 
>   And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.

The changes I did to ld allow the following cool new features:

* ld can produce a DLL instead of an EXE.

* ld can produce the implib at the same time it produces the dll.

* You can list .def files on the command lines just like objects when
  creating dlls, or the IMPORTS section can be used instead of linking
  against a dll (i.e. a def file's IMPORTS can replace an implib).

* You can tell ld to *produce* a .def file (for --export-all and
  attribute()) when it produces the dll.

* You can list a DLL on the command line just like a library (it
  synthesizes the implib internally).

* "ld --help" lists all the nt-specific options.

As far as data/code differences, you MUST tag all your imported data
as imported (attribute((dllimport))) in your header files for gcc to
produce the correct code to access them.  Even if ld did this right (I
don't think it does), it would only change your error from a segfault
to an unresolved external.

If anyone wants to test this ld, or submit additions to it, mail me
personally.  Please include a note about what you're thinking of
doing, too.

Re: ld, dlls, and windows libraries

[Mumit Khan]

On Fri, 12 Feb 1999, John Fortin wrote:

>     Is there the equiv. of -mwindows for ld.  The trouble occurs when I
> build a DLL which uses win32 api, I get a bunch of errors for unknown
> symbols.  If I manually add ( by trial and error at this point )
> -lkernel32 -lm and other libraries, I am able to finish the build of the
> DLL.
>     Is there a shortcut, or is there a list which indicates which
> functions are in which libs.  I suppose I could use nm, but that seems
> inefficient.

Yes, use gcc! 

<gratuitous gripe mode> I frequently see folks using ld to build DLLs,
and run into all sorts of problems. Why use ld when gcc does all of
this and more?? Is it because Cygwin User Guide shows the most 
convoluted and error-prone way to build DLLs? Also interesting is the 
aversion to using the search facility in the mailing list where I and 
others have posted info on portably building DLLs many many times. 
<off now, whew!>

Here's a start:

  $ gcc -c foo1.c foo2.c
  $ dllwrap -o mydll.dll -mwindows --export-all foo1.o foo2.o

When DJ's excellent work on ld is released, you'll be able to do:

  $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o

The --export-all exports all the non-static symbols as done on most 
Unix systems. If you want to restrict the exports, you have two choices:
  
  - provide a DEF file via ``--def mydef.def'', or
  - use __attribute__((dllexport)) or alternatively __declspec(dllexport) 
    in your sources, 

instead of using --export-all. The option --add-stdcall-alias adds aliases
for STDCALL symbols without the trailing @<n> to be compatible with MSVC.

Regards,
Mumit

Re: ld, dlls, and windows libraries

[John Fortin]

Oops, your are definitely correct.  I should have checked the mail archives
first.
Sorry about that.  And yes, I was following in instructions in the users
guide.

Thanks for the info!!

John Fortin,
fortinj@ibm.net

Mumit Khan wrote:

> On Fri, 12 Feb 1999, John Fortin wrote:
>
> >     Is there the equiv. of -mwindows for ld.  The trouble occurs when I
> > build a DLL which uses win32 api, I get a bunch of errors for unknown
> > symbols.  If I manually add ( by trial and error at this point )
> > -lkernel32 -lm and other libraries, I am able to finish the build of the
> > DLL.
> >     Is there a shortcut, or is there a list which indicates which
> > functions are in which libs.  I suppose I could use nm, but that seems
> > inefficient.
>
> Yes, use gcc!
>
> <gratuitous gripe mode> I frequently see folks using ld to build DLLs,
> and run into all sorts of problems. Why use ld when gcc does all of
> this and more?? Is it because Cygwin User Guide shows the most
> convoluted and error-prone way to build DLLs? Also interesting is the
> aversion to using the search facility in the mailing list where I and
> others have posted info on portably building DLLs many many times.
> <off now, whew!>
>
> Here's a start:
>
>   $ gcc -c foo1.c foo2.c
>   $ dllwrap -o mydll.dll -mwindows --export-all foo1.o foo2.o
>
> When DJ's excellent work on ld is released, you'll be able to do:
>
>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
>
> The --export-all exports all the non-static symbols as done on most
> Unix systems. If you want to restrict the exports, you have two choices:
>
>   - provide a DEF file via ``--def mydef.def'', or
>   - use __attribute__((dllexport)) or alternatively __declspec(dllexport)
>     in your sources,
>
> instead of using --export-all. The option --add-stdcall-alias adds aliases
> for STDCALL symbols without the trailing @<n> to be compatible with MSVC.
>
> Regards,
> Mumit