2011/2/8 Jonathan Craig <[email protected]>: > The primary reason being that this allows easier integration of > multiple versions. If you reverse this and force the actual library > into /opt/csw/lib then you will have to move this library to its > package/versioned subdirectory before overwriting. This would be a > logistical nightmare.
I'm not sure I'm following. Can you describe a concrete scenario? > As to libraries with SONAME collisions I don't know whether its better > to not create any symlinks or always create symlinks to the newest > version (or possibly last installed). Its a coin toss between > problems finding libraries during builds and the possibility that > you'll break an existing application by installing a newer version of > the library. Having said that, I guess I would lean towards > operational stability and not create any symlinks. Each backward-incompatible upgrade of a library comes with a new SONAME, so it won't break existing programs. There's one predictable SONAME collision scenario, and it is C++ libraries compiled with Solaris Studio vs GCC. Because each complier has it's own way of name mangling, the two libraries will be incompatible. I see two potential solutions to it: 1. Injecting a soname modification, e.g. turning libfoo.so.1 into libfoo-gcc.so.1 2. Keeping GCC-compiled C++ libraries in a separate directory, e.g. /opt/csw/lib-gcc Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
