On 9/26/06, Mike Melanson <[EMAIL PROTECTED]> wrote:
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.
I understand that very well. I was just thinking that it might be
preferrable than dealing with random crashes and angry users. In this
case, you would also need to re-think your solution - which might be
more time consuming, especially if you end up doing what Ralf and I
were suggesting.
Please check the document I linked (section 1.5 - Startup in the
dynamic linker), I think Ralf has a point. I don't think there's any
problem with the libstdc++.so already loaded by firefox when flash
will be loaded, since your version will be statically linked (thus no
relocations - at least that's my understanding); the problem will be
with plugins loaded *after* the flash plugin, as far as I understand,
because it will find the libstdc++ symbols exported in the Flash DSO
before the others. That's why Ralf was asking if you take any measures
to not export the libstdc++ symbols you export. Drepper's DSO HOWTO
also shows you how to check what your shared library is exporting.
Now consider the possible results - sometimes the plugin works fine,
other times it crashes, depending on which plugin gets loaded first;
for end users, this is not easy to reproduce or understand. Maybe it
will work in most cases, but I don't think you want to go with "mostly
works".
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.
Somebody suggested a different approach in the penguin.swf blog's
comments - check what opera does; they have a small number of packages
customized for many distros, but you pick the version according to
distro. Or two alternatives:
1) For each libstdc++ version, offer a list of most common distros
shipped with it in a parantheses. Then, offer a link explaining how to
check the version for those who didn't find their distro.
2) provide a shell script that checks the libstdc++ version (and/or
distro) and downloads the relevant package.
Of course, I realize this would require changing your code so that it
compiles with an older version of gcc (3.2 or 3.3).
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.
I agree it always has to be a trade off. I was just suggesting that
there might be some more drawbacks to the approach you've chosen.
Thanks for listening,
Stefan.
--
-Mike Melanson
