public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Can't build a DLL using gcc
@ 2000-06-15 14:12 kulack
  2000-06-15 15:40 ` Carl Thompson
  0 siblings, 1 reply; 8+ messages in thread
From: kulack @ 2000-06-15 14:12 UTC (permalink / raw)
  To: cygwin

I'm pretty new at Win and gcc development. I've been searching the archives
for details about this, but have only found hints.
I've followed the instrutions at
http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html for building
DLLs using GCC, but get a STATUS_ACCESS_VIOLATION when I attempt to use it.

About my only guess is that I'm doing something wrong with the .DEF file.
Can it get created automatically or should there be a 'SECTIONS' section in
the .DEF file indicating which type of access (EXECUTE, READ, WRITE) the
dll should have?
Not familiar with nm output, but it seems to look ok for the created dll...
Can anyone teach me to fish? 8-)

Bash /db2src/test
 > make libhello.a
gcc  -g -c -I/sqllib/include libhello.c
gcc -s -Wl,--base-file,libhello.base -o libhello.dll libhello.o
-Wl,-e,_mydll_init@12
dlltool --base-file libhello.base --def libhello.def --output-exp
libhello.exp --dllname libhello.dll
gcc -s -Wl,--base-file,libhello.base,libhello.exp -o libhello.dll
libhello.o -Wl,-e,_mydll_init@12
dlltool --base-file libhello.base --def libhello.def --output-exp
libhello.exp --dllname libhello.dll
gcc -Wl,libhello.exp -o libhello.dll libhello.o -Wl,-e,_mydll_init@12
dlltool --def libhello.def --dllname libhello.dll --output-lib libhello.a
cp libhello.dll ..
rm libhello.o

Bash /db2src/test
 > make hello.exe
gcc  -g -c -I/sqllib/include hello.c
gcc  -g hello.o -L/db2src/test -lhello
mv a.exe hello.exe

Bash /db2src/test
 > hello
Hello World
      0 [main] hello 1127 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   9205 [main] hello 1127 stackdump: Dumping stack trace to
hello.exe.stackdump

Bash /db2src/test
 > cat hello.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=000055CC
eax=00000009 ebx=00000000 ecx=0000000C edx=0245FDF4 esi=00000000
edi=0A041448
ebp=0245FE74 esp=0245FE58 program=c:\db2src\test\hello.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0245FE74  00401085  (00000009, 0245FEB0, 0245FEA4, 0040106B)
0245FEA4  00401085  (00000001, 0A041448, 0A040008, 00000000)
0245FF00  610022E5  (7FFDF000, 00000000, 00000018, 80452662)
0245FF60  61002735  (00403010, 00000000, 0245FF90, 004011DA)
0245FF90  004011E7  (00401060, FFFFFFFF, 80430B27, 00000000)
0245FFC0  0040103B  (00000018, 00000000, 7FFDF000, 00000000)
0245FFF0  77E87903  (00401000, 00000000, 000000C8, 00000100)
End of stack trace

======= libhello.c
#include <stdio.h>
#include <windows.h>
extern int helloFromDll(int parm);

int WINAPI
mydll_init(HANDLE h, DWORD reason, void *foo)
{
   return 1;
}

int helloFromDll(int parm) {
   printf("Hello from Dll, parm=%d\n", parm);
   return parm+1;
}

int main(int argc, char **argv) {
   // This doesn't feel right...
   // Was forced to add main() in order to get the
   // instructions for building DLLs at
   //   http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html
   // to work correctly, otherwise, linker failed to
   // find WinMain@16 (which I wouldn't have believed it should
   // require).
}

======= libhello.def
LIBRARY LIBHELLO
DESCRIPTION 'LIBHELLO.DLL Testcase'
EXPORTS
   helloFromDll

======= hello.c
#include <stdio.h>
extern int helloFromDll(int parm);
int main(int argc, char **argv)
{
   int         rc;
   printf("Hello World\n");
   rc = helloFromDll(9);
   printf("DLL returned %d\n", rc);
   return 0;
}




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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
  2000-06-15 14:12 Can't build a DLL using gcc kulack
@ 2000-06-15 15:40 ` Carl Thompson
  2000-06-15 16:17   ` Charles Wilson
  2000-06-15 23:13   ` Heinz-Juergen Oertel
  0 siblings, 2 replies; 8+ messages in thread
