[Top][All Lists]

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

Re: Forcing static link of libstdc++

From: Mike Melanson
Subject: Re: Forcing static link of libstdc++
Date: Tue, 26 Sep 2006 10:18:15 -0700
User-agent: Thunderbird (X11/20060802)

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

reply via email to

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