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.
sfunny, we at blastwave, dont seem to have any linking problems, compiling against our stuff :-) Basically, blastwave packages are set up to be binary distributions, not developer distributions. If you want to compile other stuff against our packages, you are encouraged to become a maintainer and add to the collection, using our nice clean build servers ;-) If you are compiling stuff on your own machines, and you dont WANT blastwave libs linked in... simplest thing is to just remove /opt/csw/bin from your $PATH, and pretend the blastwave packages dont exist for purposes of your compile. Contrariwise, if you DO want to compile against blastwave stuff, then remove /opt/sfw/bin from your path, add in /opt/csw/bin first in your PATH, and it's all good. (If you also follow the other build notes specified in our build standards) In NEITHER case, should you mess with LD_LIBRARY_PATH, or crle. That's what actually leds to the most problems. Properly compiled software does not use or need crle or LD_LIBRARY_PATH to work. They only mess things up. _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
