On Fri, 03 Jan 2014 14:00:17 -0700 Jonathan <[email protected]> said:
> Since this is such a common problem, wouldn't it be worthwhile to have a > script called by configure, which looks for old versions of libraries, > and fails if it finds them? because trying to be too "smart" and holding hands this way invariably breaks packaging systems where the packager does know what they are doing. it also means we have to work around developers who DO knwo what they are doing. i have installed multiple efl installs before for good reasons... but i know i'm doing it. > Isn't this what pkg-config and the like are for? To look for minimum > versions of libraries, where they're installed, etc? It seems like it > would be worthwhile to investigate using it to prevent errors like this. > It's not as if this is the only project with these problems to solve. pkg-config will only find 1 version not multiple. the first one it finds based on PKG_CONFIG_PATH or built-in defaults. we have to re-invent the wheel here - we have to detect and then check it's an install in a DIFFERENT location which pkg-cofng does tell us - we have to IMPLY it from --cflags strngs or --libs strings and parse them ala the c compiler and guess based on cflags -I paths or -L option paths as an install into the SAME location is valid and something we developers do all day, every day. > If re-inventing the wheel is your thing, perhaps a pre-build script > checking the library cache for outdated versions using something like this: > > ldconfig -p | grep libeina > > This would work to find any library in the ldconfig cache. It's not as > thorough as your command, but much quicker. And unless there's special > environment variables somewhere affecting the linker during build, it > should work just as well. you need much more than ldconfig - ldconfig is ONLY at runtime where it is run. if LD_LIBRARY_PATH is set differently when e runs then this will be invalid. there is ALSO the thing that linking at compile time has nothing to do with LD_LIBRARY_PATH or ldconfig at all - its done via link flags to the compiler/linker... :) so to make it all automagic to catch "silliness" we will end up making things harder and unexpected for those who do know what they are doing... :) > Jonathan > > On 14-01-02 05:19 PM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 2 Jan 2014 20:14:36 +0200 Michael Vara <[email protected]> said: > > > >> Oh now that was embarassing. I thought i had erased all e17 libraries when > >> i upgaded to e18 but there was a sneaky libeina.1.7.9 left under directory > >> /usr/lib/i386-linux-gnu, a directory which is included in the > >> /etc/ld.so.conf.d/i486-linux-gnu.conf file. I guess jessie changed > >> something and the system looked first at /usr/lib/i386-linux-gnu for the > >> requested libraries and picked the 1.7.9 version. > >> Many thanks for your help and also congrats to the people responsible for > >> terminology, it rocks :) > > aha! the multiple lib install bites... yet again. year after year people > > shuffle by with "e/efl doesn't build/work/is broken" comments and time and > > time again it's something like this. multiple lib installs, old headers or > > people going nuts with --enable/--disable etc. and using configuration > > combinations we just never test. that's why we have been steadily removing > > build options and making it harder to diverge. :) this is a note to > > everyone... if you have problems .. like this - stuff that is so stinkingly > > obviously broken and not working, there is a HIGH chance the problem is > > "pebkac" (problem exists between keyboard and chair). look for this kind of > > mess - multiple installs. and stop thinking "i know there is nothing". > > brute force search: > > > > find / -print | grep libeina.so > > > > (same for libevas.so, libeet.so, libedje.so etc. etc.). same for the header > > files. brute-force hunt them down. stuff in your build trees etc. won't > > matter but stuff that may be found by ld.so does. also remember setuid > > binaries IGNORE LD_PRELOAD and LD_LIBRARY_PATH environment vars for > > security reasons. so don't think that these magically solve everything. :) > > > > (in the following "you" is generic not specific to any special person) > > > > and if you are hyper-customizing with configure options... stop! just stop. > > read the README. it suggests SOME options you may need or want - stick to > > those. stop using xcb thinking it's amazingly better than xlib. it isn't. > > it's much more painful, long-winded and not tested with things like opengl > > (in fact doesn't work so we have to use a combo of xcb and xlib and that > > won't be tested by driver maintainers etc.). stop with the USE flags for > > customizing every minute aspect of an efl build. you think you are being > > clever. you are not. trust me. the very few people and use cases for such > > customizing know what they are doing - you do not. (only mess with > > configure flags that are not in the recommended list if you KNOW the code > > they affect and HOW, WHY etc. and YOU can actually hack on that code > > yourself and understand it. that is why i say that "you" do not know). > > > > hopefully this advice prompts some people to fix their packaging or build > > scripts or whatever... and perhaps some people will finally have a better > > more "working" experience as a result. :) > > > >> On Thu, Jan 2, 2014 at 2:10 AM, Carsten Haitzler > >> <[email protected]>wrote: > >> > >>> for whatever reason enlightenment_sys for YOU is not linked to eina or > >>> somehow > >>> symbols have been removed in your eina lib (_eina_log_state_shutdown was > >>> added > >>> march 2013 ... so LONG LONG LONG before efl 1.8 was out). > >>> > >>> check with ldd - but it should be linked to eina too as eo won't work > >>> without > >>> eina anyway... and eo itself should be linked to eina: > >>> > >>> $ ldd /usr/local/lib/libeo.so.1 > >>> linux-vdso.so.1 (0x00007ffffc1fa000) > >>> libeina.so.1 => /usr/local/lib/libeina.so.1 (0x00007f0321730000) > >>> libm.so.6 => /usr/lib/libm.so.6 (0x00007f03213fe000) > >>> libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f03211fa000) > >>> librt.so.1 => /usr/lib/librt.so.1 (0x00007f0320ff1000) > >>> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f0320dd3000) > >>> libc.so.6 => /usr/lib/libc.so.6 (0x00007f0320a28000) > >>> /usr/lib64/ld-linux-x86-64.so.2 (0x0000003000000000) > >>> > >>> $ ldd /usr/local/lib/enlightenment/utils/enlightenment_sys > >>> linux-vdso.so.1 (0x00007fffa3446000) > >>> libecore.so.1 => /usr/local/lib/libecore.so.1 > >>> (0x00007fa8e4223000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 > >>> (0x00007fa8e3ff2000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 > >>> (0x00007fa8e3cf2000) libeo.so.1 => /usr/local/lib/libeo.so.1 > >>> (0x00007fa8e3ade000) libeina.so.1 => /usr/local/lib/libeina.so.1 > >>> (0x00007fa8e3883000) libdl.so.2 => /usr/lib/libdl.so.2 > >>> (0x00007fa8e367f000) librt.so.1 => /usr/lib/librt.so.1 > >>> (0x00007fa8e3476000) libpthread.so.0 => /usr/lib/libpthread.so.0 > >>> (0x00007fa8e3258000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fa8e2f55000) > >>> libbluetooth.so.3 => /usr/lib/libbluetooth.so.3 (0x00007fa8e2d36000) > >>> libpam.so.0 => /usr/lib/libpam.so.0 (0x00007fa8e2b28000) libc.so.6 => > >>> /usr/lib/libc.so.6 > >>> (0x00007fa8e277d000) libpcre.so.1 => /usr/lib/libpcre.so.1 > >>> (0x00007fa8e2516000) > >>> /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 > >>> (0x0000003000000000) > >>> > >>> whatever has happened - something has gone wrong seeming at build time or > >>> packaging... as your libeo i guess is not linked against eina... OR if it > >>> is, > >>> the eina lib u have predates march 2013... which means its not efl 1.8... > >>> (maybe you have multiple eina libs installed? how have you gotten away > >>> with that? well multiple eina libs in different dirs? it's possible to do > >>> but with > >>> great care and frankly if you are asking these questions here... you're > >>> not the > >>> right person to be maintaining multiple instances of efl (eina or other > >>> things) > >>> across multiple dirs on your system as you'd know you have them and know > >>> how to > >>> make them work. :)). > >>> > >>> > >>>> thanks > >>>> Michael > >>>> > >>> ------------------------------------------------------------------------------ > >>>> Rapidly troubleshoot problems before they affect your business. Most IT > >>>> organizations don't have a clear picture of how application performance > >>>> affects their revenue. With AppDynamics, you get 100% visibility into > >>> your > >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > >>> AppDynamics Pro! > >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> enlightenment-users mailing list > >>>> [email protected] > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >>>> > >>> > >>> -- > >>> ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >>> The Rasterman (Carsten Haitzler) [email protected] > >>> > >>> > >> ------------------------------------------------------------------------------ > >> Rapidly troubleshoot problems before they affect your business. Most IT > >> organizations don't have a clear picture of how application performance > >> affects their revenue. With AppDynamics, you get 100% visibility into your > >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > >> Pro! > >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > >> _______________________________________________ enlightenment-users > >> mailing list [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
