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

O. Hartmann ohartman at
Mon Nov 22 13:54:23 UTC 2010

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!

Sorry, if I bother you again.
So, just in case when leaving the vendor intended library naming and 
forget about the FreeBSD paradigm of naming the library, as far as I see from your mail it would be more 
convenient having a port textproc/xerces-c3 with the library

In such a case, I guess I need some advisor/revisioner to look after the 
small Makefile for the port I wrote to push it into the ports collection.

Because libxerces-c2 and libxerces-c3 seem to break the API, it is 
obviously a good advice haveing a new generation port.


More information about the freebsd-ports mailing list