From: Joel K. <th...@sp...> - 2012-11-24 23:09:25
|
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. * eet-1.7.2-libgcrypt.patch Use cflags returned from libgcrypt-config when compiling files including libgcrypt.h * 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. * 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. * enlightenment-0.17.0-alpha5-e_xsettings.patch e_xsettings.c use X11 headers directly, so must check for x_cflags. * enlightenment-0.17.0-alpha5-mixer-alsa.patch Use cflags from pkg-config alsa-lib when using alsa headers. * 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. 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-03 11:26:35
|
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. > * 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. > * 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? > * 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. > * 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. > 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? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Joel K. <th...@sp...> - 2013-01-04 17:50:18
|
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. > > > * 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. > > * 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. > > * 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. > > * 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. > > 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-05 02:26:01
|
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... |
From: Joel K. <th...@sp...> - 2013-01-05 12:26:37
|
On Sat, 5 Jan 2013 11:25:58 +0900 Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > 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. 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. > > > > > * 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-06 06:04:18
|
On Sat, 5 Jan 2013 12:53:26 +0100 Joel Klinghed <th...@sp...> said: > On Sat, 5 Jan 2013 11:25:58 +0900 > Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > > > 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. > > 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) ra...@ra... |
From: Joel K. <th...@sp...> - 2013-01-06 11:21:37
|
On Sun, 6 Jan 2013 15:04:23 +0900 Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: [snip] > > > > > > > > > * 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? :) Well, for most packages you have some way of asking where it was installed so you don't have to write infernal long CFLAGS and LDFLAGS. You have pkg-config, *-config scripts and so on. To me, the whole point of checking if and where a package is installed is so compiling will just work on every dist and OS. Old X11 you located by using xmkmf (which is what AC_PATH_X* does). For Xorg you actually have nice pkg-config files but they are only used for xcb. The thing is, even if I put my Xorg in /usr/X11R6 the configure check as they are now would not work. They *only* work if X11/Xlib.h is places in /usr/include or /usr/local/include or one of the standard includes. Same for libs as both AC_CHECK_HEADER and AC_CHECK_LIB doesn't use x_includes or x_libraries that you later use to actually compile everything. But yes, it is unusual not to put your X11 files all over /usr and /usr/X11R6. Perhaps because of all these broken configure scripts? ;) I can take that I'll have to add -I/usr/xorg/include -L/usr/xorg/lib64 to CFLAGS and LDFLAGS respectively but then I must ask, why do you bother calling AC_PATH_X and AC_PATH_XTRA? You don't use it and unless everything is accessible from /usr/include and /usr/lib anyway it wont work as both the X11/X.h and XCreateImage in libX11.so checks will fail. [snip] /JK |
From: Gustavo S. B. <bar...@pr...> - 2013-01-07 21:25:29
|
Hi Joel, Just go to this mail, did you try that with SVN EFL (trunk, single tree)? I'm trying to get it right for release 1.8, so if you find something that applies there, let me know. >From memory the XTRA stuff should also be wrong, if you send the patch I'll apply. On Sun, Jan 6, 2013 at 8:54 AM, Joel Klinghed <th...@sp...> wrote: > On Sun, 6 Jan 2013 15:04:23 +0900 > Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > > [snip] > > > > > > > > > > > > * 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? :) > > Well, for most packages you have some way of asking where it was > installed so you don't have to write infernal long CFLAGS and LDFLAGS. > You have pkg-config, *-config scripts and so on. > To me, the whole point of checking if and where a package is installed > is so compiling will just work on every dist and OS. > > Old X11 you located by using xmkmf (which is what AC_PATH_X* does). > For Xorg you actually have nice pkg-config files but they are only used > for xcb. > > The thing is, even if I put my Xorg in /usr/X11R6 the configure check > as they are now would not work. They *only* work if X11/Xlib.h is > places in /usr/include or /usr/local/include or one of the standard > includes. Same for libs as both AC_CHECK_HEADER and AC_CHECK_LIB > doesn't use x_includes or x_libraries that you later use to actually > compile everything. > > But yes, it is unusual not to put your X11 files all over /usr > and /usr/X11R6. Perhaps because of all these broken configure > scripts? ;) > > I can take that I'll have to add -I/usr/xorg/include -L/usr/xorg/lib64 > to CFLAGS and LDFLAGS respectively but then I must ask, why do you > bother calling AC_PATH_X and AC_PATH_XTRA? You don't use it and unless > everything is accessible from /usr/include and /usr/lib anyway it wont > work as both the X11/X.h and XCreateImage in libX11.so checks will fail. > > [snip] > > /JK > > > ------------------------------------------------------------------------------ > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Joel K. <th...@sp...> - 2013-01-07 22:20:39
Attachments:
efl-configure-xorg-2.patch
|
On Mon, 7 Jan 2013 19:25:22 -0200 Gustavo Sverzut Barbieri <bar...@pr...> wrote: > Hi Joel, > > Just go to this mail, did you try that with SVN EFL (trunk, single > tree)? I'm trying to get it right for release 1.8, so if you find > something that applies there, let me know. > > From memory the XTRA stuff should also be wrong, if you send the > patch I'll apply. Yes I did, most of the missing CFLAGS & LIBS handling from evas 1.7.x was copied over to merged trunk efl. Attached is an updated patch based on r82364 that includes what I need to be able to compile efl with either x11 or xcb backend including GL without modifying environment variables. But the whole patch builds on the premise that AC_PATH_X and AC_PATH_XTRA gives correct results. For old (pre modular Xorg) X11 this is not a problem, AC_PATH_X uses xmkmf to get include and lib directories (or uses the --x-includes, --x-libraries arguments given to configure). For modern X11 the whole Imakefile system is probably missing (including xmkmf). Some distros do what I do, create a fake xmkmf that just returns what AC_PATH_X needs. Some modify AC_PATH_X to use pkg-config. A lot just put everything in /usr/include. I do not pretend to know what all of them do... To put it another way, my patch tries to unify the flags used in the configure checks and the flags used in the compilation. Without the patch the compilation uses the results of AC_PATH_X but the configure checks do not. /JK > On Sun, Jan 6, 2013 at 8:54 AM, Joel Klinghed <th...@sp...> > wrote: > > > On Sun, 6 Jan 2013 15:04:23 +0900 > > Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > > > > [snip] > > > > > > > > > > > > > > > * 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? :) > > > > Well, for most packages you have some way of asking where it was > > installed so you don't have to write infernal long CFLAGS and > > LDFLAGS. You have pkg-config, *-config scripts and so on. > > To me, the whole point of checking if and where a package is > > installed is so compiling will just work on every dist and OS. > > > > Old X11 you located by using xmkmf (which is what AC_PATH_X* does). > > For Xorg you actually have nice pkg-config files but they are only > > used for xcb. > > > > The thing is, even if I put my Xorg in /usr/X11R6 the configure > > check as they are now would not work. They *only* work if > > X11/Xlib.h is places in /usr/include or /usr/local/include or one > > of the standard includes. Same for libs as both AC_CHECK_HEADER and > > AC_CHECK_LIB doesn't use x_includes or x_libraries that you later > > use to actually compile everything. > > > > But yes, it is unusual not to put your X11 files all over /usr > > and /usr/X11R6. Perhaps because of all these broken configure > > scripts? ;) > > > > I can take that I'll have to add -I/usr/xorg/include > > -L/usr/xorg/lib64 to CFLAGS and LDFLAGS respectively but then I > > must ask, why do you bother calling AC_PATH_X and AC_PATH_XTRA? You > > don't use it and unless everything is accessible from /usr/include > > and /usr/lib anyway it wont work as both the X11/X.h and > > XCreateImage in libX11.so checks will fail. > > > > [snip] > > > > /JK > > > > > > ------------------------------------------------------------------------------ > > 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 > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > |
From: Gustavo S. B. <bar...@pr...> - 2013-01-07 22:39:33
|
Hi Joel, This looks fine, one last question: why are these needed? =================================================================== --- src/Makefile_Ecore_Evas.am (revision 82364) +++ src/Makefile_Ecore_Evas.am (working copy) @@ -74,7 +74,8 @@ -I$(top_srcdir)/src/lib/ecore_x \ -I$(top_builddir)/src/lib/ecore_x \ -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ --I$(top_srcdir)/src/modules/evas/engines/gl_x11 +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ +@ECORE_X_CFLAGS@ modules_ecore_evas_engines_x_module_la_LIBADD = \ lib/ecore_evas/libecore_evas.la \ lib/ecore_x/libecore_x.la Index: src/Makefile_Ecore_Imf.am =================================================================== --- src/Makefile_Ecore_Imf.am (revision 82364) +++ src/Makefile_Ecore_Imf.am (working copy) @@ -155,7 +155,8 @@ -I$(top_builddir)/src/lib/ecore_x \ -I$(top_srcdir)/src/lib/ecore_imf \ @ECORE_IMF_CFLAGS@ \ -@EFL_COV_CFLAGS@ +@EFL_COV_CFLAGS@ \ +@ECORE_X_CFLAGS@ modules_ecore_immodules_xim_xim_la_LIBADD = \ lib/ecore_imf/libecore_imf.la \ lib/ecore_x/libecore_x.la \ Index: src/Makefile_Evas.am both ecore_evas and imf shouldn't be doing X directly, rather using Ecore_X that shouldn't expose X directly. A quick look tells me that ecore-evas is including X directly for some weird reason I'll try to investigate. But how about IMF? On Mon, Jan 7, 2013 at 8:02 PM, Joel Klinghed <th...@sp...> wrote: > On Mon, 7 Jan 2013 19:25:22 -0200 > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > Hi Joel, > > > > Just go to this mail, did you try that with SVN EFL (trunk, single > > tree)? I'm trying to get it right for release 1.8, so if you find > > something that applies there, let me know. > > > > From memory the XTRA stuff should also be wrong, if you send the > > patch I'll apply. > > Yes I did, most of the missing CFLAGS & LIBS handling from evas 1.7.x > was copied over to merged trunk efl. > > Attached is an updated patch based on r82364 that includes what I need > to be able to compile efl with either x11 or xcb backend including GL > without modifying environment variables. > > But the whole patch builds on the premise that AC_PATH_X and > AC_PATH_XTRA gives correct results. > > For old (pre modular Xorg) X11 this is not a problem, AC_PATH_X uses > xmkmf to get include and lib directories (or uses the --x-includes, > --x-libraries arguments given to configure). > For modern X11 the whole Imakefile system is probably missing > (including xmkmf). Some distros do what I do, create a fake xmkmf > that just returns what AC_PATH_X needs. Some modify AC_PATH_X to use > pkg-config. A lot just put everything in /usr/include. I do > not pretend to know what all of them do... > > To put it another way, my patch tries to unify the flags used in the > configure checks and the flags used in the compilation. Without the > patch the compilation uses the results of AC_PATH_X but the configure > checks do not. > > /JK > > > On Sun, Jan 6, 2013 at 8:54 AM, Joel Klinghed <th...@sp...> > > wrote: > > > > > On Sun, 6 Jan 2013 15:04:23 +0900 > > > Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > > > > > > [snip] > > > > > > > > > > > > > > > > > > * 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? :) > > > > > > Well, for most packages you have some way of asking where it was > > > installed so you don't have to write infernal long CFLAGS and > > > LDFLAGS. You have pkg-config, *-config scripts and so on. > > > To me, the whole point of checking if and where a package is > > > installed is so compiling will just work on every dist and OS. > > > > > > Old X11 you located by using xmkmf (which is what AC_PATH_X* does). > > > For Xorg you actually have nice pkg-config files but they are only > > > used for xcb. > > > > > > The thing is, even if I put my Xorg in /usr/X11R6 the configure > > > check as they are now would not work. They *only* work if > > > X11/Xlib.h is places in /usr/include or /usr/local/include or one > > > of the standard includes. Same for libs as both AC_CHECK_HEADER and > > > AC_CHECK_LIB doesn't use x_includes or x_libraries that you later > > > use to actually compile everything. > > > > > > But yes, it is unusual not to put your X11 files all over /usr > > > and /usr/X11R6. Perhaps because of all these broken configure > > > scripts? ;) > > > > > > I can take that I'll have to add -I/usr/xorg/include > > > -L/usr/xorg/lib64 to CFLAGS and LDFLAGS respectively but then I > > > must ask, why do you bother calling AC_PATH_X and AC_PATH_XTRA? You > > > don't use it and unless everything is accessible from /usr/include > > > and /usr/lib anyway it wont work as both the X11/X.h and > > > XCreateImage in libX11.so checks will fail. > > > > > > [snip] > > > > > > /JK > > > > > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > enl...@li... > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > ------------------------------------------------------------------------------ > 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. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Joel K. <th...@sp...> - 2013-01-07 23:27:38
|
On Mon, 7 Jan 2013 20:39:26 -0200 Gustavo Sverzut Barbieri <bar...@pr...> wrote: > Hi Joel, > > This looks fine, one last question: why are these needed? > > =================================================================== > --- src/Makefile_Ecore_Evas.am (revision 82364) > +++ src/Makefile_Ecore_Evas.am (working copy) > @@ -74,7 +74,8 @@ > -I$(top_srcdir)/src/lib/ecore_x \ > -I$(top_builddir)/src/lib/ecore_x \ > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > +@ECORE_X_CFLAGS@ > modules_ecore_evas_engines_x_module_la_LIBADD = \ > lib/ecore_evas/libecore_evas.la \ > lib/ecore_x/libecore_x.la Without this I get: In file included from modules/ecore_evas/engines/x/ecore_evas_x.c:22: ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: fatal error: 'X11/Xlib.h' file not found I assume this is the one you found. > Index: src/Makefile_Ecore_Imf.am > =================================================================== > --- src/Makefile_Ecore_Imf.am (revision 82364) > +++ src/Makefile_Ecore_Imf.am (working copy) > @@ -155,7 +155,8 @@ > -I$(top_builddir)/src/lib/ecore_x \ > -I$(top_srcdir)/src/lib/ecore_imf \ > @ECORE_IMF_CFLAGS@ \ > -@EFL_COV_CFLAGS@ > +@EFL_COV_CFLAGS@ \ > +@ECORE_X_CFLAGS@ > modules_ecore_immodules_xim_xim_la_LIBADD = \ > lib/ecore_imf/libecore_imf.la \ > lib/ecore_x/libecore_x.la \ Without this I get: modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: 'X11/Xlib.h' file not found > > both ecore_evas and imf shouldn't be doing X directly, rather using > Ecore_X that shouldn't expose X directly. A quick look tells me that > ecore-evas is including X directly for some weird reason I'll try to > investigate. But how about IMF? > > > On Mon, Jan 7, 2013 at 8:02 PM, Joel Klinghed <th...@sp...> > wrote: > > > On Mon, 7 Jan 2013 19:25:22 -0200 > > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > > > Hi Joel, > > > > > > Just go to this mail, did you try that with SVN EFL (trunk, single > > > tree)? I'm trying to get it right for release 1.8, so if you find > > > something that applies there, let me know. > > > > > > From memory the XTRA stuff should also be wrong, if you send the > > > patch I'll apply. > > > > Yes I did, most of the missing CFLAGS & LIBS handling from evas > > 1.7.x was copied over to merged trunk efl. > > > > Attached is an updated patch based on r82364 that includes what I > > need to be able to compile efl with either x11 or xcb backend > > including GL without modifying environment variables. > > > > But the whole patch builds on the premise that AC_PATH_X and > > AC_PATH_XTRA gives correct results. > > > > For old (pre modular Xorg) X11 this is not a problem, AC_PATH_X uses > > xmkmf to get include and lib directories (or uses the --x-includes, > > --x-libraries arguments given to configure). > > For modern X11 the whole Imakefile system is probably missing > > (including xmkmf). Some distros do what I do, create a fake xmkmf > > that just returns what AC_PATH_X needs. Some modify AC_PATH_X to use > > pkg-config. A lot just put everything in /usr/include. I do > > not pretend to know what all of them do... > > > > To put it another way, my patch tries to unify the flags used in the > > configure checks and the flags used in the compilation. Without the > > patch the compilation uses the results of AC_PATH_X but the > > configure checks do not. > > > > /JK > > > > > On Sun, Jan 6, 2013 at 8:54 AM, Joel Klinghed <th...@sp...> > > > wrote: > > > > > > > On Sun, 6 Jan 2013 15:04:23 +0900 > > > > Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > > > > > > > > [snip] > > > > > > > > > > > > > > > > > > > > > * 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? :) > > > > > > > > Well, for most packages you have some way of asking where it was > > > > installed so you don't have to write infernal long CFLAGS and > > > > LDFLAGS. You have pkg-config, *-config scripts and so on. > > > > To me, the whole point of checking if and where a package is > > > > installed is so compiling will just work on every dist and OS. > > > > > > > > Old X11 you located by using xmkmf (which is what AC_PATH_X* > > > > does). For Xorg you actually have nice pkg-config files but > > > > they are only used for xcb. > > > > > > > > The thing is, even if I put my Xorg in /usr/X11R6 the configure > > > > check as they are now would not work. They *only* work if > > > > X11/Xlib.h is places in /usr/include or /usr/local/include or > > > > one of the standard includes. Same for libs as both > > > > AC_CHECK_HEADER and AC_CHECK_LIB doesn't use x_includes or > > > > x_libraries that you later use to actually compile everything. > > > > > > > > But yes, it is unusual not to put your X11 files all over /usr > > > > and /usr/X11R6. Perhaps because of all these broken configure > > > > scripts? ;) > > > > > > > > I can take that I'll have to add -I/usr/xorg/include > > > > -L/usr/xorg/lib64 to CFLAGS and LDFLAGS respectively but then I > > > > must ask, why do you bother calling AC_PATH_X and AC_PATH_XTRA? > > > > You don't use it and unless everything is accessible > > > > from /usr/include and /usr/lib anyway it wont work as both the > > > > X11/X.h and XCreateImage in libX11.so checks will fail. > > > > > > > > [snip] > > > > > > > > /JK > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > 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 > > > > enl...@li... > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > 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. SALE $99.99 this month only -- learn > > more at: http://p.sf.net/sfu/learnmore_122412 > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > |
From: Gustavo S. B. <bar...@pr...> - 2013-01-08 18:49:59
|
On Mon, Jan 7, 2013 at 8:53 PM, Joel Klinghed <th...@sp...> wrote: > On Mon, 7 Jan 2013 20:39:26 -0200 > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > Hi Joel, > > > > This looks fine, one last question: why are these needed? > > > > =================================================================== > > --- src/Makefile_Ecore_Evas.am (revision 82364) > > +++ src/Makefile_Ecore_Evas.am (working copy) > > @@ -74,7 +74,8 @@ > > -I$(top_srcdir)/src/lib/ecore_x \ > > -I$(top_builddir)/src/lib/ecore_x \ > > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > > +@ECORE_X_CFLAGS@ > > modules_ecore_evas_engines_x_module_la_LIBADD = \ > > lib/ecore_evas/libecore_evas.la \ > > lib/ecore_x/libecore_x.la > > Without this I get: > > In file included from modules/ecore_evas/engines/x/ecore_evas_x.c:22: > ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: fatal > error: 'X11/Xlib.h' file not found > > I assume this is the one you found. > ok, this was fixed today by raster. You can drop this from your patch :-) > Index: src/Makefile_Ecore_Imf.am > > =================================================================== > > --- src/Makefile_Ecore_Imf.am (revision 82364) > > +++ src/Makefile_Ecore_Imf.am (working copy) > > @@ -155,7 +155,8 @@ > > -I$(top_builddir)/src/lib/ecore_x \ > > -I$(top_srcdir)/src/lib/ecore_imf \ > > @ECORE_IMF_CFLAGS@ \ > > -@EFL_COV_CFLAGS@ > > +@EFL_COV_CFLAGS@ \ > > +@ECORE_X_CFLAGS@ > > modules_ecore_immodules_xim_xim_la_LIBADD = \ > > lib/ecore_imf/libecore_imf.la \ > > lib/ecore_x/libecore_x.la \ > > Without this I get: > modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: > 'X11/Xlib.h' file not found > this is really needed, but we shouldn't use ECORE_X_CFLAGS. Rather we need to find out XIM requirements and do another CFLAGS/LIBS pair. >From what it seems to be: #include <X11/Xlib.h> #include <X11/Xlocale.h> #include <X11/Xutil.h> The symbols seems to be all in libX11.so Would you do this? If I'm not asking enough, a last desire would be: could you please add support for Xlib .pc files? :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Joel K. <th...@sp...> - 2013-01-09 01:38:34
Attachments:
efl-configure-xorg-4.patch
|
On Tue, 8 Jan 2013 16:49:52 -0200 Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Mon, Jan 7, 2013 at 8:53 PM, Joel Klinghed <th...@sp...> > wrote: > > > On Mon, 7 Jan 2013 20:39:26 -0200 > > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > > > Hi Joel, > > > > > > This looks fine, one last question: why are these needed? > > > > > > =================================================================== > > > --- src/Makefile_Ecore_Evas.am (revision 82364) > > > +++ src/Makefile_Ecore_Evas.am (working copy) > > > @@ -74,7 +74,8 @@ > > > -I$(top_srcdir)/src/lib/ecore_x \ > > > -I$(top_builddir)/src/lib/ecore_x \ > > > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > > > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > > > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > > > +@ECORE_X_CFLAGS@ > > > modules_ecore_evas_engines_x_module_la_LIBADD = \ > > > lib/ecore_evas/libecore_evas.la \ > > > lib/ecore_x/libecore_x.la > > > > Without this I get: > > > > In file included from > > modules/ecore_evas/engines/x/ecore_evas_x.c:22: ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: > > fatal error: 'X11/Xlib.h' file not found > > > > I assume this is the one you found. > > > > ok, this was fixed today by raster. You can drop this from your > patch :-) > > > > Index: src/Makefile_Ecore_Imf.am > > > =================================================================== > > > --- src/Makefile_Ecore_Imf.am (revision 82364) > > > +++ src/Makefile_Ecore_Imf.am (working copy) > > > @@ -155,7 +155,8 @@ > > > -I$(top_builddir)/src/lib/ecore_x \ > > > -I$(top_srcdir)/src/lib/ecore_imf \ > > > @ECORE_IMF_CFLAGS@ \ > > > -@EFL_COV_CFLAGS@ > > > +@EFL_COV_CFLAGS@ \ > > > +@ECORE_X_CFLAGS@ > > > modules_ecore_immodules_xim_xim_la_LIBADD = \ > > > lib/ecore_imf/libecore_imf.la \ > > > lib/ecore_x/libecore_x.la \ > > > > Without this I get: > > modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: > > 'X11/Xlib.h' file not found > > > > this is really needed, but we shouldn't use ECORE_X_CFLAGS. > > Rather we need to find out XIM requirements and do another > CFLAGS/LIBS pair. > > >From what it seems to be: > #include <X11/Xlib.h> > #include <X11/Xlocale.h> > #include <X11/Xutil.h> > > The symbols seems to be all in libX11.so > > Would you do this? > > If I'm not asking enough, a last desire would be: could you please add > support for Xlib .pc files? :-) > Damn you for getting me to do this ;) Changelog from the last patch: * Removed ECORE_X_CFLAGS from evas_ecore_x * Split out ecore_imf_xim to do its own check * Fixed problem with xcb:s makekeys, no rule for $(top_builddir)/src/utils/ecore/makekeys$(EXEEXT) exists so make used an implicit rule (ignoring any cflags of course) * Fixed gl_x11 engine to build with either Xlib or XCB (xcb flags were missing) * Added EFL_FIND_X and replace any used of AC_PATH_X{,TRA}. First looks for Xorg pkg-config files then if those arn't found it falls back to old AC_PATH_X. Also generalized common header and lib checks. Could probably use some polishing (the AC_CACHE_VAL cruft especially) but this is what I have time for tonight. /Joel Klinghed |
From: Gustavo S. B. <bar...@pr...> - 2013-01-09 16:49:16
|
committed as it will help you, but would be nice to simplify even further. >From logs: checking how to find X... use pkg-config checking for EFL_X11... yes checking X11/X.h usability... yes checking X11/X.h presence... yes checking for X11/X.h... yes checking for evas_engine_software_xlib... yes checking for XCreateImage... yes checking for XShmCreateImage... yes ... checking how to find X... (cached) already found checking X11/Xlib.h usability... yes checking X11/Xlib.h presence... yes checking for X11/Xlib.h... yes checking X11/Xatom.h usability... yes checking X11/Xatom.h presence... yes checking for X11/Xatom.h... yes checking X11/Xutil.h usability... yes checking X11/Xutil.h presence... yes checking for X11/Xutil.h... yes checking X11/extensions/Xrender.h usability... yes checking X11/extensions/Xrender.h presence... yes checking for X11/extensions/Xrender.h... yes checking X11/Xresource.h usability... yes checking X11/Xresource.h presence... yes checking for X11/Xresource.h... yes checking for evas_engine_gl_xlib... yes checking for XCreateColormap... yes checking for XRenderCreatePicture... yes if using pkg-config, do not check any of header of symbols. Situation with Ecore_X is also the same: checking how to find X... (cached) already found checking for X11/Xlib.h... (cached) yes checking X11/Xcursor/Xcursor.h usability... yes checking X11/Xcursor/Xcursor.h presence... yes checking for X11/Xcursor/Xcursor.h... yes checking for ECORE_X_XLIB... yes checking for XOpenDisplay... yes checking for XcursorImageLoadCursor... yes checking for X11/extensions/XKB.h... yes checking for XkbSetDetectableAutoRepeat in -lX11... yes checking for X11/extensions/Xcomposite.h... yes checking for XCompositeQueryExtension in -lXcomposite... yes checking for X11/extensions/Xdamage.h... yes checking for XDamageSubtract in -lXdamage... yes checking for X11/extensions/dpms.h... yes checking for DPMSQueryExtension in -lXext... yes checking for X11/extensions/Xfixes.h... yes checking for XFixesExpandRegion in -lXfixes... yes checking for X11/extensions/Xinerama.h... yes checking for XineramaQueryScreens in -lXinerama... yes checking for X11/extensions/Print.h... yes checking for XpQueryScreens in -lXp... yes checking for X11/extensions/Xrandr.h... yes checking for XRRGetScreenResourcesCurrent in -lXrandr... yes checking for X11/extensions/Xrender.h... (cached) yes checking for XRenderFindVisualFormat in -lXrender... yes checking for X11/extensions/XTest.h... yes checking for XTestFakeKeyEvent in -lXtst... yes checking for X11/extensions/scrnsaver.h... yes checking for XScreenSaverSelectInput in -lXss... yes checking for X11/extensions/XInput2.h... yes checking for XIQueryDevice in -lXi... yes if we detect it's pkg-config capable, just do EFL_DEPEND_PKG() as we do for xcb. Will cut us lots of calls to gcc to check these. Could you do this? :-) Thank you for you help! On Tue, Jan 8, 2013 at 11:22 PM, Joel Klinghed <th...@sp...> wrote: > On Tue, 8 Jan 2013 16:49:52 -0200 > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > On Mon, Jan 7, 2013 at 8:53 PM, Joel Klinghed <th...@sp...> > > wrote: > > > > > On Mon, 7 Jan 2013 20:39:26 -0200 > > > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > > > > > Hi Joel, > > > > > > > > This looks fine, one last question: why are these needed? > > > > > > > > =================================================================== > > > > --- src/Makefile_Ecore_Evas.am (revision 82364) > > > > +++ src/Makefile_Ecore_Evas.am (working copy) > > > > @@ -74,7 +74,8 @@ > > > > -I$(top_srcdir)/src/lib/ecore_x \ > > > > -I$(top_builddir)/src/lib/ecore_x \ > > > > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > > > > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > > > > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > > > > +@ECORE_X_CFLAGS@ > > > > modules_ecore_evas_engines_x_module_la_LIBADD = \ > > > > lib/ecore_evas/libecore_evas.la \ > > > > lib/ecore_x/libecore_x.la > > > > > > Without this I get: > > > > > > In file included from > > > modules/ecore_evas/engines/x/ecore_evas_x.c:22: > ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: > > > fatal error: 'X11/Xlib.h' file not found > > > > > > I assume this is the one you found. > > > > > > > ok, this was fixed today by raster. You can drop this from your > > patch :-) > > > > > > > Index: src/Makefile_Ecore_Imf.am > > > > =================================================================== > > > > --- src/Makefile_Ecore_Imf.am (revision 82364) > > > > +++ src/Makefile_Ecore_Imf.am (working copy) > > > > @@ -155,7 +155,8 @@ > > > > -I$(top_builddir)/src/lib/ecore_x \ > > > > -I$(top_srcdir)/src/lib/ecore_imf \ > > > > @ECORE_IMF_CFLAGS@ \ > > > > -@EFL_COV_CFLAGS@ > > > > +@EFL_COV_CFLAGS@ \ > > > > +@ECORE_X_CFLAGS@ > > > > modules_ecore_immodules_xim_xim_la_LIBADD = \ > > > > lib/ecore_imf/libecore_imf.la \ > > > > lib/ecore_x/libecore_x.la \ > > > > > > Without this I get: > > > modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: > > > 'X11/Xlib.h' file not found > > > > > > > this is really needed, but we shouldn't use ECORE_X_CFLAGS. > > > > Rather we need to find out XIM requirements and do another > > CFLAGS/LIBS pair. > > > > >From what it seems to be: > > #include <X11/Xlib.h> > > #include <X11/Xlocale.h> > > #include <X11/Xutil.h> > > > > The symbols seems to be all in libX11.so > > > > Would you do this? > > > > If I'm not asking enough, a last desire would be: could you please add > > support for Xlib .pc files? :-) > > > > Damn you for getting me to do this ;) > > Changelog from the last patch: > * Removed ECORE_X_CFLAGS from evas_ecore_x > * Split out ecore_imf_xim to do its own check > * Fixed problem with xcb:s makekeys, no rule for > $(top_builddir)/src/utils/ecore/makekeys$(EXEEXT) exists so make > used an implicit rule (ignoring any cflags of course) > * Fixed gl_x11 engine to build with either Xlib or XCB (xcb flags were > missing) > * Added EFL_FIND_X and replace any used of AC_PATH_X{,TRA}. > First looks for Xorg pkg-config files then if those arn't found it > falls back to old AC_PATH_X. Also generalized common header and lib > checks. > Could probably use some polishing (the AC_CACHE_VAL cruft especially) > but this is what I have time for tonight. > > /Joel Klinghed > > > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Joel K. <th...@sp...> - 2013-01-10 01:10:41
Attachments:
efl-configure-1.patch
|
On Wed, 9 Jan 2013 14:49:07 -0200 Gustavo Sverzut Barbieri <bar...@pr...> wrote: > committed as it will help you, but would be nice to simplify even > further. > > >From logs: > checking how to find X... use pkg-config > checking for EFL_X11... yes > checking X11/X.h usability... yes > checking X11/X.h presence... yes > checking for X11/X.h... yes > checking for evas_engine_software_xlib... yes > checking for XCreateImage... yes > checking for XShmCreateImage... yes > ... > checking how to find X... (cached) already found > checking X11/Xlib.h usability... yes > checking X11/Xlib.h presence... yes > checking for X11/Xlib.h... yes > checking X11/Xatom.h usability... yes > checking X11/Xatom.h presence... yes > checking for X11/Xatom.h... yes > checking X11/Xutil.h usability... yes > checking X11/Xutil.h presence... yes > checking for X11/Xutil.h... yes > checking X11/extensions/Xrender.h usability... yes > checking X11/extensions/Xrender.h presence... yes > checking for X11/extensions/Xrender.h... yes > checking X11/Xresource.h usability... yes > checking X11/Xresource.h presence... yes > checking for X11/Xresource.h... yes > checking for evas_engine_gl_xlib... yes > checking for XCreateColormap... yes > checking for XRenderCreatePicture... yes > > if using pkg-config, do not check any of header of symbols. > > Situation with Ecore_X is also the same: > checking how to find X... (cached) already found > checking for X11/Xlib.h... (cached) yes > checking X11/Xcursor/Xcursor.h usability... yes > checking X11/Xcursor/Xcursor.h presence... yes > checking for X11/Xcursor/Xcursor.h... yes > checking for ECORE_X_XLIB... yes > checking for XOpenDisplay... yes > checking for XcursorImageLoadCursor... yes > checking for X11/extensions/XKB.h... yes > checking for XkbSetDetectableAutoRepeat in -lX11... yes > checking for X11/extensions/Xcomposite.h... yes > checking for XCompositeQueryExtension in -lXcomposite... yes > checking for X11/extensions/Xdamage.h... yes > checking for XDamageSubtract in -lXdamage... yes > checking for X11/extensions/dpms.h... yes > checking for DPMSQueryExtension in -lXext... yes > checking for X11/extensions/Xfixes.h... yes > checking for XFixesExpandRegion in -lXfixes... yes > checking for X11/extensions/Xinerama.h... yes > checking for XineramaQueryScreens in -lXinerama... yes > checking for X11/extensions/Print.h... yes > checking for XpQueryScreens in -lXp... yes > checking for X11/extensions/Xrandr.h... yes > checking for XRRGetScreenResourcesCurrent in -lXrandr... yes > checking for X11/extensions/Xrender.h... (cached) yes > checking for XRenderFindVisualFormat in -lXrender... yes > checking for X11/extensions/XTest.h... yes > checking for XTestFakeKeyEvent in -lXtst... yes > checking for X11/extensions/scrnsaver.h... yes > checking for XScreenSaverSelectInput in -lXss... yes > checking for X11/extensions/XInput2.h... yes > checking for XIQueryDevice in -lXi... yes > > if we detect it's pkg-config capable, just do EFL_DEPEND_PKG() as we > do for xcb. Will cut us lots of calls to gcc to check these. > > Could you do this? :-) > > Thank you for you help! > Todays patch then. I removed the header, libs and functions checks when pkg-config is used. Started moving ECORE_X and ECORE_IMF_XIM to use EFL_LIB_START ... ended up doing the same with all the evas_engines - I might have gone a bit overboard here but it is more consistent... Anyway, it works for me, compile tested (./configure && make gave no error) X11, XCB and SDL, all with GL and with and without pkg-config. /Joel Klinghed > > On Tue, Jan 8, 2013 at 11:22 PM, Joel Klinghed <th...@sp...> > wrote: > > > On Tue, 8 Jan 2013 16:49:52 -0200 > > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > > > On Mon, Jan 7, 2013 at 8:53 PM, Joel Klinghed <th...@sp...> > > > wrote: > > > > > > > On Mon, 7 Jan 2013 20:39:26 -0200 > > > > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > > > > > > > > > Hi Joel, > > > > > > > > > > This looks fine, one last question: why are these needed? > > > > > > > > > > =================================================================== > > > > > --- src/Makefile_Ecore_Evas.am (revision 82364) > > > > > +++ src/Makefile_Ecore_Evas.am (working copy) > > > > > @@ -74,7 +74,8 @@ > > > > > -I$(top_srcdir)/src/lib/ecore_x \ > > > > > -I$(top_builddir)/src/lib/ecore_x \ > > > > > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > > > > > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > > > > > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > > > > > +@ECORE_X_CFLAGS@ > > > > > modules_ecore_evas_engines_x_module_la_LIBADD = \ > > > > > lib/ecore_evas/libecore_evas.la \ > > > > > lib/ecore_x/libecore_x.la > > > > > > > > Without this I get: > > > > > > > > In file included from > > > > modules/ecore_evas/engines/x/ecore_evas_x.c:22: > > ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: > > > > fatal error: 'X11/Xlib.h' file not found > > > > > > > > I assume this is the one you found. > > > > > > > > > > ok, this was fixed today by raster. You can drop this from your > > > patch :-) > > > > > > > > > > Index: src/Makefile_Ecore_Imf.am > > > > > =================================================================== > > > > > --- src/Makefile_Ecore_Imf.am (revision 82364) > > > > > +++ src/Makefile_Ecore_Imf.am (working copy) > > > > > @@ -155,7 +155,8 @@ > > > > > -I$(top_builddir)/src/lib/ecore_x \ > > > > > -I$(top_srcdir)/src/lib/ecore_imf \ > > > > > @ECORE_IMF_CFLAGS@ \ > > > > > -@EFL_COV_CFLAGS@ > > > > > +@EFL_COV_CFLAGS@ \ > > > > > +@ECORE_X_CFLAGS@ > > > > > modules_ecore_immodules_xim_xim_la_LIBADD = \ > > > > > lib/ecore_imf/libecore_imf.la \ > > > > > lib/ecore_x/libecore_x.la \ > > > > > > > > Without this I get: > > > > modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: > > > > 'X11/Xlib.h' file not found > > > > > > > > > > this is really needed, but we shouldn't use ECORE_X_CFLAGS. > > > > > > Rather we need to find out XIM requirements and do another > > > CFLAGS/LIBS pair. > > > > > > >From what it seems to be: > > > #include <X11/Xlib.h> > > > #include <X11/Xlocale.h> > > > #include <X11/Xutil.h> > > > > > > The symbols seems to be all in libX11.so > > > > > > Would you do this? > > > > > > If I'm not asking enough, a last desire would be: could you > > > please add support for Xlib .pc files? :-) > > > > > > > Damn you for getting me to do this ;) > > > > Changelog from the last patch: > > * Removed ECORE_X_CFLAGS from evas_ecore_x > > * Split out ecore_imf_xim to do its own check > > * Fixed problem with xcb:s makekeys, no rule for > > $(top_builddir)/src/utils/ecore/makekeys$(EXEEXT) exists so make > > used an implicit rule (ignoring any cflags of course) > > * Fixed gl_x11 engine to build with either Xlib or XCB (xcb flags > > were missing) > > * Added EFL_FIND_X and replace any used of AC_PATH_X{,TRA}. > > First looks for Xorg pkg-config files then if those arn't found it > > falls back to old AC_PATH_X. Also generalized common header and > > lib checks. > > Could probably use some polishing (the AC_CACHE_VAL cruft > > especially) but this is what I have time for tonight. > > > > /Joel Klinghed > > > > > > > > ------------------------------------------------------------------------------ > > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, > > jQuery and much more. Keep your Java skills current with > > LearnJavaNow - 200+ hours of step-by-step video tutorials by Java > > experts. SALE $49.99 this month only -- learn more at: > > http://p.sf.net/sfu/learnmore_122612 > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > |
From: Gustavo S. B. <bar...@pr...> - 2013-01-16 22:21:42
|
On Wed, Jan 9, 2013 at 10:40 PM, Joel Klinghed <th...@sp...> wrote: > On Wed, 9 Jan 2013 14:49:07 -0200 > Gustavo Sverzut Barbieri <bar...@pr...> wrote: > >> committed as it will help you, but would be nice to simplify even >> further. [...] > Todays patch then. I removed the header, libs and functions checks when > pkg-config is used. > Started moving ECORE_X and ECORE_IMF_XIM to use EFL_LIB_START ... > ended up doing the same with all the evas_engines - I might have gone a > bit overboard here but it is more consistent... > Anyway, it works for me, compile tested (./configure && make gave no > error) X11, XCB and SDL, all with GL and with and without pkg-config. Hi Joel, Sorry but I moved on with configure.ac and forgot about this patch, could you provide a new patch considering the following comments: - do not abuse the EFL_LIB_* macros for internal modules, I plan to do some extra stuff with them later, such as automatic library and module reporting. Maybe do similar (likely simpler) versions for modules? It seems that it will be useful to make modules handling more standard and less error prone. Check if it's feasible to do with a small subset, if we end doing replicating the whole thing, then better keep your way. - use the m4_ prefixed macros (popdef, pushdef..) - don't do AC_DEFINE([ECORE_[]UP], [0], [Build support for $1]) for every module, as the code checks for "#ifdef" not #if" - rename ECORE_ADD_X_EXTENSION -> XLIB? Maybe add a start/end so we can remove those variables and loops from the configure.ac... Although it improved a lot with your patch, this X handling is still too-exposed. If we could shrink it to something like XCB then it would be awesome. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |