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/
