Re: [gentoo-user] e17 fails to build from svn

[Alan McKinnon <alan.mckinnon@gmail.com>]

Apparently, though unproven, at 21:34 on Tuesday 17 May 2011, Mick did opine 
thusly:

> On 17 May 2011 08:01, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > Apparently, though unproven, at 08:23 on Tuesday 17 May 2011, Mick did
> > opine
> > 
> > thusly:
> >>   eukit >= 1.0.999
> >>   ehal
> >> ) were not met:
> >> 
> >> No package 'ehal' found
> > 
> > e17 from svn works fine here.
> > 
> > What version are you trying to install?
> 
> These are the packages I tried to install/update:

I can confirm that e17 builds just fine without hal, I remerged everything 
here today with a fresh svn update.

I compared by USE to yours and they are much the same apart from ofono (not 
relevant) and I have ukit enabled.

You are running x86 (32 bit) right? I see your USE has (-hal) whereas mine is 
-hal. man emerge implies that means the flag is forced off somehow, so I would 
be interested to see what e17 thinks it should do on your machine.

Please emerge enlightenment (just that one package) and post the section just 
before this:

checking for E_REMOTE... yes
checking for E_IMC... yes
checking for E_THUMB... yes

It's the 5 lines or so immediately before the error in your first post and 
will mention hal_mount and eeze.

[snip]

> > When emerge ran, did it check out the
> > latest code for first first?
> 
> You lost me here!  O_O

Looks like a bad paste error. I meant if you use the regular overlay and check 
out a fresh svn update with each emerge (i.e. not using an old checkout with 
updates from the repo disabled). I see elsewhere you do use fresh checkouts.
 
> > The hal stuff in e17 has been iffy for a while.
> 
> Right, but I have excluded all hal USE flags as far as I can tell,
> that's why I cannot understand why x11-wm/enlightenment-9999 failed
> with that error.

Well, the gentoo part works. It's the e17 ./configure step that is iffy.

raster HATES use flags with a passion; automagic deps is the only way to go in 
his worldview. Quite obviously this will lead to problems on gentoo with no 
real way to disable support for something you do have installed. (Just because 
you have libXYZ installed is not a good reason to force support on for it 
everywhere that might use it.)

> 
> Anyway, tonight it failed right on the first package:
> ====================================
> 
> >>> Emerging (1 of 10) dev-libs/eina-9999 from enlightenment

[snip]

Well, whaddaya know. For once it wasn't cedric who broke it. Looks like commit 
r59468 to eina at 17:45 by tasn did it.  

> eina_binbuf_template_c.x:140: error: conflicting types for
> 'eina_binbuf_length_get'
> ../../src/include/eina_binbuf.h:209: note: previous declaration of
> 'eina_binbuf_length_get' was here
> eina_amalgamation.c:17936: error: redefinition of '__STRBUF_MAGIC_STR'
> eina_amalgamation.c:1222: note: previous definition of
> '__STRBUF_MAGIC_STR' was here
> make[3]: *** [libeina_la-eina_amalgamation.lo] Error 1

[snip]

> What's causing this one?

I don't see an easy way to workaround this apart from reverting r59468.

So, just skip past eina, you already have a copy from earlier that built 
correctly and portage won't catch version difference seeing as everything is 
-9999


> BTW, any idea when DR17 will make it into the portage tree?

I suppose it would have to exist first :-)

EFL-1.0.0 is released since three months ago so it could go into the tree. It 
probably isn't there yet because the most useful app using it - the window 
manager - is still unreleased.

I reckon vapier or barbieri would be the right people to answer that question.


-- 
alan dot mckinnon at gmail dot com