From: Carl Thompson @ 2000-06-15 15:40 UTC (permalink / raw)
  To: kulack; +Cc: Cygwin List

I wrote a message to the list the other day about a much easier way to
create DLLs using Cygwin than using dlltool, dllhelpers and .def files.  You
can see it at

   http://sourceware.cygnus.com/ml/cygwin/2000-06/msg00688.html

This method is not only easier, but also allows you to maintain your symbol
information in one place-- the header files where they belong.  You don't
have to try to keep separate .def files in sync.

Even if you choose to keep using .def files, I believe you can use the newer
method to actually create the DLLs anyway.  This might cure your problem.  I
highly recommend not using .def files and using the technique described in
my message.  It guarantees that the symbols you want to export are exported
correctly.

I know this method works because I use it for non trivial projects.  It's
quite possible the documentation you looked at is outdated or inaccurate.

Hope this helps,
Carl Thompson

kulack@us.ibm.com wrote:
> 
> I'm pretty new at Win and gcc development. I've been searching the archives
> for details about this, but have only found hints.
> I've followed the instrutions at
> http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html for building
> DLLs using GCC, but get a STATUS_ACCESS_VIOLATION when I attempt to use it.
> 
> About my only guess is that I'm doing something wrong with the .DEF file.
> Can it get created automatically or should there be a 'SECTIONS' section in
> the .DEF file indicating which type of access (EXECUTE, READ, WRITE) the
> dll should have?
> Not familiar with nm output, but it seems to look ok for the created dll...
> Can anyone teach me to fish? 8-)
> 
> Bash /db2src/test
>  > make libhello.a
> gcc  -g -c -I/sqllib/include libhello.c
> gcc -s -Wl,--base-file,libhello.base -o libhello.dll libhello.o
> -Wl,-e,_mydll_init@12
> dlltool --base-file libhello.base --def libhello.def --output-exp
> libhello.exp --dllname libhello.dll
> gcc -s -Wl,--base-file,libhello.base,libhello.exp -o libhello.dll
> libhello.o -Wl,-e,_mydll_init@12
> dlltool --base-file libhello.base --def libhello.def --output-exp
> libhello.exp --dllname libhello.dll
> gcc -Wl,libhello.exp -o libhello.dll libhello.o -Wl,-e,_mydll_init@12
> dlltool --def libhello.def --dllname libhello.dll --output-lib libhello.a
> cp libhello.dll ..
> rm libhello.o
> 
> Bash /db2src/test
>  > make hello.exe
> gcc  -g -c -I/sqllib/include hello.c
> gcc  -g hello.o -L/db2src/test -lhello
> mv a.exe hello.exe
> 
> Bash /db2src/test
>  > hello
> Hello World
>       0 [main] hello 1127 handle_exceptions: Exception:
> STATUS_ACCESS_VIOLATION
>    9205 [main] hello 1127 stackdump: Dumping stack trace to
> hello.exe.stackdump
> 
> Bash /db2src/test
>  > cat hello.exe.stackdump
> Exception: STATUS_ACCESS_VIOLATION at eip=000055CC
> eax=00000009 ebx=00000000 ecx=0000000C edx=0245FDF4 esi=00000000
> edi=0A041448
> ebp=0245FE74 esp=0245FE58 program=c:\db2src\test\hello.exe
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0245FE74  00401085  (00000009, 0245FEB0, 0245FEA4, 0040106B)
> 0245FEA4  00401085  (00000001, 0A041448, 0A040008, 00000000)
> 0245FF00  610022E5  (7FFDF000, 00000000, 00000018, 80452662)
> 0245FF60  61002735  (00403010, 00000000, 0245FF90, 004011DA)
> 0245FF90  004011E7  (00401060, FFFFFFFF, 80430B27, 00000000)
> 0245FFC0  0040103B  (00000018, 00000000, 7FFDF000, 00000000)
> 0245FFF0  77E87903  (00401000, 00000000, 000000C8, 00000100)
> End of stack trace
> 
> ======= libhello.c
> #include <stdio.h>
> #include <windows.h>
> extern int helloFromDll(int parm);
> 
> int WINAPI
> mydll_init(HANDLE h, DWORD reason, void *foo)
> {
>    return 1;
> }
> 
> int helloFromDll(int parm) {
>    printf("Hello from Dll, parm=%d\n", parm);
>    return parm+1;
> }
> 
> int main(int argc, char **argv) {
>    // This doesn't feel right...
>    // Was forced to add main() in order to get the
>    // instructions for building DLLs at
>    //   http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html
>    // to work correctly, otherwise, linker failed to
>    // find WinMain@16 (which I wouldn't have believed it should
>    // require).
> }
> 
> ======= libhello.def
> LIBRARY LIBHELLO
> DESCRIPTION 'LIBHELLO.DLL Testcase'
> EXPORTS
>    helloFromDll
> 
> ======= hello.c
> #include <stdio.h>
> extern int helloFromDll(int parm);
> int main(int argc, char **argv)
> {
>    int         rc;
>    printf("Hello World\n");
>    rc = helloFromDll(9);
>    printf("DLL returned %d\n", rc);
>    return 0;
> }
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
  2000-06-15 15:40 ` Carl Thompson
@ 2000-06-15 16:17   ` Charles Wilson
  2000-06-15 16:39     ` Carl Thompson
  2000-06-15 23:13   ` Heinz-Juergen Oertel
  1 sibling, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2000-06-15 16:17 UTC (permalink / raw)
  To: Carl Thompson; +Cc: kulack, Cygwin List

