Re: gnome 2.8.0 and external dependencies

[Yaakov Selkowitz <yselkowitz at users dot sourceforge dot net>]

Gerrit P. Haase wrote:
> I have tried several times to build mozilla, it shouild work AFAICS, but 
> the build system is a mess, at least I was able to build spidermonkey.

On X11 I presume?

> No, I introduced a bug in the glib2 update, I'll upload another update 
> tomorrow.  GLib uses dlopen() then.  The other three yes, they don't 
> depend on GLib.  After I have GLib updated I'll need to recompile atk, 
> pango and gtk+ which were ready but Martin reported the GLib bug so I 
> didn't uploaded them yet.  The new updates are based on libtool-1.5.10 
> now which seems to work fine here.

Just to clarify, does this bug affect everything compiled against 
glib-2.4.6-1, or will everything work as is with the new package?

> 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.
>
> That was mysterious for me too, I compiled GConf the first tiome, it 
> worked, but I didn't included the old locking patches, so it fails to 
> run.  Then I fetched Steve's locking patches and after the second build 
> it was broken.  I'm not sure if I updated any package between the two 
> builds.
>
> 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.

So for now, it sounds we're waiting for libtool-1.5.10.  Later, maybe 
you could help me so I know what to patch in regards to these .rdata tags.

> > Only libbonobo requires ORBit2; the others could be updated as soon as 
> > they're ready.  gtk+ is currently 2.4.10, after a number of bugfixes 
> > since our 2.4.4.  More noticably, atk and pango versions have been 
> > bumped, and I know that libgnomeprint-2.8.0 needs pango >= 1.5, so 
> > updating pango will be helpful.
>
> Yes, I will submit them at first.

Thanks.

> Some of the Perl packages are building without modification via cpan 
> shell, so I think these should not be included.

I don't know how that's possible (except for the ExtUtils::*); 
EU::MakeMaker still doesn't like .dll.a, and all the modules are 
dependent on at least Glib and many of them Gtk2 at link time, and this 
needs to be specified in cygwin  (EU::Depends still doesn't do this). 
Trust me, I know, I've discussed this before with the gtk2-perl people. 
 Less importantly, to build all the man3 files, a dirty hack is needed 
for most of the modules.

In any case, it should be worth it to include at least Glib and Gtk2. 
Then there's still PyGTK and the gtkmm bindings.

> I saw it, I had similar problems once, but I cannot remember the actual 
> solution.  Are you sure that there is no other Cygwin DLL in memory?
> Some commercial applications are installing cygwin1.dll as well!

I know about that, and am very careful.  I'm sure that wasn't the problem.

> I make a backup in such cases, `format h:` reinstall all the stuff and 
> everytime I'm missing a DLL or a library I pull it out of the backup.

I ended up removing everything but /home and doing a clean reinstall.  I 
think I'm back up and running again.

> What I also did was to buy some more RAM and I added this to my 
> registry, maybe this helps?
>
> REGEDIT4
>
> [HKEY_CURRENT_USER\SOFTWARE\Cygnus Solutions\Cygwin]
> "heap_chunk_in_mb"=dword:00000400
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin]
> "heap_chunk_in_mb"=dword:00000400

What does this do exactly?


Yaakov