Renaming a shared library in the port-framework to match FreeBSD naming schemes?

O. Hartmann ohartman at mail.zedat.fu-berlin.de
Mon Nov 22 20:20:19 UTC 2010


On 11/22/10 19:20, Andrew W. Nosenko wrote:
> On Fri, Nov 19, 2010 at 19:28, O. Hartmann
> <ohartman at mail.zedat.fu-berlin.de>  wrote:
>> On 11/19/10 18:11, Andrew W. Nosenko wrote:
>>>
>>> 2010/11/19 O. Hartmann<ohartman at zedat.fu-berlin.de>:
>>>>
>>>> On 11/19/10 13:46, Koop Mast wrote:
>>>>>
>>>>> On Fri, 19 Nov 2010 12:32:33 +0100
>>>>> "O. Hartmann"<ohartman at zedat.fu-berlin.de>      wrote:
>>>>>
>>>>>> Hello.
>>>>>> Trying to do my first port and run into trouble.
>>>>>> The software package (Xerces-c 3.1.1) comes with a full autotoll
>>>>>> environment and so far building and installing works.
>>>>>>
>>>>>> But the libarary name is "libxerces-c-3.1.so" and I need to change this
>>>>>> to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm
>>>>>> looking for a way avoiding some "post-install:" stuff.
>>>>>
>>>>> There isn't any problem with the libxerces-c-3.1.so name.
>>>>>   From http://www.freebsd.org/doc/en/books/porters-handbook/special.html
>>>>> Try to keep shared library version numbers in the libfoo.so.0 format.
>>>>> Our runtime linker only cares for the major (first) number.
>>>>
>>>> Well, this is the problem. The automated installation process installes
>>>> libxerces-c-3.1.so.
>>>
>>> This not a problem.  Inability to catch the libxerces-c-3.1.so by
>>> specifying -lxerces-c linker flag (and enforce you to specify
>>> -lxerces-c-3.1) is intended and desired effect.  Please, don't touch
>>> the library name.
>>>
>>> Usually, authors change library name if want to ensure and express
>>> complete API and ABI break without any forward and backward
>>> compatibility.  Like switch from Glib-1.x (libglib.so.x) to Glib-2.x
>>> (libglib-2.0.so.x).  In both your (libxerces) and my (libglib)
>>> examples the authors desired to use "interface generation" numbers,
>>> but it just for aesthetics reasons, indeed the libraries could be
>>> renamed to any other arbitrary way (for example, libNewGlib.so and
>>> libEvenBetterXerces.so -- ideologically and technically there no
>>> differences).
>>>
>>> If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all
>>> application that want and expect the old "zero-generation" API and
>>> link against '-llibxerces-c' will fail because will catch absolutely
>>> unexpected (by them) and incompatible libxerces-c-3.1 API.
>>>
>>> Applications that indeed want and expect libxerces-c-3.1 API, and
>>> therefore that links with '-llibxerces-c-3.1' will fail also.  Just
>>> because there no more libxerces-c-3.1.so library -- it was renamed to
>>> unexpected name w/o good reasons.
>>>
>>> Conclusion: Please, don't touch library names!
>>>
>>
>> Well, maybe here is a misunderstanding.
>
> Sure.  See below.
>
>> I'd like to come along with FreeBSD's library naming scheme when installing
>> the library into /usr/local/lib. I thought manipulating the
>> source-environment when compiling would be the least-efford way, but I see,
>> maybe it would be easier to come along with a post-install: target by simply
>> moving and making a symbolic link. If so, I need to detect by the framework
>> what the lib vendor has choosen as thi lib name, to automate the proceed
>> perfectly. Is this possible?
>>
>
> Seems, like you think that Xerces authors use libNAME-VER.so naming
> scheme, while FreeBSD uses libNAME.so.VER ...

Well, after building a vanilla xerces-c version 3.1.1 and checked the 
vendor's point of view how the lib should be named, I guess my thinking 
is right about libNAME-VER.so. Simply try download and compile/install 
the sources from http://xerces.apache.org/xerces-c/.

>
> Ineed it's simple not true.  Both uses libNAME.so[.VER].

I doubt this, or I do something stupid everytime again and again.

> Usually, libNAME.so.VER with greatest VER symlinked to libNAME.so.
> How VER represented (it just a number, or more complicated like .N,
> .N.M., .N.M.K... -- depends on the ld.so implementation on the target
> system and usually should not bother you as software author (if you
> use Libtool, which is good in job of hiding differences between
> systems in that respect).
>
> Also, these .N[.M[.K]] represent the ABI version of library and has
> nothing with package version.
>
> Just in the case of Xerces, the NAME contains digits that looks like
> version (version of package).  But indeed, the NAME in your case _is_
> "libxerces-c-3.1".  I unable to say what ABI version VER is without
> building Xerces-C, or upstream authors decided to left it empty
> indeed, sorry.
>


The new xerces-c 3.1.1 comes with a whole/complete 
autotools-environment. There is a m4-folder containing libtool.m4. I 
tried to patch this in the section "freebsd-elf*" and "freebsd-*" to 
reflect the naming scheme FreeBSD uses (libNAME.so.VER). I tried several 
variations, but it seems that something from the ports toplevel Makefile 
isn't triggering a reconfiguration the right way.

I did the same with the toplevel ./configure file which already contains 
the libtool.m4-macro substitutions, but again, it doesn't seem to be 
possible to change the libname that gets installed.

I tried forcing triggering a aclocal/autoconf procedure via 
USE_AUTOTOOLS= butthis results surprisingly in a linker error.

My intention is to manipulate the installed library and the symbolic 
link that way that it is clean in the sense of low complication 
post-install manipulations.

xerces-c and xerces-c2 are already in the ports collection and I need a 
collision-free xerces-c3, so renaming the installed library is important.

I thought I could pass some environment variables to the autotool 
environment when building via a port's top level Makefile, but this 
seems to be impossible.


More information about the freebsd-ports mailing list