Carl Thompson wrote:
> 
> I wrote a message to the list the other day about a much easier way to
> create DLLs using Cygwin than using dlltool, dllhelpers and .def files.  You
> can see it at
> 
>    http://sourceware.cygnus.com/ml/cygwin/2000-06/msg00688.html
> 
> This method is not only easier, but also allows you to maintain your symbol
> information in one place-- the header files where they belong.  You don't
> have to try to keep separate .def files in sync.
> 
> Even if you choose to keep using .def files, I believe you can use the newer
> method to actually create the DLLs anyway.  This might cure your problem.  I
> highly recommend not using .def files and using the technique described in
> my message.  It guarantees that the symbols you want to export are exported
> correctly.
> 
> I know this method works because I use it for non trivial projects.  It's
> quite possible the documentation you looked at is outdated or inaccurate.
> 
> Hope this helps,
> Carl Thompson

You probably *should* use def files if (a) you're developing a library
that other folks might want to use, without recompiling their
application code, and (b) you want to support those apps that
'import-by-number' from the dll. With the no-def-file method, you're
never guaranteed that the name/numbers will be the same from build to
build. That is:

----sample def file 1-----
EXPORTS
   my_func1 @1
   my_func2 @2
------------------------

Suppose the first time you build your library dll using the no-def-file
method, it generates the dll as described by the sample def file #1
above (by luck or what have you).

Then, another developer ('John') uses your dll to write an application,
and links by number. So he accesses my_func1 via the dll-position number
'@1' and my_func2 via '@2'.

Later, you add a new function to your library, new_func. Then, you
rebuild the dll, and (by luck or what have you) the dll is built
according to the following def file:

----sample def file 2-----
EXPORTS
   new_func @1
   my_func1 @2
   my_func2 @3
--------------------------

John's app won't work with the new dll unless he recompiles, since '@1'
isn't my_func1 anymore.

I'm not sure what controls whether an app links by the export name or by
the position number, so I try to allow both to work from version to
version of a given dll, by using an explicit def file. Just add new
functions to the end.

--Chuck


