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

O. Hartmann ohartman at
Fri Nov 19 17:28:56 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!

Well, maybe here is a misunderstanding.
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?

More information about the freebsd-ports mailing list