[Top][All Lists]

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

lib-link.m4 on OpenBSD or MirBSD

From: Benny Siegert
Subject: lib-link.m4 on OpenBSD or MirBSD
Date: Tue, 15 Feb 2011 18:13:22 +0100


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.

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

With the current lib-link.m4, only the .a is found, so the program is
linked against static libraries. Worse, I don't see an easy way to
handle this case using the existing code. You would have to glob for a
name matching the pattern and select the one with the largest major
and/or minor. 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.

Any idea on how to fix this now? I do not understand the code enough
to patch this. Help would be very much appreciated.


The first essential in chemistry is that you should perform practical
work and conduct experiments, for he who performs not practical work
nor makes experiments will never attain the least degree of mastery.
        -- Abu Musa Jabir ibn Hayyan (721-815)

reply via email to

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