On Thu, 12 Apr 2012 14:54:53 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> On Thu, 12 Apr 2012 14:18:04 +1000 David Seikel <[email protected]> > said: > > > On Thu, 12 Apr 2012 14:07:20 +1000 David Seikel <[email protected]> > > wrote: > > > > > On Thu, 12 Apr 2012 12:57:10 +0900 Carsten Haitzler (The > > > Rasterman) <[email protected]> wrote: > > > > > > > On Thu, 12 Apr 2012 11:43:20 +1000 David Seikel > > > > <[email protected]> said: > > > > > > > > > Starting from line 6048 of evas_object_textblock.c there is a > > > > > macro defined BREAK_AFTER, that, in the absence of > > > > > HAVE_LINEBREAK, refers to a non existant "str" array. Yep, > > > > > I'm trying to compile it on an embedded system that has no > > > > > linebreak thingy (library?). > > > > > > > > liblinebreak is there in src/static_deps and compiled along with > > > > evas. > > > > > > Sooo, why am I getting two errors that str is not defined? > > > > > > Fact is that the no linebreak path IS broken. There is no str, I > > > think it means to use the text variable instead. I'm not so > > > familiar with that bit of code though, so it might be something > > > else. > > dont disable liblinebreak. keep it. it's part of the evas srctree. > you want it for intl suport. I don't need intl support either. Still does not get away from the fact that it's broken without it. The alternative macro looks like it will do just what I need, if it could only reference the correct variable. Tried that, and it compiled at least, gonna test it tomorrow. A three line macro used twice is WAAAAY smaller than an entire intl line break library that I just don't need. Don't think it will be too hard to fix either, but I'm just not familiar with that code. And yes, I've even stubbed out gettext, that's how little I need intl. :-P > > Actually, in an effort to keep the embedded project small, I > > disable as much as I can, including liblinebreak. So that's why > > I'm going through that path. Which, as I said, is broken. > > > > While I'm bitching, evas wants to include wayland stuff in the > > build, so now I have to disable that to. This is in my embedded > > system, not even X. I think that's where this error is coming from > > - > > have you looked at config.log ? it builds wayland_shm because it > requires no wayland libs. wayland_egl requires egl - which you > seemingly have or it wouldnt enable it. check config.log If I had any sort of GL, then I would not be getting that error, coz it's the lack of GL that the error is complaining about. I build the entire OS myself, it's got no GL. Right now I have no config.log to check for GL stuff, coz I just disabled all the wayland stuff to get it to compile, so I could move onto the next bit of autofoo breakage. > > In file included from evas_gl_private.h:3, > > from evas_gl_context.c:1: > > evas_gl_common.h:37:22: error: GL/gl.h: No such file or directory > > evas_gl_common.h:38:25: error: GL/glext.h: No such file or directory > > > > Coz the only GL that configure mentions is - > > > > Engines: > > Software Memory Buffer.....: yes > > Software X11...............: no (Xlib: no) (XCB: no) > > OpenGL X11.................: no (Xlib: no) (XCB: no) > > Software GDI...............: no > > Software DirectDraw........: no > > Direct3d...................: no > > OpenGL SDL.................: no > > > > OpenGL Cocoa...............: no > > Software Framebuffer.......: yes > > DirectFB...................: no > > PSL1GHT....................: no > > Software 8bit grayscale....: no > > Software 16bit ............: no > > Software 16bit X11.........: no > > Software 16bit Directdraw..: no > > Software 16bit WinCE.......: no > > Software 16bit SDL.........: no (primitive: no) > > Wayland Shm................: yes > > Wayland Egl................: yes > > > > Still wondering why the autofoo of so much of the current alpha > > wants to include Exotic.h when it's not been built. Hard for me to > > debug that at the moment. I just patch it out for now. I'm taking a wild guess that the autofoo took one look at my qemu pretending to be a x486 compile environment, says WTF, and thinks it's exotic. Still, why should it bother trying to include Exotic.h, when Exotic is not even installed? Exotic is still in PROTO, a release tarball should NOT be depending on it for no apparent reason. The edje autofoo was also thinking it should install multisense and ALL it's friends, though I had none of that on this OS either. Sure, alsa is in the kernel, but no alsa development stuff, no remix, vorbis, or any of that other stuff is anywhere near this OS. Been up since yesterday, I'll sleep soon, and make a full report later. Seems to be a general lack of autofoo doing the right thing in the absence of stuff it's supposed to be checking for. That's kinda what autofoo is FOR. Still trying to figure out why the embedded system can't link my app to ecore_exe stuff, though happily links to the rest of ecore. You can't even disable ecore_exe, and I actually need it. lol -- 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
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
