> Took /opt/csw/lib out of my LD_LIBRARY_PATH and it > now works. > > Blastwave is great but it often clobbers > functionality.
Blastwave doesn't clobber functionality. Unawareness clobbers functionality. What are you doing with a LD_LIBRARY_PATH on Solaris. Here's a good read why LD_LIBRARY_PATH is a bad thing. http://xahlee.org/UnixResource_dir/_/ldpath.html Many people don't understand the implications of stuff they stick in their .profile/.bash_profile/.login/.tcshrc/.cshrc/.kshrc file because they picked it up from somewhere else not on Solaris, or inherited from someone who never had any problems with those variables. Too many assumptions are made by not understanding dependencies. Solaris 10 is really in a quagmire because it's been out for 3.5 years and much of the OSS software that started there, is not as current as is found in SXCE or OpenSolaris/Indiana. To improve the user interface, we are forced as a community to rely on things like pkgbuild, Blastwave, SunFreeware and the plethora of Open Source binary package available for Solaris. So we load it up on our systems, and when we find something we want and it's not package, we end up compiling. This is where things like multiple libraries, PATH order, and a set of other variables can really bite the inexperienced. How you order your PATH can change how a configure script will pick up dependencies. If you have sun's glib, blastwave's glib and sunfreeware's glib, what comes first in your PATH depends on which library you compile against. This is additionally compounded by shell variables should as LIBS, LDFLAGS, LD_RUN_PATH and other "helper" variables which instruct the compiler and linker to do things you may not expect. Examening the actual configure log can often indicate where the script has picked up something unintentionally, because of PATH, environment flags like PKG_CONFIG_PATH, ACLOCAL, LDFLAGS, etc. Often, poorly built applications or libraries don't have all the "Solaris'isms" so configure tests might fail due to a link phase that doesn't pickup the -R <dir> which was not builtin the package config file (such as I experienced with libSDL a while back) Blastwave has done a very good job at making dependencies fool proof for the most part. However, they can't be held responsible for a badly formed LD_LIBRARY_PATH on Solaris (which should never be used in a global sense, it's appropriately used for testing, and shell wrapper scripts to make a *single* application behave differently than how it was compiled) Blastwave could take it a step further and make sure that no Blastwave applications could run with anything other than the dependencies they were compiled with. I'm not sure if that's a good thing or not. But it could be done. But again, even said, a bad LD_LIBRARY_PATH, or messing with crle without understanding the implications of what those settings actually cause most users a fair amount of consternation, complaining publically that some setting they mistakenly used is Blastwave's fault, instead of owning their mistake. I don't blame you. We hope that this stuff is simple, but often we have to customize our environments, and sometimes forget that a one-off fix, gets left around and 6 months down the road bites us on the butt. Look, the whole dependency thing is really complicated. Multiple application trees, libraries, configuration settings and a whole host of other customizations make this a very *indeterministic* process if you do not stay aware of all the implications of the environment you setup. It's doubly dangerous to the average user who just wants his favorite tool on Solaris, and there's no where to download a binary. As soon as you start compiling, you might try and fix the problem the best way you know how, and the next thing you know, VBOX won't run. Ben This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
