On Thu, Aug 21, 2014 at 01:46:23PM +0530, Hariharan wrote: > Hi Ken, > > " > By the time you are in BLFS, your host system should not matter, > because either you are in chroot after completing LFS, or else you > have booted your shiny new LFS. Or, are you doing somehting > different ? > " >
Can you fix how you reply to mails, please ? We don't like top-posting, and some of us get really annoyed by quoting without conventional '>' identifiers. Now that I'm replying, I can see you have put double quotes before and after my text, but they do not give my eyes the usual clues, no do they cause my mail client to colour the different levels of reply (normally, lines preceded by > are a different colour, >> a third, etc). > I can boot into LFS but I prefer using the chroot environment in the host > till I install a desktop environment(preferably Xfce). > That's ok. Your host should not be making any obvious difference to the result. > " > This is where the problem starts. Google thinks that happens if > you use a really old version of Python2 (less than 2.5). Or, I > suppose, perhaps you have not installed Python2 at all ? > " > I have Python2.7.8 and Python3.4 . I used Python3.4 . Also i when i built > libdrm-2.4.56 again, I noticed that the make and make install were > successful but make check failed two tests: > Mesa requires Python2. I know some people build Python3 early, but I always leave that until quite late in my build (libreoffice uses it, everything else I care about is Python2). I'm not quite sure what you mean by "I used Python3.4" ? But I think (details at the end) that this is the problem. For libdrm, I do not run tests, so I don't know if failures are normal. > PASS: getstats > ../build-aux/test-driver: line 107: 3163 Aborted (core > dumped) "$@" > $log_file 2>&1 > FAIL: setversion > ../build-aux/test-driver: line 107: 3183 Aborted (core > dumped) "$@" > $log_file 2>&1 > FAIL: updatedraw > PASS: name_from_fd > PASS: gem_basic > PASS: gem_flink > PASS: gem_readwrite > PASS: gem_mmap [...] > ============================================================================ > Testsuite summary for libdrm 2.4.56 > ============================================================================ > # TOTAL: 11 > # PASS: 9 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 2 > # XPASS: 0 > # ERROR: 0 > > Could that be a possible reason?? Xorg libraries compiled and built fine > though. > Google found https://www.libreoffice.org/bugzilla/show_bug.cgi?id=77269 (I have no idea why it is in the libreoffice bugzilla!) which seems similar. I think it is probably harmless. [snipping the bottom-posted original, except for the actual error - so that I can find what it was, for review ] > > > Entering directory '/sources/xc/Mesa-10.2.5/src/mapi' CC > > > shared_glapi_libglapi_la-mapi_glapi.lo../../src/mapi/mapi_glapi.c: In > > > function > > > '_glapi_get_dispatch_table_size':../../src/mapi/mapi_glapi.c:34:31: > > error: > > > 'MAPI_TABLE_NUM_STATIC' undeclared (first use in this function) #define > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I also found http://comments.gmane.org/gmane.comp.video.mesa3d.devel/62277 where the missing header is apparently defined in src/mapi/shared-glapi/glapi_mapi_tmp.h which is generated at build time. My Mesa build on this machine (intel) is slightly different from the book (I don't have llvm, so I drop the r300 ... radeonsi drivers) and that file gets created during the build, not by autogen.sh. On mine, that file is over 28000 lines long. At line 1165, after a lot of void APIENTRY lines is #undef MAPI_TMP_DEFINES #endif /* MAPI_TMP_DEFINES */ #ifdef MAPI_TMP_TABLE #define MAPI_TABLE_NUM_STATIC 1152 #define MAPI_TABLE_NUM_DYNAMIC 256 #undef MAPI_TMP_TABLE #endif /* MAPI_TMP_TABLE */ So this get defined if MAPI_TMP_TABLE is defined. That, for me, is in src/mapi/table.h in an unconditional block after the Copyright: * Authors: * Chia-I Wu <[email protected]> */ #ifndef _TABLE_H_ #define _TABLE_H_ #include "u_compiler.h" #include "entry.h" #define MAPI_TMP_TABLE #include "mapi_tmp.h" #define MAPI_TABLE_NUM_SLOTS (MAPI_TABLE_NUM_STATIC + MAPI_TABLE_NUM_DYNAMIC) #define MAPI_TABLE_SIZE (MAPI_TABLE_NUM_SLOTS * sizeof(mapi_func)) I have to assume that somehow in your build either the define of MAPI_TMP_TABLE is not included (that seems very unlikely), or that it is indeed a python problem. When I looked for MAPI_TMP_TABLE I got the following results: ken@jtm1 /scratch/ken/Mesa-10.2.5 $find . -type f | xargs grep MAPI_TMP_TABLE ./src/mapi/shared-glapi/glapi_mapi_tmp.h:#ifdef MAPI_TMP_TABLE ./src/mapi/shared-glapi/glapi_mapi_tmp.h:#undef MAPI_TMP_TABLE ./src/mapi/shared-glapi/glapi_mapi_tmp.h:#endif /* MAPI_TMP_TABLE */ ./src/mapi/vgapi/vgapi_tmp.h:#ifdef MAPI_TMP_TABLE ./src/mapi/vgapi/vgapi_tmp.h:#undef MAPI_TMP_TABLE ./src/mapi/vgapi/vgapi_tmp.h:#endif /* MAPI_TMP_TABLE */ ./src/mapi/table.h:#define MAPI_TMP_TABLE ./src/mapi/mapi_abi.py: print '#ifdef MAPI_TMP_TABLE' ./src/mapi/mapi_abi.py: print '#undef MAPI_TMP_TABLE' ./src/mapi/mapi_abi.py: print '#endif /* MAPI_TMP_TABLE */' ken@jtm1 /scratch/ken/Mesa-10.2.5 $view src/mapi/table.h so it seems that mapi_abi.py is what generates that file. It is a straight python2 script invoked as #!/usr/bin/env python What do you get for python --version ? You should get Python 2.7.8 ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
