Pavel Janík wrote:
Hi,
Another line of attack I had in mind is to ship a recent version of
libstdc++.so.6 (from GCC 4.2, say), even if we continue to build with
GCC 3.4.1. The advantages are that it is simple, we do not need to
change any code, and OOo keeps running on machines that do not
already have a listdc++.so.6 installed (see above); the disadvantage
is that it only cures the current symptoms and is no general fix (as
in the future system libraries can again have dependencies on then
more current versions of libstdc++.so.6).
Any objections against solving issue 86389 this way? (Heiner told me
that Sun Hamburg might switch to some GCC 4 for the final OOo 3.0 on
Linux, anyway). If there are no objections, we could cancel any
further meetings on this...
I have an objection. The solution is nonsense. We do not want binary
libstdc++.so.6 in the CVS. If this solution sounds appropriate for
commercial software, it is no go fo OpenOffice.org.
You misunderstand me; I guess I was not clear enough.
1 Sun Hamburg Linux builds include a libstdc++.so.6 that comes from
somewhere "by magic"; it is not checked into CVS. That is already how
it works for a long time, and probably will not change. Traditionally,
the included libstdc++.so.6 is the one corresponding to the compiler
with which Sun Hamburg creates the builds (but it should be OK to use a
later one, due to libstdc++.so.6's compatibility nature). It is the Sun
Hamburg builds that are offered for download on the OOo web site.
2 Linux distros typically do not include any libstdc++.so in their OOo
builds, as they already have a matching one included in the distro.
Note that OOo builds included in a Linux distro (when run on that Linux
distro) are never affected by the problem of issue 86389.
3 Others building OOo on Linux (for themselves, or for distribution
through whatever channel) either include the libstdc++.so coming with
the compiler they use (--without-system-stdlibs, the default) or do not
include any libstdc++.so (--with-system-stdlibs), IIUC.
A general fix for the problem of issue 86389 (for any system with any
kind of libstdc++.so available, ensure that any kind of OOo distributed
through whatever channel---see 1 and 3 above---works fine) appears to be
nontrivial and out of scope for OOo 3.0. (Rene's suggestion to never
include a libstdc++.so in OOo would solve the problem, but would
probably have other drawbacks as discussed. Lets assume that Sun
Hamburg---see 1 above---will not use that solution. Others---see 3
above---are of course easily able to use that solution, via
--with-system-stdlibs.)
However, a more specific fix for issue 86389 (Sun Hamburg built
OOo/BrOffice failing on Mandriva) appears to be rather easily available
(by including, "by magic," a more recent libstdc++.so.6 in the Sun
Hamburg builds). I am well aware that this solution has the two
drawbacks that it only solves the problem for Sun Hamburg builds, not
for builds done by others (see 3 above; but those are free to adopt
Rene's suggestion to solve the problem), and that it only works until
the libstdc++.so.6 included in OOo again becomes outdated on certain
systems.
Does this make it more clear?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