> 
> kulack@us.ibm.com wrote:
> >
> > I'm pretty new at Win and gcc development. I've been searching the archives
> > for details about this, but have only found hints.
> > I've followed the instrutions at
> > http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html for building
> > DLLs using GCC, but get a STATUS_ACCESS_VIOLATION when I attempt to use it.
> >
> > About my only guess is that I'm doing something wrong with the .DEF file.
> > Can it get created automatically or should there be a 'SECTIONS' section in
> > the .DEF file indicating which type of access (EXECUTE, READ, WRITE) the
> > dll should have?
> > Not familiar with nm output, but it seems to look ok for the created dll...
> > Can anyone teach me to fish? 8-)
> >
> > Bash /db2src/test
> >  > make libhello.a
> > gcc  -g -c -I/sqllib/include libhello.c
> > gcc -s -Wl,--base-file,libhello.base -o libhello.dll libhello.o
> > -Wl,-e,_mydll_init@12
> > dlltool --base-file libhello.base --def libhello.def --output-exp
> > libhello.exp --dllname libhello.dll
> > gcc -s -Wl,--base-file,libhello.base,libhello.exp -o libhello.dll
> > libhello.o -Wl,-e,_mydll_init@12
> > dlltool --base-file libhello.base --def libhello.def --output-exp
> > libhello.exp --dllname libhello.dll
> > gcc -Wl,libhello.exp -o libhello.dll libhello.o -Wl,-e,_mydll_init@12
> > dlltool --def libhello.def --dllname libhello.dll --output-lib libhello.a
> > cp libhello.dll ..
> > rm libhello.o
> >
> > Bash /db2src/test
> >  > make hello.exe
> > gcc  -g -c -I/sqllib/include hello.c
> > gcc  -g hello.o -L/db2src/test -lhello
> > mv a.exe hello.exe
> >
> > Bash /db2src/test
> >  > hello
> > Hello World
> >       0 [main] hello 1127 handle_exceptions: Exception:
> > STATUS_ACCESS_VIOLATION
> >    9205 [main] hello 1127 stackdump: Dumping stack trace to
> > hello.exe.stackdump
> >
> > Bash /db2src/test
> >  > cat hello.exe.stackdump
> > Exception: STATUS_ACCESS_VIOLATION at eip=000055CC
> > eax=00000009 ebx=00000000 ecx=0000000C edx=0245FDF4 esi=00000000
> > edi=0A041448
> > ebp=0245FE74 esp=0245FE58 program=c:\db2src\test\hello.exe
> > cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> > Stack trace:
> > Frame     Function  Args
> > 0245FE74  00401085  (00000009, 0245FEB0, 0245FEA4, 0040106B)
> > 0245FEA4  00401085  (00000001, 0A041448, 0A040008, 00000000)
> > 0245FF00  610022E5  (7FFDF000, 00000000, 00000018, 80452662)
> > 0245FF60  61002735  (00403010, 00000000, 0245FF90, 004011DA)
> > 0245FF90  004011E7  (00401060, FFFFFFFF, 80430B27, 00000000)
> > 0245FFC0  0040103B  (00000018, 00000000, 7FFDF000, 00000000)
> > 0245FFF0  77E87903  (00401000, 00000000, 000000C8, 00000100)
> > End of stack trace
> >
> > ======= libhello.c
> > #include <stdio.h>
> > #include <windows.h>
> > extern int helloFromDll(int parm);
> >
> > int WINAPI
> > mydll_init(HANDLE h, DWORD reason, void *foo)
> > {
> >    return 1;
> > }
> >
> > int helloFromDll(int parm) {
> >    printf("Hello from Dll, parm=%d\n", parm);
> >    return parm+1;
> > }
> >
> > int main(int argc, char **argv) {
> >    // This doesn't feel right...
> >    // Was forced to add main() in order to get the
> >    // instructions for building DLLs at
> >    //   http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html
> >    // to work correctly, otherwise, linker failed to
> >    // find WinMain@16 (which I wouldn't have believed it should
> >    // require).
> > }
> >
> > ======= libhello.def
> > LIBRARY LIBHELLO
> > DESCRIPTION 'LIBHELLO.DLL Testcase'
> > EXPORTS
> >    helloFromDll
> >
> > ======= hello.c
> > #include <stdio.h>
> > extern int helloFromDll(int parm);
> > int main(int argc, char **argv)
> > {
> >    int         rc;
> >    printf("Hello World\n");
> >    rc = helloFromDll(9);
> >    printf("DLL returned %d\n", rc);
> >    return 0;
> > }
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
  2000-06-15 16:17   ` Charles Wilson
@ 2000-06-15 16:39     ` Carl Thompson
  2000-06-15 17:00       ` Charles Wilson
  0 siblings, 1 reply; 8+ messages in thread
From: Carl Thompson @ 2000-06-15 16:39 UTC (permalink / raw)
  To: Charles Wilson; +Cc: Cygwin List

Charles Wilson wrote:

> ...

> You probably *should* use def files if (a) you're developing a library
> that other folks might want to use, without recompiling their
> application code, and (b) you want to support those apps that
> 'import-by-number' from the dll. With the no-def-file method, you're
> never guaranteed that the name/numbers will be the same from build to
> build.

I understand what you are saying, but if developers are using my headers and
my import library to link with my DLL, wouldn't they always be importing by
name?  I don't know anything about the import by number method.  Why is it
ever used?  How is it used?  More info, please...

Anyway, I hope at least the information in my message about the alternate
way to build DLLs helped you.

> --Chuck

Carl Thompson

> ...

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
  2000-06-15 16:39     ` Carl Thompson
