[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lib-link.m4 on OpenBSD or MirBSD

From: Bruno Haible
Subject: Re: lib-link.m4 on OpenBSD or MirBSD
Date: Fri, 18 Feb 2011 01:45:00 +0100
User-agent: KMail/1.9.9


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

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
but not for
If you wish this to work, first someone needs to submit MirBSD support for

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]