On Wed, 2006-11-15 at 16:03 +0100, Ivan Perez wrote:
> >> I'm using Gentoo Linux. We obviously don't use prebuilt packaged
> >> versions, but installing it is just doing "emerge wxhaskell" and
> >> 'playing the... waiting game'. Gtk2hs support under Gentoo is mostly
> >> missing (the package is included, but doesn't work at all).
> > Hmm, that strange. I emerged both gtk2hs-0.9.10 and ghc-6.4.2 just fine.
> > Probably you should update your portage tree. I don't remember exactly, but I
> > used portage snapshot from late spring of 2006.
> Duncan Coutts wrote:
> > Heh, that's odd. For me it's usually the other way around and I maintain
> > both of those Gentoo packages! :-)
> > Are you thinking of this bug or is it something else?
> > http://bugs.gentoo.org/show_bug.cgi?id=144028
> > If it's something else then please report it.
> I'm always using the latest portage snapshot, there seems to be
> a problem with c2hs, the one of that bug report (144028).
> I usually keep my system up to date, reemerging everything
> I need to. I tried all the available versions of
> gtk2hs, none of them worked (I used different glibc versions,
> different gcc and ghc versions, etc.).
So yes, it is a c2hs problem. It currently cannot parse a construct used
in glibc 2.4.x.
Specifically, in /usr/include/bits/libio-ldbl.h it has:
and __LDBL_REDIR_DECL is a macro that expands to...
# define __LDBL_REDIR_DECL(name) \
extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
so the whole thing expands to:
extern __typeof(_IO_vfscanf) _IO_vfscanf __asm (__ASMNAME ("__nldbl__IO_vfscanf"));
the problem is that we're expecting a type but what we get is this type
expression '__typeof(_IO_vfscanf)' so basically we need to extend the
c2hs C parser to recognise __typeof(<name/expr>) as a type expression.
> In a Debian box, I could download the source and compile it myself
> with no problems at all.
That is because Debian is using an older version of glibc that doesn't
use the __typeof construct.
> I even tried to modify a copy of the ebuild in my own
> portage overlay, but couldn't make it work either.
Yeah, sadly that wouldn't help. c2hs needs to be taught about this GNU C
extension that glibc 2.4 is now using.
> Btw, as far as I remember (I don't have my laptop here to check it out),
> either the ebuild or the 'configure' script have a "use-external-c2hs"
> flag. I couldn't get it to work. If the support of an external
> version of c2hs is totally missing in current versions of gtk2hs,
> having this option here is definitely misleading (I remember
> I got a warning/error msg when trying to use it, however).
Yes I added the error message when the option is used. The plan is that
we will eventually be able to use the normal c2hs version rather than
our own fork.