@ 2000-06-15 17:00       ` Charles Wilson
  0 siblings, 0 replies; 8+ messages in thread
From: Charles Wilson @ 2000-06-15 17:00 UTC (permalink / raw)
  To: Carl Thompson; +Cc: Cygwin List

Carl Thompson wrote:
> 
> Charles Wilson wrote:
> 
> > ...
> 
> > You probably *should* use def files if (a) you're developing a library
> > that other folks might want to use, without recompiling their
> > application code, and (b) you want to support those apps that
> > 'import-by-number' from the dll. With the no-def-file method, you're
> > never guaranteed that the name/numbers will be the same from build to
> > build.
> 
> I understand what you are saying, but if developers are using my headers and
> my import library to link with my DLL, wouldn't they always be importing by
> name?  I don't know anything about the import by number method.  Why is it
> ever used?  How is it used?  More info, please...

I'm not really clear on the details -- I was reading the
libpng-developers mailing list and they were discussing the relative
merits of def-files, harvesting function names, 'export ordinals' and
'implicit' (by-number) linking. See
ftp://swrinde.nde.swri.edu/pub/png-group/archives/png-implement.0005

> 
> Anyway, I hope at least the information in my message about the alternate
> way to build DLLs helped you.

Sure -- more information is always good.

--Chuck

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
  2000-06-15 15:40 ` Carl Thompson
  2000-06-15 16:17   ` Charles Wilson
@ 2000-06-15 23:13   ` Heinz-Juergen Oertel
  1 sibling, 0 replies; 8+ messages in thread
From: Heinz-Juergen Oertel @ 2000-06-15 23:13 UTC (permalink / raw)
  To: Carl Thompson; +Cc: Cygwin List

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

Carl Thompson wrote:
> 
> I wrote a message to the list the other day about a much easier way to
> create DLLs using Cygwin than using dlltool, dllhelpers and .def files.  You
> can see it at
> 
>    http://sourceware.cygnus.com/ml/cygwin/2000-06/msg00688.html
> 

I have used it as a first try to write a DLL.
It does work for Cygwin apps  using Cygwin DLLs,

--- many thanks for the instructions. ---

What else is needed the same easy way to link a Cygwin app against a Microsoft,
e.g. VC or Borland created DLL, without having a .def or import library.
Doing more with LINUX every time its difficult to understand why there are so
much differences and difficulties. 

-- 
with best regards / mit freundlichen Grüßen

   Heinz-Jürgen Oertel

===========================================
Heinz-Jürgen Oertel
port GmbH            phone +49 345 77755-0
Regensburger Str. 7c fax   +49 345 77755-20
D-06132 Halle/Saale  mailto:oe@port.de
Germany              http://www.port.de
===========================================


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Can't build a DLL using gcc
@ 2000-06-16 14:51 kulack
  0 siblings, 0 replies; 8+ messages in thread
From: kulack @ 2000-06-16 14:51 UTC (permalink / raw)
  To: Cygwin List

Thanks Carl,
This solved my problem wonderfully, and your presentation of it was exactly
the type of
'hello world' that lets people be most productive!

I don't need (and can't conceive that I will need) to manage the order of
my DLL exports, but I've
kept the .DEF / export ordinality discussion in mind. Thanks again!

