Re: Forcing static link of libstdc++

[Mike Melanson]

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