This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.21-1 DLL Loading Problem


Hi Rob...

I got...

$ ./run
Foundation load failed: Permission denied

HTH,

...Karl


From: Rob Hatcherson Subject: Re: 1.5.21-1 DLL Loading Problem
Date: Wed, 02 Aug 2006 16:14:41 -0500

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



<< testcase1.tgz >>


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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]