This is the mail archive of the cygwin@sourceware.cygnus.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
Re: ANNOUNCE: cygwin `ldd' script
- To: cygwin@sourceware.cygnus.com
- Subject: Re: ANNOUNCE: cygwin `ldd' script
- From: Eugene Kanter <eugene@bgs.com>
- Date: Wed, 21 Apr 1999 16:55:58 -0400
- References: <Pine.SUN.3.93.981209163956.6180E-100000@modi.xraylith.wisc.edu> <366FF20A.65BB0922@oranda.demon.co.uk>
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