This is the mail archive of the cygwin@sourceware.cygnus.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re[2]: ld, dlls, and windows libraries
- To: Mumit Khan <khan@xraylith.wisc.edu>, <cygwin@sourceware.cygnus.com>
- Subject: Re[2]: ld, dlls, and windows libraries
- From: Paul Sokolovsky <paul-ml@is.lg.ua>
- Date: Sat, 13 Feb 1999 19:25:34 +0200
- Delivered-To: listarch-cygwin@sourceware.cygnus.com
- Delivered-To: mailing list cygwin@sourceware.cygnus.com
- Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
- Priority: Normal
- References: <Pine.SUN.3.93.990212113933.18731B-100000@modi.xraylith.wisc.edu>
- Reply-To: Paul Sokoilovsky <paul-ml@is.lg.ua>
- Sender: cygwin-owner@sourceware.cygnus.com
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