public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: Paul Sokoilovsky <paul-ml@is.lg.ua>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Re[2]: ld, dlls, and windows libraries
Date: Sat, 13 Feb 1999 09:52:00 -0000	[thread overview]
Message-ID: <199902131751.LAA20089@modi.xraylith.wisc.edu> (raw)
In-Reply-To: Your message of "Sat, 13 Feb 1999 19:25:34 +0200."            < 1809.990213@is.lg.ua >

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

WARNING: multiple messages have this Message-ID
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: Paul Sokoilovsky <paul-ml@is.lg.ua>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Re[2]: ld, dlls, and windows libraries
Date: Sun, 28 Feb 1999 23:02:00 -0000	[thread overview]
Message-ID: <199902131751.LAA20089@modi.xraylith.wisc.edu> (raw)
Message-ID: <19990228230200.BhFh5SfkzvD7uAyQdPpfe4Q6wgS4adinGxw9GAo2aZU@z> (raw)
In-Reply-To: <1809.990213@is.lg.ua>

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


  parent reply	other threads:[~1999-02-13  9:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-12  8:40 John Fortin
     [not found] ` < 36C4582C.A302D915@ibm.net >
1999-02-12  9:56   ` Mumit Khan
1999-02-12 10:06     ` John Fortin
1999-02-28 23:02       ` John Fortin
     [not found]     ` < Pine.SUN.3.93.990212113933.18731B-100000@modi.xraylith.wisc.edu >
1999-02-12 16:53       ` Geoffrey Noer
1999-02-28 23:02         ` Geoffrey Noer
1999-02-13  9:28     ` Re[2]: " Paul Sokolovsky
     [not found]       ` < 1809.990213@is.lg.ua >
1999-02-13  9:52         ` Mumit Khan [this message]
1999-02-28 23:02           ` Mumit Khan
1999-02-13  9:52         ` DJ Delorie
     [not found]           ` < 199902131751.MAA26487@envy.delorie.com >
1999-02-13 10:02             ` Mumit Khan
1999-02-13 10:40               ` Re[2]: " Paul Sokolovsky
     [not found]                 ` < 13857.990213@is.lg.ua >
1999-02-13 10:48                   ` DJ Delorie
1999-02-28 23:02                     ` DJ Delorie
1999-02-28 23:02                 ` Re[2]: " Paul Sokolovsky
1999-02-28 23:02               ` Mumit Khan
1999-02-28 23:02           ` DJ Delorie
1999-02-28 23:02       ` Re[2]: " Paul Sokolovsky
1999-02-28 23:02     ` Mumit Khan
1999-02-28 23:02 ` John Fortin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199902131751.LAA20089@modi.xraylith.wisc.edu \
    --to=khan@xraylith.wisc.edu \
    --cc=cygwin@sourceware.cygnus.com \
    --cc=paul-ml@is.lg.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).