Message-ID: <1331078014.61966.YahooMailNeo@web36701.mail.mud.yahoo.com>
Date: Tue, 6 Mar 2012 15:53:34 -0800 (PST)
From: cppjavaperl <cppjavaperl AT yahoo DOT com>
Reply-To: cppjavaperl <cppjavaperl AT yahoo DOT com>
Subject: Re: ldd fails when dll has no execute permissions
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit

> On Feb 24 12:56, Corinna Vinschen wrote:
>
> On Feb 23 15:03, cppjavaperl wrote:
> > This was discovered in cygwin-1.7.10-1.
> > 
> > If you run 'ldd' against an executable, and the executable has 
> > dependent DLLs which do *not* have execute permissions, ldd's output
> > stops when it reaches the offending dependent DLL, and reports no
> > further information.Ā ldd does not give an error message, and the exit
> > code is zero.
> 
> DLL's must have execute permissions to be loaded into the process.
> And that is what ldd does, it starts a process and inspects the 
> process memory to see what DLLs are loaded via the Win32 debug API.
> 
> The problem is that the Win32 loader stops loading as soon as it
> encounters the non-executable DLL.  So there will simply be no further
> LOAD_DLL_DEBUG_EVENT.  The next event is an EXIT_PROCESS_DEBUG_EVENT
> which means to ldd that it collected all DLLs and so it just prints
> the list of so far collected DLLs.
> 
> I don't see how this could be changed to behave differently in this
> case.
> 
> 
> Corinna
> 

Sorry I just got back to this topic.  After a little research, I found
this old link which discusses a similar type tool provided by Microsoft:

http://www.mail-archive.com/delphi AT delphi DOT org DOT nz/msg11393.html

After reading that thread, I downloaded the code from Microsofts ftp site
here:

ftp://ftp.microsoft.com/softlib/mslfiles/MSJFEB97.EXE

The code looks reasonable, and doesn't appear to be difficult at all to 
follow.  Running the executable in testing like I did with ldd gives
better results (IMHO).  It finds the dependent DLLs even if the executable
bit is not set, and it continues looking for DLLs when it can't find one,
while noting each DLL that can't be found.

Perhaps it would be good to use this sample code to make modifications
to ldd, so that it could give more accurate information.  I do not know
if there are any situations where the Microsoft sample code would 
provide inaccurate information, and perhaps there are situations I'm not 
aware of where the existing ldd code would work and the Microsoft code
would not.  However, it seems to me that the Microsoft code is worth
looking at -- in order to consider improving ldd.  The Microsoft code
doesn't appear to me to be restricted in any way that would hinder its use 
in ldd.

It seems to me that the ideal solution would list all the DLLs, 
noting which could not be found, and also giving a warning if a DLL
is not executable.  Perhaps that kind of solution could be achieved by
modifiying ldd using Microsoft's sample code as an example.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple