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

[O. Hartmann]

On 11/23/10 02:14, Andrew W. Nosenko wrote:
> On Mon, Nov 22, 2010 at 22:20, O. Hartmann
> <ohartman at mail.zedat.fu-berlin.de>  wrote:
>> 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.
>
> Yes.  You mess the package version (3.1 oe 3.1.1 in your case) with
> the ABI version (.0 or empty, in this case AFAIU).

Well, I just compare to xerces-c.so.27 or xerces-c.so.28 
(xerces-c2-devel). Both libraries get installed according to the 
FreeBSD's library naming policy. I do not find any library that is apart 
from this naming policy in my boxes /usr/local/lib. Old xerces-c ports 
seem to have some kind of home-brewn build environment, so GNU autotools 
do not apply and it seems to be easier to come along with the naming 
policy which is introduced for FreeBSD's libraries.

>
>>
>>> 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
>
> Simple don't touch and you will comply!  The NAME part here is
> "xerces-c-3.1".  Not NAME="xerces-c" and VER="3.1" but
> NAME="xerces-c-3.1" and VER is empty.
>
> Again: "3.1" is the part of NAME!
>
>> 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.
>
> Again: just don't touch the library name and you will collision free
> from the library names point of view: xerces-c2 has no
> libxerces-c-3.1.so.
>
> But there lives another problem: Xerces people doesn't expect parallel
> installation of the "evelopment" part of Xerces-C (headers,
> pkg-config, etc).  At least it seems so by listing the libxerces-c
> package from Ubuntu.

I guess so, but some ports of the FreeBSD ports (i.e. textproc/xalan-c) 
want xerces-c2 (which is 2.7.0). I try build xalan-c with the new 
xerces-c3 and see if it can handle the new header and libraries.

>
> I see three variants:
> (1) simple: just mark these ports (c2 and c3) as conflicting,

... in my testcase I did.

> (2) semi-simple: split each xerces-c port at the two: run-time and
> development.  Runtime contains a shered library, development contains
> anything other.  Mark development parts as conflictitng.

... well, in such a case we converge much to the weird Linux mess, I guess.

> (3) move each port away from each other's way: move headers into own
> versioned deirectory (e.g. from include/xercesc/ to
> insclude/xercesc-3.1/xercesc/), drop libxerces-c.so (if any -- I don't
> know), rename pkg-config (.pc) file, and static library (if any), may
> be something yet another, like documentation -- need to look at the
> actual install.  All these changes hidden from the users through
> pkg-config's .pc, therefore only one problem for developers will be
> changed (non-standard name of the .pc file, i.e. pkg-config's module).

... this would bring up other complications for ports expecting libs and 
headers at places where the solo installation normally resides.

>   But ATM I see no better way to allow parallel installation of the
> packages that aren't intended for parallel installation by theirs
> authors...

I tend to install it as a unique port with conflicts activated. Hope 
there are no further conflicts other than xalan-c.

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