On 11/19/10 18:11, Andrew W. Nosenko wrote:
2010/11/19 O. Hartmann<ohart...@zedat.fu-berlin.de>:
On 11/19/10 13:46, Koop Mast wrote:
On Fri, 19 Nov 2010 12:32:33 +0100
"O. Hartmann"<ohart...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
