This is the mail archive of the firstname.lastname@example.org
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]
How to handle variables (data, etc.) in DLLs?
- To: email@example.com
- Subject: How to handle variables (data, etc.) in DLLs?
- From: T J Harding <firstname.lastname@example.org>
- Date: Wed, 03 Mar 1999 14:05:40 +0000
- Delivered-To: email@example.com
- Delivered-To: mailing list firstname.lastname@example.org
- Mailing-List: contact email@example.com; run by ezmlm
- Organization: Quadstone
- Sender: firstname.lastname@example.org
- Sender: email@example.com
I was porting something to Cygwin and all was going swimmingly, until I
ran into problems building a DLL from object code with global data
nm shows these symbols as type D or C).
Just to make it clearer, a trivial example:
main.c might contain:
extern int foo;
extern void bar(void);
int main ( int argc, char **argv )
and foo.c might contain:
It is foo.o that I want to include in a DLL.
I was using dllwrap 0.2.4 (and dlltool 2.9.4) with b20.1 (95 and NT).
"dllwrap --export-all-symbols" exports the data symbols to the .def
they seem to be exported as if they were functions, resulting in a core
when a.exe is run. I've tried putting "DATA" after the symbol name in
.def file, which results in the symbol being undefined in the import-lib
libfoo.a, meaning I have to link foo.o in as well as libfoo.a.
So how should one best deal with this situation? It's not my code, so I
want to have to alter it significantly just to port it.
tel;cell:+44 961 444986
tel;fax:+44 131 220 4492
tel;work:+44 131 220 4491
adr:;;16 Chester Street;Edinburgh;Scotland;EH3 7RA;United Kingdom
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org