[haiku-development] Re: nomenclature : building shared libs
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 7 Mar 2009 06:48:17 +0000
On Sat, Mar 7, 2009 at 6:22 AM, Dustin Howett <alaricx@xxxxxxxxx> wrote:
> I believe that it's this way for linking concerns.
> Like, a program can depend specifically on X.a.b.c (only that version
> works, or so), or just a major version X, or any version of the
> library in general (no suffix.)... Thus, if the library gets upgraded,
> the X.a.b.c has changed and the more specifically-linked programs fail
> to load.
> Dealing with programs that link against the specific library version
> is a pain, in my experience.
>
> Not sure about them not matching though... They are meant to represent
> an ABI version at any given point in time.
>
I think /boot/common/share/aclocal/libtool.m4 is responsible for the
multiple filenames.
As a note, openssl, libxml, zlib are some of the few libs on my system
that properly names itself to libssl.so.0.9.8 or libxml2.so.2.7.3
cURL, expat, iconv, intltool-0.40.5, pcre, do not seem to use any
logical naming scheme.
comparing + contrasting the beos + haiku sections, particularly
libary_names_spec :
beos*)
library_names_spec='${libname}${shared_ext}'
dynamic_linker="$host_os ld.so"
shlibpath_var=LIBRARY_PATH
;;
haiku*)
version_type=linux
need_lib_prefix=no
need_version=no
dynamic_linker="$host_os runtime_loader"
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
hardcode_into_libs=yes
;;
Other related posts:
