Mail Archives: cygwin/2006/08/04/18:04:45
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/
- Raw text -