Stefan Puiu wrote:
Yes, but also making sure the flash plugin can statically link with
libstdc++ increased your development effort quite a bit. And if Ralf
is correct about the symbol clashes that you can experience because of
the way ELF works, I think you agree that the QA extra effort in this
case would also increase. Only the troubleshooting involved would be
more difficult , and if you have problems with ELF symbol resolution,
all the hacks you've ahd to go through would be useless.
The QA process is exactly doubled since there are 2 binaries instead of
1 binary that needs to be run through the formal certification process.
Also, consider the matter of end-user experience: A typical users
usually knows whether they need to download the Windows, Mac, or Linux
version of the Player. What happens when the Linux user sees:
1) Flash Player for Linux linked against libstdc++ v5
2) Flash Player for Linux linked against libstdc++ v6
That's the kind of thing an end user should not have to worry about.
We've been using gcc-3.3 for quite a while and when moving to 4.0 I
found out that the latter is a lot less permissive - usually stuff
that compiles with 3.3 will break on 4.0, because of two-phase lookup.
Is it something two-phase lookup related? Is it only in one part of
the code, and reproducible in a small program?
I tried many different versions of gcc. I seem to recall that different
versions had different problems with C++ constructs in core code. We
felt it was better to roll with a version that compiled the current code
and move forward with making the Player work on current Linux systems.
--
-Mike Melanson
