Todd Vierling wrote:
> 
> On Thu, 22 Mar 2001, Nick Hudson wrote:
> 
> : > Oh yeah, I got the links and real library the wrong way round. What was
> : > I thinking!
> :
> : Actually no I didn't. I'm confusing myself...
> :
> : The real library is always the one with ${maj}.${min}[.${teeny}]
> : appended. libtool follows links and so your ELF pattern won't match.
> 
> Uh, that's annoying; I see the code block that uses ls(1) to resolve the
> symlinks.  And precisely why does it do that?  For a program which opens the
> file and examines its contents (such as file(1)), resolving the symlink
> shouldn't be necessary--and in this name-matching case, it's actually
> detrimental.

Hey, those libtool guys are certainly maintaining a curious beast.

A quick trawl through libtool.m4 reveals at least 4 instances of a file
command without a -L option and looking at SUSv2 it seems as though
there is no standard for such an option. So presumably they implemented
the link following for file in libtool.

> The problem with this is that the needed ELF symlink may not exist even
> though a library of the form libNAME.so.1.2.3 (note three components) does.
> I suppose, then, that the pattern could be made into a non-object-format
> dependent such as the following:
> 
>     {lt_cv_deplibs_check_method='file_magic /lib[^/\.]*\.so(\.[0-9]+)+$'}
> 
> Note the (\.[0-9]+)+$ ... this ensures that at least one version number
> component is present in the library it's trying to resolve.
> 
> : Are we heading towards a lt_cv_deplibs_check_method='match_pattern ...'
> : option for libtool?
> 
> Possibly, if you're in a position to implement it.  That's essentially what
> the file_magic_cmd='echo' does....

I'm looking for the best way to go here

	1) Make a change to file_magic so that it doesn't follow links unless
	   it's told to do so.
	2) Add a new option like match_pattern that does what
	   file_magic_cmd='echo' should do.

Maybe I should ask on the libtool lists...

Nick
-- 
aka skrll@netbsd.org, skrll@excite.co.uk