[EGIT] [core/enlightenment] master 01/01: Fix configure option string
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=4c88b83fa6138e638aab6c57c08c9b2f106a6a07
commit 4c88b83fa6138e638aab6c57c08c9b2f106a6a07
Author: Ralph Sennhauser s...@gentoo.org
Date: Sat Jul 5 16:17:30 2014 +0200
Fix configure option string
enightenment-menu is install-enlightenment-menu
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index deaa278..f08f7d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -346,7 +346,7 @@ AM_CONDITIONAL(INSTALL_SYSACTIONS, test
x${e_cv_enable_install_sysactions} = xye
AC_MSG_CHECKING([whether to install enlightenment.menu])
AC_ARG_ENABLE([install-enlightenment-menu],
- AS_HELP_STRING([--disable-enlightenment-menu],[disable installing
/etc/xdg/menus/enlightenment.menu @:@default=enabled@:@]),
+ AS_HELP_STRING([--disable-install-enlightenment-menu],[disable installing
/etc/xdg/menus/enlightenment.menu @:@default=enabled@:@]),
[e_cv_enable_install_enlightenment_menu=$enableval],
AC_CACHE_VAL([e_cv_enable_install_enlightenment_menu],
[e_cv_enable_install_enlightenment_menu=yes]))
AC_MSG_RESULT([$e_cv_enable_install_enlightenment_menu])
--
Re: [E-devel] efl tree
On Sat, 13 Oct 2012 14:37:11 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: So again: Either force-disable/force-enable a feature or allow configure switches for it, automagic just causes more confusion and more work for packagers and users. more for packagers. less for users. users have their stuff mostly just work in terms of build. they may or may not have certain features and these are checked for later at runtime anyway, but we are making more core features not even able to be disabled in the efl tree anyway - so these wont need runtime checks as much but the rest is still automagic unless u enable the strict stuff as above - if you are a packager then go do that. :) Automatic deps are what you are talking about and all that David Seikel is after. Automagic deps is what Thomas Sachau is talking about. The difference is the former has a configure option the latter has not or the option is broken. This distinction of automatic vs automagic might be Gentoo specific, not sure others use it the same way or bother to make this distinction in the first place. Automatic deps, ie enable if dep is installed and the configure option is not given, is all fine and dandy and the packager is to blame if he misses the configure option. Automagic deps are harder to spot and need to be treated as hard dependencies in source based distros unless the packager patchs the build to add the missing configure option. Binary distros can indeed get away without it being a hard dep. Either way, automagic deps means 99% of the work for upstream, ie, properly ifdef the code and detect the dep and zero gain for a source based distros as Gentoo. About lld and friends, well, they make for great qa tools and and are extensively used in Gentoo as well, but are no substitute to declaring proper deps in the package spec (ebuild). It makes sense to autorecord missing ones for rpms, guess it helps greatly to reduce broken 3rd party rpms. On the topic of removing configure options, there are indeed silly ones and I welcome your plans to simply things. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Sun, 14 Oct 2012 11:40:36 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch wrote: Automagic deps are harder to spot and need to be treated as hard dependencies in source based distros unless the packager patchs the build to add the missing configure option. Binary distros can indeed get away without it being a hard dep. Either way, automagic deps means 99% of the work for upstream, ie, properly ifdef the code and detect the dep and zero gain for a source based distros as Gentoo. Who would have thought we have a document [1] describing the problem Thomas Sachau doesn't want to run into. [1] http://www.gentoo.org/proj/en/qa/automagic.xml -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/terminology/src/bin
On Mon, 6 Aug 2012 13:17:31 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: You can have multiple options for same variable. So --bg and --background. No -bg as I find this the worst idea ever why? cmdline apps have done this since the dawn of time. it's useful and handy - short and to the point. They usually start out wasting short options on things no one is going to use on the command line anyway just so every option has it's short form, then they are running short on letters and come up with the idea of two letter short options just to run into issues further down the road. '-bg' should be parsed as '-b -g' as this is the expected behaviour, otherwise '-gb' '-g -b' '-b -g' all do the same but '-bg' is special. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/terminology/src/bin
On Mon, 6 Aug 2012 16:46:36 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 6 Aug 2012 08:55:19 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch said: On Mon, 6 Aug 2012 13:17:31 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: You can have multiple options for same variable. So --bg and --background. No -bg as I find this the worst idea ever why? cmdline apps have done this since the dawn of time. it's useful and handy - short and to the point. They usually start out wasting short options on things no one is going to use on the command line anyway just so every option has it's short form, then they are running short on letters and come up with the idea of two letter short options just to run into issues further down the road. '-bg' should be parsed as '-b -g' as this is the expected behaviour, otherwise '-gb' '-g -b' '-b -g' all do the same but '-bg' is special. how is this expected behaviour? http://pubs.opengroup.org/onlinepubs/9699919799/ cmdline apps have done the kind of -bg thing and a single FULL option ever since i can remember using unix. look at xterm and rxvt's option list for starters. xorg's too (for ancient executables). mplayer (more modern), find (-depth or -d, .. -depth is the long form - not --depth).. as long as i can remember the ONLY thing that is common with options is that they almost all start with '-' and may or may not accept following arguments. All those use single hyphen long options consistently, usually with an additional --help so people wont end up doing something irreversible trying to read the help or are able to find it in the first place. You are suggesting to freely mix those long option styles. i'd argue that this is *NOT* expected behaviour. my experiences with unix (since 1994 anyway) are that you can't expect this kind of behaviour. RTFM if u want to know what to do .. at BEST guess options begin with '-' :) This is the lemmings argument and with it you can make a case for /bg just as well. Also you are completely leaving out the ambiguity argument I brought up. The --longopt style does address this, even so it's not classic unix and more of a gnuism. To sum up -bg is a long opt of a different style and a poor choice of name and it will clearly be --background which I'll remember if I RTFM. If you need the option 20 times a day any arbitrary letter will do just as fine, you still have more than 30 spare in terminology. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eyesight and mupdf : build a shared lib of mupdf or link mupdf statically against eyesight ?
On Mon, 30 Jul 2012 09:08:55 +0200 Vincent Torri vincent.to...@gmail.com wrote: hey On Mon, Jul 30, 2012 at 8:45 AM, Cedric BAIL cedric.b...@free.fr wrote: Yop, On Mon, Jul 30, 2012 at 2:55 PM, Vincent Torri vincent.to...@gmail.com wrote: I plan to update mupdf from 0.9 to 1.0. So i'm writing the build system for that version. As mupdf is not necessarly included in the distros, I integrate the mupdf source in eyesight and I build it. I'm now wondering if I should build a shared lib of mupdf and install it, or if i should statically link mupdf against the pdf module of eyesight. Basically: 1) integrate mupdf and its thirdparty package (which includes : libjpeg, freetype, openjpeg, jbig2dec and zlib), i build them and I statically link all that against the pdf module of eyesight 2) or I ask the user to have libjpeg, freetype, openjpeg, jbig2dec and zlib already installed, I build mupdf and I link mupdf statically against the pdf module of eyesight 3) or I ask the user to have libjpeg, freetype, openjpeg, jbig2dec and zlib already installed, I build mupdf as a shared lib and the pdf module will use the shared lib of mupdf. What is the best solution ? I think 2 will be better as it doesn't conflict at all with the distribution without getting insane and building 10 dependencies inside. ok, so it seems that 2) is the best. faster compilation in addition. Please have a configure option with-system-mupdf or similar for those distros which have mupdf in their repositories. Btw, i'll drop support of poppler, too much work. Mupdf is fast and lean, it's C. If it's missing features, i'll ask the devs to add them. Vincent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Screen resolution not remembered
On Wed, 9 May 2012 22:02:34 +0200 Andreas Volz li...@brachttal.net wrote: Hi, I bought a new 24 screen and it works well in 1920x1080 with E. But what ever I do each day after restart E it remembers 1680x1050 and I've to change resolution in the dialog. This is very annoying. Is this a known bug? regards Andreas This issue is old. 2 years maybe? Here E uses the resolution set by X at startup. The dialog works just fine to change the resolution but it won't stick ever. Possibly it's due to no consolekit or such. Cheers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Screen resolution not remembered
On Thu, 10 May 2012 13:34:03 -0500 Jeff Hoogland jeffhoogl...@linux.com wrote: In the latest E builds the resolution change does in fact stick past reboots now. Has for at least a month or so. I obviously missed that one. Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Scrolled_Entry Object and Events Handler
On Thu, 15 Sep 2011 08:51:29 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: 55255 is way old. latest version is 63400. to grt the full support of lastest features, please update it. 55255 is the latest snapshot, there is nothing to upgrade to ;) Daniel Juyung Seo (SeoZ) On Sep 15, 2011 7:20 AM, Paulo Benatto bena...@gmail.com wrote: -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.0 Release of core EFL
On Sat, 29 Jan 2011 12:43:25 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: Finally after a lkong time coming, we are pleased to announce the 1.0 release of the core EFL libraries (With the exception of Eet at 1.4). This has been many years coming. The following libraries have been released: * Eina - 1.0.0 * Eet - 1.4.0 * Evas - 1.0.0 * Ecore - 1.0.0 * Embryo - 1.0.0 * Edje - 1.0.0 * E_Dbus - 1.0.0 * Efreet - 1.0.0 * Eeze - 1.0.0 You can download the respective libraries from our Download Page: http://www.enlightenment.org/p.php?p=downloadl=en A long awaited moment. Congratulations to the whole team. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] getting svn revision in a simpler manner (in configure.ac)
On Sun, 17 Oct 2010 07:59:46 +0200 (CEST)
Vincent Torri vto...@univ-evry.fr wrote:
Hey,
instead of:
(svnversion ${SVN_REPO_PATH:-.} | grep -v export || echo 0) | awk
-F : '{printf(%s\n, $1);}' | tr -d ' :MSP\n'
why not using:
svn info |grep Revision | sed 's/Revision: //g'
Or maybe:
svn info -r HEAD | awk '/Revision/{print $2;}'
Requesting the HEAD revision is required to get the same result from
svn info all over the repository.
Cheers,
Ralph
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas built with threads enabled causes enlightenment to hang.
incompatible pointer type^M evas_engine.c:260: warning: assignment from incompatible pointer type^M evas_engine.c:261: warning: assignment from incompatible pointer type^M evas_engine.c: In function 'module_open':^M evas_engine.c:1554: warning: assignment from incompatible pointer type^M evas_engine.c:1577: warning: assignment from incompatible pointer type^M evas_image_load_png.c: In function 'evas_image_load_file_data_png':^M evas_image_load_png.c:154: warning: ignoring return value of 'fread', declared with attribute warn_unused_result^M make -j2 install DESTDIR=/var/tmp/paludis/media-libs-evas-/image/^M libtool: install: warning: remember to run `libtool --finish /usr/lib64'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/software_generic/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/buffer/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/software_16/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/software_16_x11/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/software_x11/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/engines/xrender_x11/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/loaders/eet/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/loaders/jpeg/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/loaders/png/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/loaders/bmp/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/loaders/tga/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/savers/eet/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/savers/jpeg/linux-gnu-x86_64-ver-pre-svn-06'^M libtool: install: warning: relinking `module.la'^M libtool: install: warning: remember to run `libtool --finish /usr/lib64/evas/modules/savers/png/linux-gnu-x86_64-ver-pre-svn-06'^M On Sun, 20 Jun 2010 15:34:56 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sat, 19 Jun 2010 23:14:49 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch said: i have it enabled and e works just fine. (async render in build - but not actually enabled runtime). if it can't be reproduced... it can't be debugged. so it works for me (tm). (ubuntu 10.04 32bit) Hi all, I use the live ebuilds from the efl repository to install enlightenment. When I enable the threads use flag enlightenment hangs at startup. Actually it's only the option --enable-async-render which when set causes the hang. The problem persists for at least 2 weeks. Some system informations to work with: Portage 2.1.8.3 (hardened/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.34-gentoo x86_64) = System uname: Linux-2.6.34-gentoo-x86_64-AMD_Athlon-tm-_64_Processor_3700 +-with-gentoo-1.12.13 Timestamp of tree: Sat, 19 Jun 2010 11:45:01 + distcc[22855] (dcc_trace_version) distcc 3.1 x86_64-pc-linux-gnu; built Sep 11 2009 17:38:40 [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 Back trace for threads use flag enabled: #0 0x7f05d37d4a9c
Re: [E-devel] Evas built with threads enabled causes enlightenment to hang.
On Sun, 20 Jun 2010 17:54:59 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 20 Jun 2010 09:43:26 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch said: i fixed the warnings, and 1 may be relevant on 64bit. not 32 though. The additional ones are gone. E still hangs. Thanks nonetheless. I found another warning which needs attention and is likely to cause problems on 64-bit systems and is probably not visible on a 32-bit system. It might be related or not, but certainly a potential source for segfaults. In e/src/modules/comp/e_mod_config.c e_mod_config.c: In function '_style_demo': e_mod_config.c:246: warning: cast from pointer to integer of different size e_mod_config.c:248: warning: cast to pointer from integer of different size It's the only one of this kind for enlightenment and all it's dependencies. la files are just for libtool - not debugging. i can get all the warnings myself too btw. :) if you can find out what the problem actually is - i am sure it can be fixed - but i don't see it (and no - i'm not going to go install gentoo and portage etc. etc. just to start trying - if i installed a new distro for every bug someone found i'f have 400+ of them installed by now :)). Even installing Gentoo and portage does not necessary mean you will be able to reproduce it. So I agree this is pointless. :) I posted to the list in hope to find others with the same issue, preferably an enlightenment developer. :) I my self am struggling to find the solution. but that bt there is a thread waiting to be woken up - ie the pthread condition to go true and let it continue and do things. why this is the case - that bt doesn't say. that involved finding out where every other thread is at and all the starts of things before and leading up to this condition. thats a lot of things that need to be looked at. Thanks for trying, If it were that easy to reproduce I guess it would have been fixed in the mean time. :) Enlightenment svn is an amazing repo for that matter. http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg25610.html looks somewhat similar. amd64, it says selinux disabled which probably means a hardened toolchain and the bt looks familiar. I do not have any la files as they get stripped by the ebuilds during installation. I'll see if I can narrow it further down. The pointer warnings could be relevant here. Any hints on where to start? I just realized attachments do no work. :) Full stderr log of the evas build with threads use flag enabled in the hope formatting wont get messed up to much: ^[[33;01m*^[[0m You have enabled both 'X' and 'xcb', so we will use^M ^[[33;01m*^[[0m X as it's considered the most stable for evas^M ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --enable-cpu-mmx --enable-cpu-sse --disable-cpu-altivec --enable-pthreads --enable-async-events --enable-async-preload --enable-async-render --enable-fontconfig --disable-fribidi --disable-evas-cserve --enable-cpu-c --enable-scale-sample --enable-scale-smooth --enable-convert-yuv --enable-buffer --disable-software-gdi --disable-software-ddraw --disable-direct3d --disable-quartz --disable-gl-glew --disable-directfb --disable-fb --disable-software-sdl --enable-software-xlib=yes --enable-xrender-x11=yes --enable-software-16-x11=yes --disable-software-xcb --disable-xrender-xcb --disable-gl-x11 --disable-software-16-ddraw --disable-software-16-wince --disable-image-loader-edb --enable-image-loader-eet=yes --enable-font-loader-eet=yes --disable-image-loader-gif --enable-image-loader-jpeg=yes --disable-image-loader-pmaps --enable-image-loader-png=yes --disable-image-loader-svg --disable-image-loader-tiff --disable-image-loader-xpm --enable-convert-8-rgb-332 --enable-convert-8-rgb-666 --enable-convert-8-rgb-232 --enable-convert-8-rgb-222 --enable-convert-8-rgb-221 --enable-convert-8-rgb-121 --enable-convert-8-rgb-111 --enable-convert-16-rgb-565 --enable-convert-16-rgb-555 --enable-convert-16-rgb-444 --enable-convert-16-rgb-rot-0 --enable-convert-16-rgb-rot-270 --enable-convert-16-rgb-rot-90 --enable-convert-24-rgb-888 --enable-convert-24-bgr-888 --enable-convert-32-rgb- --enable-convert-32-rgbx- --enable-convert-32-bgr- --enable-convert-32-bgrx- --enable-convert-32-rgb-rot-0 --enable-convert-32-rgb-rot-270 --enable-convert-32-rgb-rot-90 --enable-evas-magic-debug --disable-doc --disable-static --build=x86_64-pc-linux-gnu^M make -j2^M evas_callbacks.c: In function '_evas_post_event_callback_call':^M evas_callbacks.c:20: warning: passing argument 1 of 'pc-func' discards qualifiers from pointer target type^M evas_object_textblock.c: In function 'evas_textblock_style_set':^M evas_object_textblock.c:2580
Re: [E-devel] Evas built with threads enabled causes enlightenment to hang.
On Sun, 20 Jun 2010 19:47:41 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 20 Jun 2010 12:41:10 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch said: On Sun, 20 Jun 2010 17:54:59 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 20 Jun 2010 09:43:26 +0200 Ralph Sennhauser gentoo.s...@bluewin.ch said: i fixed the warnings, and 1 may be relevant on 64bit. not 32 though. The additional ones are gone. E still hangs. Thanks nonetheless. I found another warning which needs attention and is likely to cause problems on 64-bit systems and is probably not visible on a 32-bit system. It might be related or not, but certainly a potential source for segfaults. In e/src/modules/comp/e_mod_config.c e_mod_config.c: In function '_style_demo': e_mod_config.c:246: warning: cast from pointer to integer of different size e_mod_config.c:248: warning: cast to pointer from integer of different size It's the only one of this kind for enlightenment and all it's dependencies. it's safe. i knew i was casting a pointer. it will be fine on any number of bits :) (32,, 64.. or more). la files are just for libtool - not debugging. i can get all the warnings myself too btw. :) if you can find out what the problem actually is - i am sure it can be fixed - but i don't see it (and no - i'm not going to go install gentoo and portage etc. etc. just to start trying - if i installed a new distro for every bug someone found i'f have 400+ of them installed by now :)). Even installing Gentoo and portage does not necessary mean you will be able to reproduce it. So I agree this is pointless. :) correct. I posted to the list in hope to find others with the same issue, preferably an enlightenment developer. :) I my self am struggling to find the solution. well you can disable async rendering. that's a simple solution. :) Well I meant a proper solution. :) The only other thread has it's initial frame at 0. So this looks like a pointer issue somewhere. As all llvm warnings are going to be fixed anyway I hope this will be solved with it for now. Some gdb output: #0 0x7f65f37120e3 in ?? () #1 0x7f65f46ea86a in ?? () #2 0x7f65f53a57d8 in ?? () #3 0x3fa098c428f5c28f in ?? () #4 0x in ?? () Stack level 0, frame at 0x7fff2423c620: rip = 0x7f65f37120e3; saved rip 0x7f65f46ea86a called by frame at 0x7fff2423c628 Arglist at 0x7fff2423c610, args: Locals at 0x7fff2423c610, Previous frame's sp is 0x7fff2423c620 Saved registers: rip at 0x7fff2423c618 #4 0x in ?? () Stack level 4, frame at 0x7fff2423c640: rip = 0x0; saved rip 0x0 caller of frame at 0x7fff2423c638 Arglist at 0x7fff2423c630, args: Locals at 0x7fff2423c630, Previous frame's sp is 0x7fff2423c640 Saved registers: rip at 0x7fff2423c638 #0 0x7f599f0d1a9c in pthread_barrier_wait () from /lib/libpthread.so.0 #1 0x7f59a13b8bed in evas_common_pipe_image_load_do () at evas_pipe.c:1795 #2 0x7f59a13b911e in evas_common_pipe_map4_begin (root=0x7f59a372b410) at evas_pipe.c:1898 #3 0x7f5999800f7b in eng_output_redraws_next_update_push (data=0x7f59a35903c0, surface=0x7f59a372b410, x=0, y=0, w=32, h=32) at evas_engine.c:310 #4 0x7f59a1347fef in evas_render_updates_internal (e=0x7f59a35b58e0, make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1109 #5 0x7f59a13484fb in evas_render_updates (e=0x7f59a35b58e0) at evas_render.c:1249 #6 0x7f59a1893c9d in e_pointer_idler_before () at e_pointer.c:212 #7 0x7f59a186f173 in _e_main_cb_idler_before (data=0x0) at e_main.c:1570 #8 0x7f59a10c672d in _ecore_idle_enterer_call () at ecore_idle_enterer.c:132 #9 0x7f59a10c7f18 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:770 #10 0x7f59a10c706e in ecore_main_loop_begin () at ecore_main.c:166 #11 0x7f59a186dc91 in main (argc=1, argv=0x73c74698) at e_main.c:1109 Stack level 0, frame at 0x73c711b0: rip = 0x7f599f0d1a9c in pthread_barrier_wait; saved rip 0x7f59a13b8bed called by frame at 0x73c711c0 Arglist at 0x73c711a0, args: Locals at 0x73c711a0, Previous frame's sp is 0x73c711b0 Saved registers: rip at 0x73c711a8 #1 0x7f59a13b8bed in evas_common_pipe_image_load_do () at evas_pipe.c:1795 1795evas_pipe.c: No such file or directory. in evas_pipe.c Stack level 1, frame at 0x73c711c0: rip = 0x7f59a13b8bed in evas_common_pipe_image_load_do (evas_pipe.c:1795); saved rip 0x7f59a13b911e called by frame at 0x73c711f0, caller of frame at 0x73c711b0 source language c. Arglist at 0x73c711b0, args: Locals at 0x73c711b0, Previous frame's sp is 0x73c711c0 Saved registers: rbp at 0x73c711b0, rip at 0x73c711b8 #2 0x7f59a13b911e in evas_common_pipe_map4_begin (root=0x7f59a372b410) at evas_pipe.c:1898 1898in evas_pipe.c Stack level 2, frame
[E-devel] Evas built with threads enabled causes enlightenment to hang.
Hi all, I use the live ebuilds from the efl repository to install enlightenment. When I enable the threads use flag enlightenment hangs at startup. Actually it's only the option --enable-async-render which when set causes the hang. The problem persists for at least 2 weeks. Some system informations to work with: Portage 2.1.8.3 (hardened/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.34-gentoo x86_64) = System uname: Linux-2.6.34-gentoo-x86_64-AMD_Athlon-tm-_64_Processor_3700+-with-gentoo-1.12.13 Timestamp of tree: Sat, 19 Jun 2010 11:45:01 + distcc[22855] (dcc_trace_version) distcc 3.1 x86_64-pc-linux-gnu; built Sep 11 2009 17:38:40 [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 Back trace for threads use flag enabled: #0 0x7f05d37d4a9c in pthread_barrier_wait () from /lib/libpthread.so.0 #1 0x7f05d5a436cb in evas_common_pipe_map4_begin (root=0x7f05d7e9d480) at evas_pipe.c:1795 #2 0x7f05cdf0898e in eng_output_redraws_next_update_push (data=0x7f05d7d023d0, surface=0x0, x=0, y=-1, w=32, h=32) at evas_engine.c:310 #3 0x7f05d59f1bfb in evas_render_updates_internal (e=0x7f05d7d278d0, make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1109 #4 0x7f05d5efdec8 in e_pointer_idler_before () at e_pointer.c:212 #5 0x7f05d5ee1405 in _e_main_cb_idler_before (data=value optimized out) at e_main.c:1570 #6 0x7f05d5783dd3 in _ecore_idle_enterer_call () at ecore_idle_enterer.c:132 #7 0x7f05d57850dd in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:770 #8 0x7f05d578523f in ecore_main_loop_begin () at ecore_main.c:166 #9 0x7f05d5ee4b25 in main (argc=0, argv=0x7f05d7e76a70) at e_main.c:1109 Additional output to stderr with threads use flag enabled: evas_pipe.c:962: warning: conflicting types for 'evas_common_pipe_flush' evas_pipe.c:765: warning: previous implicit declaration of 'evas_common_pipe_flush' was here evas_pipe.c: In function 'evas_common_pipe_image_draw_do': evas_pipe.c:1499: warning: passing argument 1 of 'evas_common_rgba_image_scalecache_do' from incompatible pointer type evas_pipe.c:1542: warning: passing argument 1 of 'evas_common_rgba_image_scalecache_do' from incompatible pointer type evas_engine.c: In function 'eng_image_draw': evas_engine.c:780: warning: passing argument 1 of 'evas_common_rgba_image_scalecache_prepare' from incompatible pointer type Attached to the mail there are the full outputs to stderr of both builds of evas. If there is anything else I can provide to help find the problem please ask. Cheers. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
