On 11/23/10 02:14, Andrew W. Nosenko wrote:
On Mon, Nov 22, 2010 at 22:20, O. Hartmann
<ohart...@mail.zedat.fu-berlin.de> wrote:
On 11/22/10 19:20, Andrew W. Nosenko wrote:
On Fri, Nov 19, 2010 at 19:28, O. Hartmann
<ohart...@mail.zedat.fu-berlin.de> wrote:
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!
Well, maybe here is a misunderstanding.
Sure. See below.
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?
Seems, like you think that Xerces authors use libNAME-VER.so naming
scheme, while FreeBSD uses libNAME.so.VER ...
Well, after building a vanilla xerces-c version 3.1.1 and checked the
vendor's point of view how the lib should be named, I guess my thinking is
right about libNAME-VER.so. Simply try download and compile/install the
sources from http://xerces.apache.org/xerces-c/.
Ineed it's simple not true. Both uses libNAME.so[.VER].
I doubt this, or I do something stupid everytime again and again.
Yes. You mess the package version (3.1 oe 3.1.1 in your case) with
the ABI version (.0 or empty, in this case AFAIU).
Well, I just compare to xerces-c.so.27 or xerces-c.so.28
(xerces-c2-devel). Both libraries get installed according to the
FreeBSD's library naming policy. I do not find any library that is apart
from this naming policy in my boxes /usr/local/lib. Old xerces-c ports
seem to have some kind of home-brewn build environment, so GNU autotools
do not apply and it seems to be easier to come along with the naming
policy which is introduced for FreeBSD's libraries.
Usually, libNAME.so.VER with greatest VER symlinked to libNAME.so.
How VER represented (it just a number, or more complicated like .N,
.N.M., .N.M.K... -- depends on the ld.so implementation on the target
system and usually should not bother you as software author (if you
use Libtool, which is good in job of hiding differences between
systems in that respect).
Also, these .N[.M[.K]] represent the ABI version of library and has
nothing with package version.
Just in the case of Xerces, the NAME contains digits that looks like
version (version of package). But indeed, the NAME in your case _is_
"libxerces-c-3.1". I unable to say what ABI version VER is without
building Xerces-C, or upstream authors decided to left it empty
indeed, sorry.
The new xerces-c 3.1.1 comes with a whole/complete autotools-environment.
There is a m4-folder containing libtool.m4. I tried to patch this in the
section "freebsd-elf*" and "freebsd-*" to reflect the naming scheme FreeBSD
uses (libNAME.so.VER). I tried several variations, but it seems that
Simple don't touch and you will comply! The NAME part here is
"xerces-c-3.1". Not NAME="xerces-c" and VER="3.1" but
NAME="xerces-c-3.1" and VER is empty.
Again: "3.1" is the part of NAME!
something from the ports toplevel Makefile isn't triggering a
reconfiguration the right way.
I did the same with the toplevel ./configure file which already contains the
libtool.m4-macro substitutions, but again, it doesn't seem to be possible to
change the libname that gets installed.
I tried forcing triggering a aclocal/autoconf procedure via USE_AUTOTOOLS=
butthis results surprisingly in a linker error.
My intention is to manipulate the installed library and the symbolic link
that way that it is clean in the sense of low complication post-install
manipulations.
xerces-c and xerces-c2 are already in the ports collection and I need a
collision-free xerces-c3, so renaming the installed library is important.
Again: just don't touch the library name and you will collision free
from the library names point of view: xerces-c2 has no
libxerces-c-3.1.so.
But there lives another problem: Xerces people doesn't expect parallel
installation of the "evelopment" part of Xerces-C (headers,
pkg-config, etc). At least it seems so by listing the libxerces-c
package from Ubuntu.
I guess so, but some ports of the FreeBSD ports (i.e. textproc/xalan-c)
want xerces-c2 (which is 2.7.0). I try build xalan-c with the new
xerces-c3 and see if it can handle the new header and libraries.
I see three variants:
(1) simple: just mark these ports (c2 and c3) as conflicting,
... in my testcase I did.
(2) semi-simple: split each xerces-c port at the two: run-time and
development. Runtime contains a shered library, development contains
anything other. Mark development parts as conflictitng.
... well, in such a case we converge much to the weird Linux mess, I guess.
(3) move each port away from each other's way: move headers into own
versioned deirectory (e.g. from include/xercesc/ to
insclude/xercesc-3.1/xercesc/), drop libxerces-c.so (if any -- I don't
know), rename pkg-config (.pc) file, and static library (if any), may
be something yet another, like documentation -- need to look at the
actual install. All these changes hidden from the users through
pkg-config's .pc, therefore only one problem for developers will be
changed (non-standard name of the .pc file, i.e. pkg-config's module).
... this would bring up other complications for ports expecting libs and
headers at places where the solo installation normally resides.
But ATM I see no better way to allow parallel installation of the
packages that aren't intended for parallel installation by theirs
authors...
I tend to install it as a unique port with conflicts activated. Hope
there are no further conflicts other than xalan-c.
I thought I could pass some environment variables to the autotool
environment when building via a port's top level Makefile, but this seems to
be impossible.
_______________________________________________
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"
