Re: [E-devel] Alpha5: 7 patches and 1 bug

[Carsten H. (T. R. <ra...@ra...>]

On Fri, 4 Jan 2013 17:46:54 +0100 Joel Klinghed <th...@sp...> said:

> I'm sending this again after waiting 12+ hours for the last mail to end
> up on the list. Sorry if it ends up being delivered twice.
> 
> On Thu, 3 Jan 2013 20:25:47 +0900
> Carsten Haitzler (The Rasterman) <ra...@ra...> wrote:
> 
> > On Sat, 24 Nov 2012 23:48:09 +0100 Joel Klinghed <th...@sp...>
> > said:
> > 
> > > Hi,
> > > 
> > > I installed alpha5 on my main machine today and encountered a
> > > couple of problems, mainly configure issues (patches included) but
> > > one crash (or because e_alert & software composition doesn't seem
> > > to work for me, hang).
> > > 
> > > As a pretext to my configuration issues, I'm running on my very own
> > > LFS with homebrew prefix based package handling. So every program is
> > > installed in its own prefix and not dumped in the mess that is /usr.
> > > Also my X11 is not installed in /usr, /usr/X11 or any other of the
> > > numerous "default" locations. So yes, I'm rather used to having to
> > > nudge certain configure scripts into doing what they advertise ;)
> > > (almost all configure scripts I've seen check the prefix for X11,
> > > very few actually use it, EFL do pretty well considering).
> > > 
> > > On to the patches (based on the 1.7.2 packages released recently):
> > > 
> > > * eina-1.7.2-dirfd-fix.patch
> > > The check for dirfd used AC_LANG_PROGRAM incorrectly and thus always
> > > failed.
> > 
> > already fixed - but differently.
> 
> In the efl tree, yes.
> eina-1.7 branch still has the problem but perhaps it's not serious
> enough? Also noticed that the eet-1.7 branch has the same problem.
> I've included updated patches for the 1.7 branches anyway.

eina changed to

EFL_CHECK_FUNCS([eina], [dirfd dlopen dladdr fnmatch iconv shm_open setxattr])

in the 1.7 branch ... but the m4 macro is broken it seems.

> > 
> > > * eet-1.7.2-libgcrypt.patch
> > > Use cflags returned from libgcrypt-config when compiling files
> > > including libgcrypt.h
> > 
> > fixed it seems in later 1.7.x and in efl svn.
> 
> Not fixed on eet-1.7 branch.

hmm my bad - indeed 1.7 doesnt have it fixed.

> > > * evas-1.7.2-configure-xorg.patch
> > > Use X_CFLAGS when checking X11 and GL headers and X_LIBS when
> > > checking X11 and GL libs.
> > > Also use X_CFLAGS when compiling gl_common as GL headers might use
> > > the same prefix.
> > 
> > ummm configure.ac is a lot different now... try again?
> 
> I've included an patch for the merged efl tree.
> Also an updated patch for the evas-1.7 and ecore-1.7 branches.

no ecore one attached.

so now this is up to date... i'll base my comments on the efl merged patch. why
do you use "X_CFLAGS" and "X_LIBS" (i also spot X_PRE_LIBS)? are they not
detectable by just modifying your regular CFLAGS and LDFLAGS before configure
is run? why does this need a special set of env vars? basically - what about
the existing setup is broken/doesnt work right there? i smell some other
issue...

> > > * evas-1.7.2-fribidi.patch
> > > pkg-config --cflags for fribidi has always returned
> > > ${prefix}/include/fribidi so including fribidi/fribidi.h doesn't
> > > work.
> > 
> > indeed - right. i dont know how this has been missed for so long.
> 
> configure.ac check merged, but I don't see the fix for the source files?
> Included patch for both the merged efl tree and the evas-1.7 branch for
> those.

in svn.

> > > * enlightenment-0.17.0-alpha5-e_xsettings.patch
> > > e_xsettings.c use X11 headers directly, so must check for x_cflags.
> > 
> > better solution. make the code not use x headers directly.
> > 
> > > * enlightenment-0.17.0-alpha5-mixer-alsa.patch
> > > Use cflags from pkg-config alsa-lib when using alsa headers.
> > 
> > indeed u are right! this should be there. added.
> > 
> > > * enlightenment-0.17.0-alpha5-xkb_base.patch
> > > When searching for xkeyboard-config rules, before trying a long
> > > list of guessed standard paths, check the one given by the
> > > pkg-config file if it exists.
> > 
> > this is better indeed.
>  
> Missed that the wizard has it's own code for looking up the rules,
> included a patch for that based on the enlightenment-0.17.0 branch.

in svn.

> > > With all these patches applied I can compile, install and run
> > > enlightenment fine (well, have to fiddle a bit with EDJE_PREFIX and
> > > EDJE_LIB_DIR to allow edje and embryo to be installed in different
> > > prefixes on a multilib system).
> > > 
> > > I do however get a crash when trying to change the style of a shelf
> > > on one of my secondary screens to invisible.
> > > Attached gdb stacktrace (gdb.txt) and valgrind output
> > > (valgrind.txt). Running with valgrind the operation actually
> > > succeeds but gives a few bad accesses.
> > > Please tell me if you need any more information.
> > > 
> > > Regards, Joel Klinghed
> > 
> > i'm going to have to pass on debugging these as so much has passed
> > since then. do  u still get segvs on latest 1.7.4 (or 1.7.5 when its
> > out) and e17 release?
> > 
> 
> Tested on current 1.7 branches with e17 from the 0.17.0 branch, works
> now with no troubles. Great.
> 
> /JK

this was a joke? :) /jk :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...