On Thu, 26 Sep 2013 15:02:31 +0900 Cedric BAIL <cedric.b...@free.fr> wrote:
> On Thu, Sep 26, 2013 at 12:55 AM, David Seikel <onef...@gmail.com> > wrote: > > On Thu, 26 Sep 2013 00:04:23 +1000 David Seikel <onef...@gmail.com> > > wrote: > >> On Wed, 25 Sep 2013 22:15:54 +0900 Cedric BAIL > >> <cedric.b...@free.fr> wrote: > >> > On Wed, Sep 25, 2013 at 9:14 PM, David Seikel <onef...@gmail.com> > >> > wrote: > >> > > On Wed, 25 Sep 2013 22:09:42 +1000 David Seikel > >> > > <onef...@gmail.com> wrote: > >> > > > >> > >> CCLD bin/ethumb_client/ethumbd_slave > >> > >> CCLD bin/ethumb_client/ethumbd > >> > >> CCLD bin/ethumb_client/ethumbd_client > >> > >> /opt/e17/lib/libevas.so.1: undefined reference to > >> > >> `eo_parent_get' /opt/e17/lib/libevas.so.1: undefined > >> > >> reference to `eo_parent_set' collect2: ld returned 1 exit > >> > >> status /opt/e17/lib/libevas.so.1: undefined reference to > >> > >> `eo_parent_get' /opt/e17/lib/libevas.so.1: undefined > >> > >> reference to `eo_parent_set' collect2: ld returned 1 exit > >> > >> status make[4]: *** [bin/ethumb_client/ethumbd_client] Error 1 > >> > >> make[4]: *** Waiting for unfinished jobs.... > >> > >> make[4]: *** [bin/ethumb_client/ethumbd_slave] Error 1 > >> > >> /opt/e17/lib/libevas.so.1: undefined reference to > >> > >> `eo_parent_get' /opt/e17/lib/libevas.so.1: undefined > >> > >> reference to `eo_parent_set' collect2: ld returned 1 exit > >> > >> status make[4]: *** [bin/ethumb_client/ethumbd] Error 1 > >> > >> make[3]: *** [all-recursive] Error 1 > >> > >> make[2]: *** [all] Error 2 > >> > >> make[1]: *** [all-recursive] Error 1 > >> > >> make: *** [all] Error 2 > >> > > > >> > > Cedric is to blame. Guess the rule still holds. B-) > >> > > >> > I am more on the PEBKAC on that case, but maybe you are using a > >> > different set of option when building efl than me. But there is > >> > something weird in your build system there. It should not be > >> > using something from your system when building ethumb binary. It > >> > should be using the library that are in your build directory. > >> > How do you build efl ? What does autofoo tell you when running > >> > autogen.sh ? > >> > >> I usually build from within a running E18, so that I may do other > >> things while it builds, so there is the old stuff still around > >> when I build the new stuff. Usually that works fine. > >> > >> So yes, ethumb build should be using the libraries it's in the > >> middle of building rather than the ones from the system. > >> > >> I'll just log out of X, clear out the old build, and build it from > >> scratch. Then find something else to do for a while. If I'm left > >> without a working E, then I'll blame Cedric again. :-P > > > > That did the trick, got a working E again. Let's hope the random > > crashes are fixed now. > > Ryuan found the issue and fixed it in our build system. So you should > not need to remove your system efl libraries to build a new version by > now. If it ever happen again, it's another bug to fix in our build > system. No PEBKAC after all. :-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
