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
Message-Id:	<199905090345.WAA28374@modi.xraylith.wisc.edu>
X-Authentication-Warning:	modi.xraylith.wisc.edu: localhost.xraylith.wisc.edu [127.0.0.1] didn't use HELO protocol
To:	Paul Thiessen <paul AT grserv DOT med DOT jhmi DOT edu>
cc:	cygwin AT sourceware DOT cygnus DOT com
Subject:	Re: troubles w/ dll building and crtdll-vs-msvcrt
In-reply-to:	Your message of "Sat, 08 May 1999 20:24:00 EDT."
	<Pine DOT SGI DOT 4 DOT 10 DOT 9905081953210 DOT 69532-100000 AT turandot DOT med DOT jhmi DOT edu>
Date:	Sat, 08 May 1999 22:45:23 -0500
From:	Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

Paul Thiessen <paul AT grserv DOT med DOT jhmi DOT edu> writes:
> 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.

btw, I do appreciate your reports, even if you do sound like a broken
record ;-).

>   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:

Just after I sent the last note saying there shouldn't be any problems
with the current scheme, I found out I was wrong! Programs keep on dying
die under gdb, and till your report, I had no idea why. Thanks.

At the risk of sounding like a broken record, it is fixed for egcs-1.2.

For those using msvcrt runtime add-on, I'll upload new drivers (g++/c++
and g77) sometime next week so you won't need the workaround anymore.

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

If you specify '-v' when linking (either via gcc/c++/g77 or dllwrap),
you'll see if -lcrtdll is being specified or not. You'll see that g++
and g77 do this no matter what since it's compiled in.

Regards,
Mumit


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

- Raw text -