Anthony Towns schrieb:
On Tue, Dec 17, 2002 at 07:54:32PM +0900, Junichi Uekawa wrote:I've thought having a directory for doing LD_LIBRARY_PATH might help people keep compatibility with other dists or legacy applications,What other dists or legacy applications? Do you have examples?Anyone who has locally built a c++ application on their system is going to be broken.Yes, do you have any examples? If there are real world examples, then that's something interesting that might be worth working on.
I want to mention another class of examples: gtkmm/sigc++ based programs.Since I wrote a lot of complex gtkmm programs for local (manuproc.berlios.de & unpublished friends) and public use (e.g. midgard.berlios.de) I have lots of real world examples to give.
And as a debian administrator (~10 computers) I qualify as a person going to be biten by the change (or benefitting from it).
To summarize:- Gtkmm2 programs tend to crash when compiled with 2.95 (the dynamic_cast bug) [If you used glade--, they always crash!]. So for any gtkmm2 development I'm forced to rebuild the needed packages with 3.2 right now. _Please_ do not delay shipping libraries compiled with 3.2 too long.
- There might be old versions of C++ libraries around which _might_ be sensible to still ship built with 2.95, since they do not get used in new programs. E.g. libstdc++-1.0 and libgtkmm-1.2, the gnomemm 1.2 packages. This means cheap binary compatibility to woody. But identifying and patching the packages which need them (and therefore 2.95) to build is not a task I'd love to do. This situation is comparable to kde2 packages. Also this would keep the list of still 2.95 using programs longer.
- I do not mind if I have to recompile programs for this switch. Though this is a lot of work (up to 20 different c++ applications). If I really want to continue using old binaries, I can set libgtkmm and libsigc++ to hold (or make a local copy of the *.so.* files).
- I'd never use unstable on critical servers (where breakage would mean instant work under time presssure). But I'm not convinced that it's worth the hassle to provide libfoo.so.* compiled with 2.95 for people using testing. 3.2's benefits outweight the recompile/LD_LIBRARY_PATH nuisance during the transition.
We may need to add in our release notes: "We broke ABI, please recompile from source",Well, yes. "We updated GCC which breaks the C++ ABI; if you have complicated C++ programs, please rebuild them."
Perhaps listing the C++ libraries with this issue in an appendix might be a good idea. [libxerxes, libsigc++ (and therefore libgtkmm), libqt] An easy ldd will tell you about compatibility.
It might suffice to instruct users to install packages from woody,Before we spend time, effort or imagination on this, there needs to be some evidence that it'll actually benefit people.
does this mail help?"3.2 now!" will benefit me most ;-) I don't care much for compatibility libraries (and longer delay).
Yours Christof