Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/24/10 02:58, Andrew W. Nosenko wrote: On Tue, Nov 23, 2010 at 03:42, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: 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.dewrote: 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. And, for my personal taste, it is the best option. Be close to upstream as much as possible, IMHO, is the best way. (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. And I have some feelings that either existing xalan-c able to compile against current xerces-c or there is newer version that able. I tried to build xalan-c against xerces-c 3.1.1 and it doesn't work. The Apache website for Xalan explicitely says that Xalan-c 1.X is for Xerces-c 2.7. And I did not figure out where they'he hide a newer version compatible to the new Xerces-C 3.1.1. Also, ports graphics/visionworkbench, graphics/gdal, graphics/osg (Openscene Graph) also depend on Xerces-c 2.7, as far as I see. That leaeves me with the option of having a additional port xerces-c3 separated from the other xerces-c2. This is messy ... ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Tue, Nov 23, 2010 at 03:42, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: 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: 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. And, for my personal taste, it is the best option. Be close to upstream as much as possible, IMHO, is the best way. (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. And I have some feelings that either existing xalan-c able to compile against current xerces-c or there is newer version that able. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.dewrote: 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@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 ... Ineed it's simple not true. Both uses libNAME.so[.VER]. 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. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@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. 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 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Mon, Nov 22, 2010 at 08:20:28PM +0200, Andrew W. Nosenko wrote: [snip] Seems, like you think that Xerces authors use libNAME-VER.so naming scheme, while FreeBSD uses libNAME.so.VER ... Just as a data point, it's possible (I'm not sure if it's the case with Xerces, but it *is* the case with other libraries) that the OP is right. The Debian Policy Manual recently had to be amended a bit to allow for shared library files named as libfoo-version.so; for a full discussion (long!... no, I mean it - *really* long!), see: http://bugs.debian.org/509932 So it seems that there are projects that actually do it that way. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. signature.asc Description: Digital signature
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@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). 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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.dewrote: On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.dewrote: 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
Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Is it possible to manipulate the library name via some variables passed through the port-framework to the build-enviroment? Well, I'm very new to porting and this may seem to be a very easy task for experienced porters, so please excuse possible bothering ... Thanks in advance, 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Is it possible to manipulate the library name via some variables passed through the port-framework to the build-enviroment? There isn't. We leave the library name just like upstream/author wants it to be. We only hack the library version if needed. -Koop Well, I'm very new to porting and this may seem to be a very easy task for experienced porters, so please excuse possible bothering ... Thanks in advance, 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 ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@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. Is it possible to manipulate the library name via some variables passed through the port-framework to the build-enviroment? There isn't. We leave the library name just like upstream/author wants it to be. We only hack the library version if needed. This implies having a post-install: target in the Makefile where I'm supposed to move libxerces-c-3.1.so libbxerces-c.so.31? -Koop Well, I'm very new to porting and this may seem to be a very easy task for experienced porters, so please excuse possible bothering ... Thanks in advance, 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 ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.dewrote: 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? ___ 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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
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. Hartmannohart...@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! -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ 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