>   http://sourceware.cygnus.com/ml/cygwin/2000-06/msg00688.html
> This method is not only easier, but also allows you to maintain your
symbol
> information in one place-- the header files where they belong.  You don't
> have to try to keep separate .def files in sync.




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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Can't build a DLL using gcc
@ 2000-06-15 17:21 Eric Feliu
  0 siblings, 0 replies; 8+ messages in thread
From: Eric Feliu @ 2000-06-15 17:21 UTC (permalink / raw)
  To: 'kulack@us.ibm.com', cygwin

You know when I first used cygwin to build dll's I tried using that default cygwin
FAQ you lised below and had similar problems. I think the problem with that thing is
that it is outdated as hell. Mummit Khan has samples on his web page of makefiles
that will build a good DLL with little work on your part. Here is the one I have used:

#
# Makefile for Cygwin in -mno-cygwin mode. This builds a DLL that is
# independent of Cygwin DLL and only depends on MS CRTDLL runtime.
#
# If you want to use Mingw32 gcc, then use the makeit.bat file instead.
#
CC = gcc

# The root directory for mingw-extra package. You can get this package
# from the same place where you downloaded egcs-1.1.2-cygb20 from.
# You should also read the -mno-cygwin howto available from:
#  http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
#
MINGW_EXTRA_ROOT = /usr/local/mingw-extra
MINGW_INCLUDES = -I$(MINGW_EXTRA_ROOT)/include
MINGW_LIBDIRS = -I$(MINGW_EXTRA_ROOT)/lib

DEBUG = -g -O2
# The -mrtd flag tells the compiler to use the PASCAL or "stdcall" calling
# convention required by VBA/Excel/etc.
CFLAGS = -mrtd $(DEBUG)
CPPFLAGS = $(MINGW_INCLUDES)

AS = as
DLLTOOL = dlltool
DLLWRAP = dllwrap

#
# Various targets to build.
#
DLL_NAME = test.dll
DLL_EXP_DEF = test.def

all: $(DLL_NAME)

#
# sources, objects, etc. 
#
SRCS  = $(wildcard *.c)
OBJS := $(OBJS:.c=.o)

#
# DLL related variables. These are used when building the DLL. See later.
#

# any special flags that you need to pass to the F77 compiler when building 
# the DLL. (lots of software need _DLL defined).
DLL_CFLAGS = -DBUILDING_DLL=1
# This is where you pass linker flags, such as library search path, alternate
# entry point, etc. The -s flag strips the final DLL.
DLL_LDFLAGS = $(MINGW_LIBDIRS) -s -W1,-e,_cygwin_nocygwin_init@12
# any extra libraries that your DLL may depend on.
DLL_LDLIBS = 

#
# your sources etc that go into the DLL.
#
DLL_SRCS = test.c 
DLL_OBJS = test.o 

###
#
# Making DLL
#
###

#
# Note that we let dllwrap create both the DEF and IMPORT library in
# one shot. No need to run dlltool anymore.
#
DLLWRAP_FLAGS = --export-all --output-def $(DLL_EXP_DEF) \
	--target=i386-mingw32 -mno-cygwin \
	--driver-name $(CC)

$(DLL_NAME) $(DLL_EXP_DEF): $(DLL_OBJS)
	$(DLLWRAP) $(DLLWRAP_FLAGS) -o $(DLL_NAME) \
	    $(DLL_OBJS) $(DLL_LDFLAGS) $(DLL_LDLIBS)

#
# dependencies.
#

#fdll.o: fdll.c

test.o: test.c


#
# default rules for building DLL objects. Note that client programs (ie.,
# the ones that *use* the DLL) have to be compiled without the DLL_CFLAGS
# flags.
#
.c.o:
	$(CC) -c $(CPPFLAGS) $(DLL_CFLAGS) $(CFLAGS) -o $@ $<

clean:
	-rm -f $(OBJS) $(DLL_OBJS) $(DLL_NAME) $(DLL_EXP_DEF) 


Hope this helps, it sure helped me. 

Eric

-----Original Message-----
From:	kulack@us.ibm.com [SMTP:kulack@us.ibm.com]
Sent:	Thursday, June 15, 2000 5:12 PM
To:	cygwin@sourceware.cygnus.com
Subject:	Can't build a DLL using gcc

