/usr
local
lib
boost-1.40.0
boost-1.41.0
boost -> boost-1.41.0
Lazy developers will use boost and not boost-1.40.0 and suddenly
things will break in strange, hard to figure out ways.
Could you clarify what will break?
The usual suspects for dynamic linker issues.
It's not the end of the world when it happens because it can be easily
pinned on the user/sysadmin as to why things broke, but this scenario
strikes me as reasonably common or probable enough:
1) Install 1.40 with libboost_foo.so
2) Install 1.41 with libboost_foo.so
3) Remove boost-1.40
4) Update library path to include boost-1.41
5) Run program linked against 1.40. ldd finds libboost_foo.so.1 in
boost 1.41 with a different API, or worse, a different ABI.
The problem stems from developer not verifying or confirming different
ABIs during their build process. Thinking it'll "just work" with the
symlink in there is the root of this comment.
The linker resolves the symlink using getcwd(3) in the directory of
the library, but when the symlink changes, boost-1.40.0 disappears and
it falls back to the ld cache.... Where this gets particularly
unpleasant is a symlink from lib/libboost_foo.so to lib/boost-1.40.0/
libboost_foo.so. That's the only scenario that should be prevented at
all costs, the one above is a preference from having hunted down
FreeBSD ports bugs in the past.
-sc
--
Sean Chittenden
s...@chittenden.org
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
