<div dir="ltr">Thank you for your answer,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 25, 2013 at 5:03 PM, Yury V. Zaytsev <span dir="ltr"><<a href="mailto:yury@shurup.com" target="_blank">yury@shurup.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2013-02-25 at 16:40 +0900, Oleg Tsarev wrote:<br>
><br>
> The question which I try to understand: do we need update<br>
> LD_LIBRARY_PATH for our binaries? As far I can see, ldd show correct<br>
> pathes to boost.<br>
<br>
</div>This has nothing to do with packaging per se.<br>
<br>
The reason why ldd shows correct paths is because your software is most<br>
probably linked with libtool or any other linking wrapper that was smart<br>
enough to realize that the binaries are being linked against the<br>
libraries that reside outside of the standard loader search path, and<br>
therefore hardcoded an RPATH right inside the binaries pointing to your<br>
particular library tree.<br></blockquote><div><br></div><div>1) We use CMake for build our C++ software. How to check linked or does not linked our software with libtool?<br></div><div><br>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. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So to answer your question, as long as you keep your copy of boost<br>
outside the standard loader search path, you can rely on RPATH and<br>
everything will work automagically.<br></blockquote><div><br></div><div>3) On clean machine too?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As soon as you are willing to provide libraries usable by other<br>
software, you should, of course, take care of running ldconfig from your<br>
SPECs in the corresponding sections (%post and %postun, for instance),<br>
and manage /etc/ld.so.conf.d files if you have them in non-standard<br>
locations.<br></blockquote><div><br></div><div>I modified CMakeLists.txt for our software: defined BOOST_ROOT variable, and FindBoost.cmake successfully resolved path to boost libraries.<br></div><div>We do not need make our boost available for other software.<br>
Should we change anything?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In your case, obviously, you shouldn't do any of this, and keep your<br>
boost private to your software, because otherwise, you are going to<br>
break CentOS base packages that rely on boost.<br></blockquote><div><br></div><div>I renamed boost packages (added prefix product_name-). <br></div><div>The primary reason - we do not want to build boost on every developer/build/customer machine. We want build boost once and use everywhere.<br>
</div><div>For delivery boost libraries/header files etc the most forward way - packages, and it is really awesome way.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sincerely yours,<br>
Yury V. Zaytsev<br>
<br>
<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</font></span></blockquote></div><br></div></div>