Date: Fri, 19 Nov 2010 18:28:53 +0100 From: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> To: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> Cc: Koop Mast <kwm@rainbow-runner.nl>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, freebsd-ports@freebsd.org Subject: Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes? Message-ID: <4CE6B3D5.5040101@mail.zedat.fu-berlin.de> In-Reply-To: <AANLkTimHsAqRBndpqLvuL7GC-Hiu4o85dtTJfZky0%2BO-@mail.gmail.com> References: <4CE66051.7000600@zedat.fu-berlin.de> <20101119134636.2c5f44cc@headache.rainbow-runner.nl> <4CE683D1.1020300@zedat.fu-berlin.de> <AANLkTimHsAqRBndpqLvuL7GC-Hiu4o85dtTJfZky0%2BO-@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/19/10 18:11, Andrew W. Nosenko wrote: > 2010/11/19 O. Hartmann<ohartman@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@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE6B3D5.5040101>