gnome 2.8.0 and external dependencies

[Gerrit P. Haase]

Yaakov Selkowitz said the following on 04-09-29 06:54:
> 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?

Yes.  We=ll I tried that, it doesn't succedd.  It also fails to build 
the native windows version though, the build system is broken IMO. 
Whoever is preparing the Mozilla releases does a great job.

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

I hope that it will work as is.  It is just gmodule is not looking for 
'cygname.dll', only for 'libname.dll' when you say load extension 'name' 
in your application.


>> That is the reason why we must use libtool-1.5.10, there are data 
[...]
> 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.

It is already available, as test version though.


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

No, I cannot believe it, I submitted the patch about one year ago and it 
was applied to the devel perl tree and also backported to 5.8 IIRC.

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


IIRC I already was able to install some modules via the cpan shell,
I'll look into it later.


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

Increases the default heap size (default heap_chunk_in_mb is 256MB), 
Google search should bring up some threads about it:
http://www.google.com/search?q=heap_chunk_in_mb&sourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8

The 0400 above is actually 1024MB.

Gerrit
-- 
=^..^=