This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 1.5.21-1 DLL Loading Problem
- From: Rob Hatcherson <rob dot hatcherson at zedasoft dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 02 Aug 2006 16:14:41 -0500
- Subject: Re: 1.5.21-1 DLL Loading Problem
- References: <44C6B776.2080600@zedasoft.com> <44C6DCA2.1000709@cygwin.com> <44C7F4B8.50707@zedasoft.com>
All:
This is a follow-up to a couple of posts I made 7/25,7/26/2006 regarding
DLL loading issues. cygcheck output was attached to the first of my two
posts. The cause of the problem in its original incarnation is still
undetermined, as it all seems to be happening upstream of main() where
things are slightly harder to nail down.
I tried pushing the issue downstream of main() by loading one of the
questionable DLLs directly via dlopen(). This also failed, so I pared
it down to something small that still fails consistently (testcase1.tgz,
attached). While this isn't exactly the form of the problem I
originally described, it's still DLL related, and the behavior is similar.
As indicated in my original post, this problem appears possibly related
to previously reported DLL loading issues. But... those are supposed to
be fixed in 1.5.21-1.
I've run this app on two XP boxes and one Win2K box with the 1.5.21-1
cygwin1.dll, and all failed with dlerror() reporting "permission
denied". FWIW on two of the machines I tried the 1.5.18-1 cygwin1.dll
(same compiler version), and it always worked.
At first glance it would seem that "permission denied" is pointing to
the issue, but simple (and irrational) changes to the source cause the
problem to morph. For example, commenting out the #include of
ReleasePool.h in Object.cpp - which isn't strictly required in the test
case Object.cpp but was a leftover from the paring down process - caused
the failure to be reported as "bad address". Commenting out other
things, such as some of the static fields in the Object and/or
ReleasePool classes, or the #include's in Object.h, permit dlopen() to
load the DLL successfully. Also, removing the -g from CXXFLAGS results
in a build that works. There are other variations.
At this point I'm looking for volunteers with the same cygwin/g++/etc...
versions to try to build and run this, to see if the failure is
consistent, or if we just happen to have a pile of confused machines at
our office. To run a) untar testcase1.tgz somewhere, b) make, c)
./run. It will either say the DLL loaded OK, or give a reason why it
didn't.
Note that I have *not* yet tried gcc 3.4.4-2 as suggested earlier by
Dave Korn. I'll try to get to that shortly. Have also not yet tried
the current nightly build.
For any of you who have a moment to help, feel free to my private email
if you prefer and I will be glad to summarize any findings in a future
post to keep the chatter on the list down.
TIA for any help.
Rob
Attachment:
testcase1.tgz
Description: Unix tar archive
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/