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

[O. Hartmann]

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