Re: lib-link.m4 on OpenBSD or MirBSD

[Bruno Haible]

Hello,

Benny Siegert wrote:
> I have a question regarding the lib-link.m4 macro collection provided
> by newer GNU gettext versions. First, correct me if I am wrong, but
> from what I gathered, the macros work like this: they get some
> variables, like $shlibext, from config.rpath; then they look at
> whether lib$name.$shlibext, lib$name.la or lib$name.a exist _as
> regular files_ and link directly against the found filename.

This is essentially how it works, yes.

The files lib$name.$shlibext, lib$name.la, lib$name.a may also be
symbolic links. lib-link.m4 uses "test -f", which accepts symbolic links
just like regular files.

> Has any of this been tested on OpenBSD or MirBSD? At least if the
> package is not using libtool (as bash-4.1 is) and relies on the .so,
> this approach is fundamentally wrong on these operating systems.
> 
> On OpenBSD and MirOS (where shlibext=so), shared libraries either have
> the .so extension (if they do not carry a version) or a
> .so.$major.$minor _without_ symlinks. For example, MirOS-current has:
> 
> $ ls /usr/lib/libc.*
> /usr/lib/libc.a        /usr/lib/libc.so.41.9

lib-link.m4 takes this into account: On OpenBSD, the config.rpath will
set
    library_names_spec='$libname$shrext$versuffix'
and lib-link.m4 will then execute this piece of code when searching for
an installed library:

                  ver=`(cd "$dir" && \
                        for f in "$libname$shrext".*; do echo "$f"; done \
                        | sed -e "s,^$libname$shrext\\\\.,," \
                        | sort -t '.' -n -r -k1,1 -k2,2 -k3,3 -k4,4 -k5,5 \
                        | sed 1q ) 2>/dev/null`
                  if test -n "$ver" && test -f "$dir/$libname$shrext.$ver"; then
                    found_dir="$dir"
                    found_so="$dir/$libname$shrext.$ver"
                  fi

This has been tested on OpenBSD when this support was added on 2007-01-02.

If this does not work for you on MirBSD, the reason is probably that libtool.m4
(from which config.rpath is derived) tests for
    openbsd*
but not for
    mirbsd*
If you wish this to work, first someone needs to submit MirBSD support for
libtool.

> You would have to glob for a
> name matching the pattern and select the one with the largest major
> and/or minor.

Yes, this is what lib-link.m4 does.

> Or, which would be the preferred approach, you could do 
> something like AC_TRY_LINK with "-L$libdir -l$libname" as additional
> LDFLAGS. In this case, the linker does the above for you.

But this doesn't tell us whether we really need the particular -L option.
Adding too many -L options makes a build more complicated, therefore we
want to add it only when it has a positive effect.

Bruno
-- 
In memoriam Giordano Bruno <http://en.wikipedia.org/wiki/Giordano_Bruno>