I'm pretty new at Win and gcc development. I've been searching the archives
for details about this, but have only found hints.
I've followed the instrutions at
http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html for building
DLLs using GCC, but get a STATUS_ACCESS_VIOLATION when I attempt to use it.

About my only guess is that I'm doing something wrong with the .DEF file.
Can it get created automatically or should there be a 'SECTIONS' section in
the .DEF file indicating which type of access (EXECUTE, READ, WRITE) the
dll should have?
Not familiar with nm output, but it seems to look ok for the created dll...
Can anyone teach me to fish? 8-)

Bash /db2src/test
 > make libhello.a
gcc  -g -c -I/sqllib/include libhello.c
gcc -s -Wl,--base-file,libhello.base -o libhello.dll libhello.o
-Wl,-e,_mydll_init@12
dlltool --base-file libhello.base --def libhello.def --output-exp
libhello.exp --dllname libhello.dll
gcc -s -Wl,--base-file,libhello.base,libhello.exp -o libhello.dll
libhello.o -Wl,-e,_mydll_init@12
dlltool --base-file libhello.base --def libhello.def --output-exp
libhello.exp --dllname libhello.dll
gcc -Wl,libhello.exp -o libhello.dll libhello.o -Wl,-e,_mydll_init@12
dlltool --def libhello.def --dllname libhello.dll --output-lib libhello.a
cp libhello.dll ..
rm libhello.o

Bash /db2src/test
 > make hello.exe
gcc  -g -c -I/sqllib/include hello.c
gcc  -g hello.o -L/db2src/test -lhello
mv a.exe hello.exe

Bash /db2src/test
 > hello
Hello World
      0 [main] hello 1127 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   9205 [main] hello 1127 stackdump: Dumping stack trace to
hello.exe.stackdump

Bash /db2src/test
 > cat hello.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=000055CC
eax=00000009 ebx=00000000 ecx=0000000C edx=0245FDF4 esi=00000000
edi=0A041448
ebp=0245FE74 esp=0245FE58 program=c:\db2src\test\hello.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0245FE74  00401085  (00000009, 0245FEB0, 0245FEA4, 0040106B)
0245FEA4  00401085  (00000001, 0A041448, 0A040008, 00000000)
0245FF00  610022E5  (7FFDF000, 00000000, 00000018, 80452662)
0245FF60  61002735  (00403010, 00000000, 0245FF90, 004011DA)
0245FF90  004011E7  (00401060, FFFFFFFF, 80430B27, 00000000)
0245FFC0  0040103B  (00000018, 00000000, 7FFDF000, 00000000)
0245FFF0  77E87903  (00401000, 00000000, 000000C8, 00000100)
End of stack trace

======= libhello.c
#include <stdio.h>
#include <windows.h>
extern int helloFromDll(int parm);

int WINAPI
mydll_init(HANDLE h, DWORD reason, void *foo)
{
   return 1;
}

int helloFromDll(int parm) {
   printf("Hello from Dll, parm=%d\n", parm);
   return parm+1;
}

int main(int argc, char **argv) {
   // This doesn't feel right...
   // Was forced to add main() in order to get the
   // instructions for building DLLs at
   //   http://sourceware.cygnus.com/cygwin/cygwin-ug-net/dll.html
   // to work correctly, otherwise, linker failed to
   // find WinMain@16 (which I wouldn't have believed it should
   // require).
}

======= libhello.def
LIBRARY LIBHELLO
DESCRIPTION 'LIBHELLO.DLL Testcase'
EXPORTS
   helloFromDll

======= hello.c
#include <stdio.h>
extern int helloFromDll(int parm);
int main(int argc, char **argv)
{
   int         rc;
   printf("Hello World\n");
   rc = helloFromDll(9);
   printf("DLL returned %d\n", rc);
   return 0;
}




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


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2000-06-16 14:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-15 14:12 Can't build a DLL using gcc kulack
2000-06-15 15:40 ` Carl Thompson
2000-06-15 16:17   ` Charles Wilson
2000-06-15 16:39     ` Carl Thompson
2000-06-15 17:00       ` Charles Wilson
2000-06-15 23:13   ` Heinz-Juergen Oertel
2000-06-15 17:21 Eric Feliu
2000-06-16 14:51 kulack

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).