Hi everybody,
I am sorry if my question simple and well-known. After several hours investigating man-pages, google and books I did not found answer to my question.
Short version of question: Does rpm update ld.so config files after/during install rpm package with so-files?
Longer version of question.
Our software (to some reasons) uses boost 1.46.1 under CentOS 6.3. We can not downgrade to lower version of boost to some reasons, most important - we support also Ubuntu 12.04 LTS, and really do not want develop/test/support two version of product with different boost versions.
We built related boost packages, put their to our repository, and everything works fine. Unfortunately, one customer use boost 1.41 version in some internal software from official CentOS repository, and customer can not use together our software and his internal software.
We decided rename our "boost" packages to "product_name-boost-*" and move library files from /usr/lib64 to /opt/product_name/version/lib (path /opt/product_name/version we use for our internal software). I rebuilt boost packages, everything works fine.
The question which I try to understand: do we need update LD_LIBRARY_PATH for our binaries? As far I can see, ldd show correct pathes to boost. I do not understand well, how exactly works rpm in this moment, and what the best solution: 1) find way to have together boost 1.41 and 1.46.1 without package renames (which problem we can meet? how "yum remove boost*" would works? how to remove specific version of boost? etc) 2) rename packages from "boost* to "product_name-boost-*" and do not change path from /usr/lib64 3) rename packages from "boost*" to "product_name-boost-*" and change install pathes for libraries/include to /opt/product_name/version/... 4) (3) + setup LD_LIBRARY_PATH for every our binary
I hope to your advices, links, help.
Thank you very much, Oleg
On Mon, 2013-02-25 at 16:40 +0900, Oleg Tsarev wrote:
The question which I try to understand: do we need update LD_LIBRARY_PATH for our binaries? As far I can see, ldd show correct pathes to boost.
This has nothing to do with packaging per se.
The reason why ldd shows correct paths is because your software is most probably linked with libtool or any other linking wrapper that was smart enough to realize that the binaries are being linked against the libraries that reside outside of the standard loader search path, and therefore hardcoded an RPATH right inside the binaries pointing to your particular library tree.
So to answer your question, as long as you keep your copy of boost outside the standard loader search path, you can rely on RPATH and everything will work automagically.
As soon as you are willing to provide libraries usable by other software, you should, of course, take care of running ldconfig from your SPECs in the corresponding sections (%post and %postun, for instance), and manage /etc/ld.so.conf.d files if you have them in non-standard locations.
In your case, obviously, you shouldn't do any of this, and keep your boost private to your software, because otherwise, you are going to break CentOS base packages that rely on boost.
Thank you for your answer,
On Mon, Feb 25, 2013 at 5:03 PM, Yury V. Zaytsev yury@shurup.com wrote:
On Mon, 2013-02-25 at 16:40 +0900, Oleg Tsarev wrote:
The question which I try to understand: do we need update LD_LIBRARY_PATH for our binaries? As far I can see, ldd show correct pathes to boost.
This has nothing to do with packaging per se.
The reason why ldd shows correct paths is because your software is most probably linked with libtool or any other linking wrapper that was smart enough to realize that the binaries are being linked against the libraries that reside outside of the standard loader search path, and therefore hardcoded an RPATH right inside the binaries pointing to your particular library tree.
1) We use CMake for build our C++ software. How to check linked or does not linked our software with libtool?
2) If RPATH hardcoded to binary, it means, our software would works fine after installation from packages on clean machine - is it right? Confirm/Disconfirm please.
So to answer your question, as long as you keep your copy of boost outside the standard loader search path, you can rely on RPATH and everything will work automagically.
3) On clean machine too?
As soon as you are willing to provide libraries usable by other software, you should, of course, take care of running ldconfig from your SPECs in the corresponding sections (%post and %postun, for instance), and manage /etc/ld.so.conf.d files if you have them in non-standard locations.
I modified CMakeLists.txt for our software: defined BOOST_ROOT variable, and FindBoost.cmake successfully resolved path to boost libraries. We do not need make our boost available for other software. Should we change anything?
In your case, obviously, you shouldn't do any of this, and keep your boost private to your software, because otherwise, you are going to break CentOS base packages that rely on boost.
I renamed boost packages (added prefix product_name-). The primary reason - we do not want to build boost on every developer/build/customer machine. We want build boost once and use everywhere. For delivery boost libraries/header files etc the most forward way - packages, and it is really awesome way.
-- Sincerely yours, Yury V. Zaytsev
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi Oleg,
I have provided you with all the pointers.
Subsequent discussion does not belong to this list, because it has nothing to do with the development of CentOS.
On Mon, 2013-02-25 at 17:19 +0900, Oleg Tsarev wrote:
- We use CMake for build our C++ software. How to check linked or
does not linked our software with libtool?
Most probably it isn't.
- If RPATH hardcoded to binary, it means, our software would works
fine after installation from packages on clean machine - is it right? Confirm/Disconfirm please.
http://en.wikipedia.org/wiki/Rpath
So to answer your question, as long as you keep your copy of boost outside the standard loader search path, you can rely on RPATH and everything will work automagically.
- On clean machine too?
Yes.
I modified CMakeLists.txt for our software: defined BOOST_ROOT variable, and FindBoost.cmake successfully resolved path to boost libraries. We do not need make our boost available for other software. Should we change anything?
I guess not.
-
Oleg Tsarev -
Yury V. Zaytsev