GCC 3.2 incompatibilities: plugins for mozilla/galeon (Fwd with some maybe-interesting aspects)
This thread could be interesting for those working on the new GCC 3.2.
I don't think it might help much, but maybe it lets someone find a great
solution.
To my understanding, mozilla plugins don't work on GCC-3.2 build mozilla
or galeon, because they don't find some symbols.
Someone managed to get these plugins to work by adding some of these
symbols into the galeon binary and not stripping that completely.
Maybe one could write some Application that detects if an application
has linking errors due to gcc 3.2 incompatibility, and automatically
build a suiteable wrapper library. So instead of having to provide
compatibility libs built with old g++ versions, one could generate
compatibility wrapper libraries if they are needed only.
But one major point in one of these posts was:
Why provide a compatibility function for closed-source plugins - they
should bear the full drawbacks of their decision.
For reading the complete thread, please go to the list archives
https://lists.sourceforge.net/lists/listinfo/galeon-devel
I'm not involved in g++, so don't consider my ideas serious, i'm just
trying to help you do your job by giving some "outside" ideas.
I actually don't know or care if they work ;) Brainstorming ;)
So if the above doesn't work: just delete my mail.
Greetings,
Erich
----- Forwarded message from Nix <nix@esperi.demon.co.uk> -----
To: Kelledin <kelledin@skarpsey.dyndns.org>
Cc: galeon-user@lists.sourceforge.net,
galeon-devel@lists.sourceforge.net
From: Nix <nix@esperi.demon.co.uk>
Subject: [Galeon-devel] Re: [Galeon-user] Fwd: Galeon 1.2.5 patch
X-BeenThere: galeon-devel@lists.sourceforge.net
On Mon, 9 Sep 2002, kelledin@skarpsey.dyndns.org said:
> Some background you might or might not be aware of:
> Closed-source Netscape plugins compiled with gcc-g++ v2.x expect
> certain symbols to be in libstdc++. Unfortunately, the
> libstdc++ from gcc-3.x does not include all of these symbols.
s/all/any/
The name-mangling scheme and ABI are completely different.
> For most standalone precompiled apps, it's a simple matter to
> just include libstdc++ from gcc2, but for Netscape plugins
> (which ultimately resolve all symbol references from the binary
> which dlopen's them), this is a problem if the binary is built
> against gcc3's libstdc++.
>
> The solution to this problem is to make the binary in question
> (galeon-bin in our case) provide the necessary functions if they
> are not present in libstdc++. There is a patch floating around
> out there that fixes this problem for Mozilla; I took the
The above is OK, as far as it goes, but it doesnt' go very far (it
implements new, new[], delete and delete[], and nothing else). It'll
handle plugins that are basically written in C-with-new-and-classes, but
it won't work for plugins that make use of the STL, or (especially)
plugins that throw exceptions.
(Exception throwing between GCC 2 and GCC 3 libraries *is* doable, but
it is extremely difficult; look at glibc 2.3-to-be to see how to do it.)
> I've tested the patch with gcc 3.1.1, and it appears to work
> without a hitch. Plugins for RealPlayer, Shockwave, and Acrobat
> all work now (they broke before due to symbol relocation
> errors). j2sdk would probably work as well, but I'm using a
It references
nsServiceManager::GetGlobalServiceManager(nsIServiceManager **)
so you'd have to add a wrapper for that, at least (a function
called GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager
should do the trick, but I haven't tested it.)
> gcc3-compiled j2sdk, so meh. ;)
How'd you get one of those, as a matter of interest? My entire system is
using GCC 3.2 *except for the damn JDK wrapper* and it's getting a bit
annoying.
> The major caveat to remember about this patch is that galeon-bin
> should _not_ be fully stripped--just "strip --strip-unneeded" is
> all that should be done, else you'll lose the fixes.
Have you tracked down why this is?
I can't see any reason why strip would remove functions from a binary
(or *how* it could for that matter; it can't tell where they start or
finish anymore).
Perhaps strip is removing eh_frame information, but I can't see why it
would choose to do that, either. Stripping galeon works for me (with
strip from binutils 2.13).
--
`Mips are real and bitrate earnest, shifting spam is not our goal;
silicon to sand returnest, was not spoken of the soul.'
--- _Eventful History: Version 1.x_, John M. Ford
----- End forwarded message -----
Gruss,
Erich Schubert
--
erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C
A man doesn't know what he knows until he knows what he doesn't know.
Glück gleicht durch Höhe aus, was ihm an Länge fehlt.
Der Wissende weiß, dass er glauben muß.
Reply to: