gnome 2.8.0 and external dependencies

[Charles Wilson]

Gerrit P. Haase wrote:

>   The new updates are based on libtool-1.5.10
> now which seems to work fine here.

Yay!

> That is the reason why we must use libtool-1.5.10, there are data 
> symbols in some Glib objects which are tagged with .rdata and when you 
> try to dynamically load them -> bang.   I got always this crash when 
> GConf loaded gthread.dll.  Now I don't find any 'R' tags in /usr/lib, 
> run this: for i in `ls *.dll.a`; do echo $i && nm $i | grep ' R '; done 
> in /usr/lib.

Well, that's not conclusive.  All that means is that so far, one of the 
following is true:
    (1) the libs have not been recompiled with a new gcc (>= 3.3.3-3)
OR
    (2) the libs do not have any const data items WHICH THEMSELVES 
CONTAIN pointers to other exported DATA items in their public interface.

libtool-1.5.x (x<10) had the flaw where it deliberately violated #2. 
Newer gcc's obligingly put the container item into .rdata -- where the 
runtime-pseudo-reloc magic couldn't update the *contained* references to 
the other DATA items.  We're actually just sidestepping the issue 
("Don't do that") by convincing libtool-1.5.10 to declare the container 
non-const, so it goes into .data where pseudo-reloc can muck with it.

That doesn't mean some other package might currently be violating #2. 
It just means that if so, this mythical other package hasn't yet been 
recompiled using gcc-3.3.3-3 or newer.

Keep your fingers crossed.

> What changed is that there are these .rdata tags in symbols.  That may 
> well cause such problems.  Charles explained exactly why the error 
> happens and that it must be changed in the source, we should look into 
> all the libraries if there are .rdata rtags and then try to patch the 
> sources so that gcc puts these symbols in data sections instead.

Yep.  See above.  gmodule-related stuff might be affected by this issue, 
since glib does its own symbol marshalling and lookup-table definitions.

> Now since Charles has found a workaround and we have the new libtool 
> version we can run the apps and debug them.  What to do if you even 
> cannot start the application?  The only thing I saw was that loading 
> gthread gives my a crash.

maybe caused by attempts to use thread local storage?  I'm not sure how 
mature the combination of gcc/binutils/cygwin/libtool/tls is.

--
Chuck