Hello Philip, Saturday, April 15, 2006, 2:27:45 AM, you wrote:
PB> On Sat, Apr 15, 2006 at 02:13:11AM +0200, Robert Milkowski wrote: >> Hello James, >> >> Thursday, April 13, 2006, 2:06:40 PM, you wrote: >> >> JC> Hugh McIntyre writes: >> >> JC> That's also what Debian does. That fixes the dependency problem, but >> JC> doesn't fix the path problem. >> >> JC> The path problem for libraries is that if one installs as >> >> JC> /opt/csw/lib/libfoo.so.1 >> >> JC> and the other installs as >> >> JC> /opt/sfw/lib/libfoo.so.1 >> >> JC> then one can't really satisfy the other. The user is forced straight >> JC> into LD_LIBRARY_PATH or crle(1) hell, and that's just not right. >> >> We do use Blastwave on our servers and I must say that I realy don't >> like all the problems with doubled libraries (like openssl). Sometimes >> you even endup linking with the library from blastwave while you were >> expecting something else - due to dependencies. PB> sfunny, we at blastwave, dont seem to have any linking problems, PB> compiling against our stuff :-) PB> Basically, blastwave packages are set up to be binary distributions, not PB> developer distributions. PB> If you want to compile other stuff against our packages, you are encouraged PB> to become a maintainer and add to the collection, using our nice clean PB> build servers ;-) Sorry, internal software only. PB> If you are compiling stuff on your own machines, and you dont WANT PB> blastwave libs linked in... simplest thing is to just remove /opt/csw/bin PB> from your $PATH, and pretend the blastwave packages dont exist for purposes PB> of your compile. PB> Contrariwise, if you DO want to compile against blastwave stuff, then PB> remove /opt/sfw/bin from your path, add in /opt/csw/bin first in your PB> PATH, and it's all good. PB> (If you also follow the other build notes specified in our build standards) PB> In NEITHER case, should you mess with LD_LIBRARY_PATH, or crle. PB> That's what actually leds to the most problems. What if I want to compile our own software linked with Solaris OpenSSL (to get Niagara HW acceleration for example) and linked with other open source libraries provided by Blastwave? What if then these libraries depend on openssl provided by Blastwave... and things get messy here. In my case I don't care about OSS packages being compatible with S8, S9, S10, etc. (although there are people who do). -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
