Date: Mon, 22 Nov 2010 14:54:27 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> Cc: Koop Mast <kwm@rainbow-runner.nl>, freebsd-ports@freebsd.org Subject: Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes? Message-ID: <4CEA7613.7030407@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! > 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 libxerces-c.so.31, as far as I see from your mail it would be more convenient having a port textproc/xerces-c3 with the library libxerces-c-3.1.so? 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. Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CEA7613.7030407>