On Sat, 5 Jan 2013 12:53:26 +0100 Joel Klinghed <the...@spawned.biz> said:
> On Sat, 5 Jan 2013 11:25:58 +0900
> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
>
> > On Fri, 4 Jan 2013 17:46:54 +0100 Joel Klinghed <the...@spawned.biz>
> > 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) <ras...@rasterman.com> wrote:
> > >
> > > > On Sat, 24 Nov 2012 23:48:09 +0100 Joel Klinghed
> > > > <the...@spawned.biz> 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.
>
> Ah, right. I mainly concentrated on the fact that the configure test
> failed still ;)
>
> > > >
> > > > > * 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...
>
> Right, forgot the ecore one, included this time.
>
> X_CFLAGS, X_LIBS, X_PRE_LIBS and X_EXTRA_LIBS are all set by
> AC_PATH_XTRA. So not env vars.
> They are more or less what x_cflags and x_libs ends up being.
>
> AC_PATH_X on the other hand sets x_includes and x_libraries.
>
> I could have used x_includes and x_libraries instead but then I would
> had to move the header and lib checks below the x_lib, x_cflags, x_libs
> calculations as I don't want to do that work twice.
>
> To summarise, my problem is that AC_PATH_X and AC_PATH_XTRA full and
> well find my X11 path (/usr/xorg as it happens) but the next test
> AC_CHECK_HEADER([X11/X.h]) fails because it doesn't use any of the
> results from those macros.
ok... so here´s the question. it seems you are putting xorg in its own prefix
ala the good old /usr/X11R6 (or /usr/xorg now)... which has kind of been
dropped as a standard x location amongst a lot of distros/os's - why should
this be handled specially anymore when adding -I/usr/xorg/include and
-L/usr/xorg/lib to your $CFLAGS and $LDFLAGs (also maybe adjust
LD_LIBRARY_PATH, PATH and PKG_CONFIG_PATH).. exactly like you need to do with
every other package you install from scratch this is why fribidi was a problem
- right? u put it in /usr/fribidi or something?) ... ? i'm just wondering here
why we need to add even more autofluff special cases here when it's becoming
increasingly less common and env vars solve the problem in a ingle universal
common way for every case like this? :)
> >
> > > > > * 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 :)
>
> No-one has ever done that connection before, weird ;)
>
> /Joel Klinghed
awwww! now i can giggle anymore! :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
