This is the mail archive of the
mailing list for the Cygwin project.
Re: gnome 2.8.0 and external dependencies
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
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.
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
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?
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:
The 0400 above is actually 1024MB.