Re: Forcing static link of libstdc++

[Stefan Puiu]

On 9/26/06, Mike Melanson <address@hidden> 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