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

Andrew W. Nosenko andrew.w.nosenko at
Tue Nov 23 01:14:59 UTC 2010

On Mon, Nov 22, 2010 at 22:20, O. Hartmann
<ohartman at> wrote:
> On 11/22/10 19:20, Andrew W. Nosenko wrote:
>> On Fri, Nov 19, 2010 at 19:28, O. Hartmann
>> <ohartman at>  wrote:
>>> On 11/19/10 18:11, Andrew W. Nosenko wrote:
>>>> 2010/11/19 O. Hartmann<ohartman at>:
>>>>> On 11/19/10 13:46, Koop Mast wrote:
>>>>>> On Fri, 19 Nov 2010 12:32:33 +0100
>>>>>> "O. Hartmann"<ohartman at>      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 "" and I need to change
>>>>>>> this
>>>>>>> to respect the FreeBSD nameing schemes to "". I'm
>>>>>>> looking for a way avoiding some "post-install:" stuff.
>>>>>> There isn't any problem with the name.
>>>>>>  From
>>>>>> Try to keep shared library version numbers in the format.
>>>>>> Our runtime linker only cares for the major (first) number.
>>>>> Well, this is the problem. The automated installation process installes
>>>> This not a problem.  Inability to catch the 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 ( to Glib-2.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, and
>>>> -- ideologically and technically there no
>>>> differences).
>>>> If you rename to, 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 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 naming
>> scheme, while FreeBSD uses ...
> 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 Simply try download and compile/install the
> sources from
>> Ineed it's simple not true.  Both uses[.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).

>> Usually, with greatest VER symlinked to
>> How VER represented (it just a number, or more complicated like .N,
>> .N.M., .N.M.K... -- depends on the 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 ( 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

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 see three variants:
(1) simple: just mark these ports (c2 and c3) as conflicting,
(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.
(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 (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).
 But ATM I see no better way to allow parallel installation of the
packages that aren't intended for parallel installation by theirs

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

Andrew W. Nosenko <andrew.w.nosenko at>

More information about the freebsd-ports mailing list