Mail Archives: cygwin/2012/03/06/20:52:15
On Tue, Mar 06, 2012 at 03:53:34PM -0800, cppjavaperl wrote:
>> 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.
ldd.exe is not going to change. ldd on linux is also unable to display
dependencies unless the thing being checked has executable permissions.
--
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
- Raw text -