ANNOUNCE: cygwin `ldd' script

Wed Apr 21 13:52:00 GMT 1999

I found a bug (duplicate names have been printed) in the script and
fixed it. See attached. Anyone care to optimize "for" loops or to write
a C program? Script is painfully slow, however does the job surprisingly
well. Good work, Gary!
Eugene.
"Gary V. Vaughan" wrote:
>> Attached is an all singing, all dancing ldd-a-like for cygwin. Do with
> it what you will, perhaps add it to the ftp.franken.de repository?
>> I might convert some more of the functionality from cygcheck in a few
> weeks, once I have libtool fixed to build dlls.
>> Thanks again Mumit for the response:
>> Mumit Khan wrote:
> >
> > On Wed, 9 Dec 1998, Gary V. Vaughan wrote:
> >
> > > Ahh.. I didn't know dll's could depend on one another. Are these
> > > dependencies encoded into the dependee by cygwin's ld at linktime?
> >
> > It's the same as on other Unix systems, where shared libraries can
> > have dependencies as well (the win32 dll architecture is of various
> > quite different from the various flavors of Unix shlibs, but it's the
> > same basic idea).
>> I see. It appears (by experiment!) that the final link of win32 dll
> does indeed list the other link-time dlls in the .idata section of the
> resulting library. Dll's are less brain-damaged than I had thought
> after all =)O|
>> > Few comments
> >
> > - absolute pathname may not work as is (eg., ``ldd /bin/sh.exe'')
>> You're right. Fixed in the attached version.
>> > - You do need to sort out duplicates
>> Right again. I fixed this too.
>> > - the path search is confusing. for example, let's say I have a file
> > called foo.exe in my current working directory (which is not in my
> > path), and a file called foo.exe in my PATH. Now if I do:
> >
> > $ ldd foo.exe
> >
> > it picks up the one in the PATH instead of the one in the current
> > directory!
>> I think this is how it should work. In the circumstance you describe
> above, if I typed `foo.exe' to my bash prompt, I would expect the
> foo.exe found in my $PATH to run.
>> I have changed the dll lookup (after an exe is found) to look in the
> executables directory, the current working directory and then to search
> the PATH. Despite what I said about choosing an executable file to
> run, I assume the win32 runtime loader will search for dlls as you
> describe, regardless of the shell being used.
>> > Hope I read the algorithm correctly -- don't have a windows
> > machine to test it out.
>> Yup, fine. It is a little clearer in the new version I hope =)O|
>> > You *may* need to extend the search path to include the default
> > search path for win32 DLLs (different for win9x and NT), including
> > the directory containing executable as well as the current working
> > directory.
>> How do I find what these are? I have /WINNT/System32 and /WINNT put in
> my path by either bash or the NT kernel... are these the directories you
> mean?
>> > Regards,
> > Mumit
>> Many thanks for taking the time to look at this. I hope to roll this
> (and the rest of the required bits) into CVS libtool in the next week or
> two -- with luck libtool-1.3 should be able to build dll's when it is
> released [RSN =)O|]
>> Cheers,
> Gary.
>ldd.sh
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com