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.

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....

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/