Re: gnome 2.8.0 and external dependencies

["Gerrit P. Haase" <gp at familiehaase dot de>]

Hi Yaakov,

> I'm pretty sure opencdk is a prereq for gnutls; I'm not sure exactly 
> what gnutls is needed for (gaim? mozilla?), nor libgpg-error or 
> libgcrypt, but they are definitely not necessary for the desktop or core 
> libs.

I think they are mentioned there because these packages are all external 
and not hosted with all the other gnome packages, though they also do 
explicitly list e.g. libxml2.

> > I think we can skip libfam and mozilla for now;)
> Do we have a choice? :-)

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.


> > Wait for announcements of:
> > libxml2
> > libxslt
> > gtk-doc
> > glib

> Are these all up-to-date now?

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.


> I'm having trouble with ORBit2 suddenly; I've tried both the current 
> version (2.12.0), and then the current port (2.10.3), but neither build 
> now.  The first step in building ORBit2 is to build the orbit-idl-2 
> compiler (dependent on libIDL, which is current), which is then used 
> throughout the rest of the build process to generate C code from IDL 
> files.  orbit-idl-2 will compile now, but when it is run I get a 
> *Windows* error message (in a dialog box) saying that the application 
> failed to initialize.  (This happened well before my cygheap problem, so 
> I don't think their related.)

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.


> Obviously, everything worked properly when I first built ORBit2-2.10.3, 
> and that binary package still runs, so it shouldn't be the update to 
> cygwin or glib2, nor autotools because the same ORBit2-2.10.3-1-src 
> package doesn't work now (with the previous autotools), so maybe gcc is 
> the culprit?  The current ORBit2-2.10.3-1 was built with gcc-3.3.1-3; 
> could _you_ try building it with gcc-3.3.3-3 and let me know your results?

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.


> In the meantime, is ORBit2-2.10.3 sufficient for libbonobo and GConf 2.8?
>
> > and I'll follow with:
> > intltool
> > libbonobo
> > pango
> > atk
> > gtk+
>
>
> 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.

> > and then we'll try to get GConf up and running...
>
>
> Unfortunately this is not within my abilities to help fix.  Good luck!

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.


> After all that, I have the following packages ready or almost ready; 
> those with a * need to be updated to Gnome 2.8:
[...]
> I'm not sure how many of the bindings should be in the distro, but I 
> think some of the basics would be nice.

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


> After updating that stuff, I'd like to get libgnomeprint, 
> libgnomeprintui, and diacanvas2 next, together with their bindings.  But 
> I need to get pango-1.6.0 for that, and more importantly, I need help 
> with my cygheap problem (see the main list from last night).

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 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.

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



> Once that's fixed, then I should be ready to ITP the stuff from fd.o, 
> libgnomecanvas2, and libwnck for starters, and we'll go from there.
>
> BTW, I will be busy the next week or two, but by the first week of 
> October things should be back to normal, in case nothing happens by then.

I have some spare time the next two - three weeks and then I'm busy at 
end of October.

Gerrit