Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Date:	Sat, 8 May 1999 20:24:00 -0400
From:	Paul Thiessen <paul AT grserv DOT med DOT jhmi DOT edu>
X-Sender:	paul AT turandot DOT med DOT jhmi DOT edu
To:	cygwin AT sourceware DOT cygnus DOT com
Subject:	troubles w/ dll building and crtdll-vs-msvcrt
Message-ID:	<Pine.SGI.4.10.9905081953210.69532-100000@turandot.med.jhmi.edu>
MIME-Version:	1.0

Yes, sorry to be a broken record... another post about this - I'm still
getting page faults when loading in a dll I've built myself, and am trying
to track down the problem.
  I'm using mingw32/egcs. For an example, take Mumit's "dllhelper" sample
dll build for c++. Using the provided makefile, "make" gives the following 
output:

c++ -c -DBUILDING_DLL=1 -I. -g  -o dllclass.o dllclass.cc
c++ -c -DBUILDING_DLL=1 -I. -g  -o dllexterns.o dllexterns.cc
gcc -c -DBUILDING_DLL=1 -I. -g  -o dllinit.o dllinit.c
dllwrap --export-all --output-def cxxdll.def --implib libcxxdll.a\
	--driver-name c++ -o cxxdll.dll \
    dllclass.o dllexterns.o dllinit.o
Warning: no export definition file provided
dllwrap will create one, but may not be what you want
c++ -c -I. -g  -o usedll.o usedll.cc
c++ -o usedll.exe -g   usedll.o -L./ -lcxxdll

When I run the program, usedll.exe gives correct output. However, when I
try to run it in gdb, I get a segmentation fault:

c++> gdb usedll
GNU gdb 4.17.1 (... + welcome message)
(gdb) run
run
Starting program: D:\dllhelpers-0.2.5\c++/usedll.exe
7fd50000:C:\WINDOWS\SYSTEM\CRTDLL.DLL
bff70000:C:\WINDOWS\SYSTEM\KERNEL32.DLL
78000000:C:\WINDOWS\SYSTEM\MSVCRT.DLL
67480000:D:\DLLHELPERS-0.2.5\C++\CXXDLL.DLL

Program received signal SIGSEGV, Segmentation fault.
0x78008484 in <bad string table offset> ()
(gdb)

Then, when I follow Mumit's advice about how to prevent linking with
crtdll.dll, and do the final program linking with gcc instead of c++, it
goes through okay:

c++> make
gcc -o usedll.exe -g   usedll.o -L./ -lcxxdll -lstdc++
c++> gdb usedll
GNU gdb 4.17.1  (... welcome message)
(gdb) run
run
Starting program: D:\dllhelpers-0.2.5\c++/usedll.exe
bff70000:C:\WINDOWS\SYSTEM\KERNEL32.DLL
78000000:C:\WINDOWS\SYSTEM\MSVCRT.DLL
67480000:D:\DLLHELPERS-0.2.5\C++\CXXDLL.DLL
Global integer variable = 5
DllClass 1 (Imported from DLL):
  virtual_method = 1
  non_virtual_method = 1
  instances = 2
DllClass 2 (Imported from DLL):
  virtual_method = 8
  non_virtual_method = 4
  instances = 2
DllClass (Local):
  virtual_method = 27
  non_virtual_method = 9
  instances = 3

Program exited normally.
(gdb)


I'm not sure what all this means - whether the problem is with gdb or
something more subtle. But I have a more complicated dll (made out of the
togl opengl-to-tcl-widget program) that I'm trying to link into a program
with the same dll building technique. If I just use the togl.o file linked
statically, all is fine, but once I try to use the togl.dll I built, I
just get page faults (win95 claims in msvcrt.dll) at runtime, no matter
how I do the program linking. crtdll.dll is still being linked in,
possibly because other libraries I need depend on it.
  I don't know exactly what I'm asking - I guess I still don't fully
understand the dll building process, and perhaps all this is fixed in egcs
1.2... Oh well.

 - Paul

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  Paul A.   |      paul AT grserv DOT med DOT jhmi DOT edu      |  Johns Hopkins
 Thiessen   |  http://grserv.med.jhmi.edu/~paul  |   University
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -