[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forcing static link of libstdc++

From: Stefan Puiu
Subject: Re: Forcing static link of libstdc++
Date: Tue, 26 Sep 2006 22:03:31 +0300

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 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

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,

        -Mike Melanson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]