Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
My guess is you are not getting the same error, but a similar error with a different file - there are several that need to be in /usr/include/GL, and the build fails when it finds the first one. So resolve that one (by copying it to /usr/include/GL), and then it will fail on the next one, and so on, until all the necessary headers are copied over.
But in any event, I don't recommend this approach anymore, I think editing the makefile is better. I can't look it up at the moment, but will post the modified makefile later. If you are in a rush, there are two lines in the Makefile in the xdemos directory that are of the form:
<command> <options> <name of c file>
The option -I$(TOP)/include needs to be added to the options list on both of them. This causes the compiler to look in the directory in the Mesalib source tree for the includes. Right now, it is looking only on the system, and they haven't been installed there yet.
If you can't work it out, and can't wait until I get a chance to post the modified Makefile, a quick-and-dirty solution is to copy all the header files from the Mesalib include directory to /usr/include/GL (or <XORG>/include/GL if you are not installing into /usr). But I am not sure if this results in copying something there, that shouldn't be there.
I've been following this thread with interest. At the moment this is beyond my experience, the current Development BLFS has a lot of newer package versions then when I installed it. I do start to think this is package version related.
If you decide to do so:
- Do make sure that there are no leftovers from the attempts with the 7.9 version.
- The build instructions for 7.8.2 could be different (for one: 7.8.2 does not have/need a patch). I would start with the instructions for 7.9 minus the patch -Np1 -i ../MesaLib-7.9-add_xdemos-1.patch && line and go from there. And don't forget to change the version number in the 2 install commands
I know I said before it looked like a bug in Mesalib, but I no longer think that is the case - it looks to me like an issue with the patch file.
The programs in xdemos need the header files like gl.h to compile, but the compile command in the Makefile assumes these headers are already installed within the search path of the system. But if it is the first time Mesalib is being compiled, then they won't be installed. This modification causes the compile to look within the Mesalib source tree for the header files (the other Makefiles in the Mesalib build already include an option to look for headers there).
The following are speculative (I haven't verified any of them):
(1) If Mesalib 7.9 has already been compiled and installed on this system, then this modification to the Makefile is not necessary, because the include files will already be in $XORG_PREFIX/include/GL (/usr/include/GL would be the default).
(2) If an old version of Mesalib had been installed, there might be some problem without the modification, because the programs in xdemos will be compiled with old versions of the header files.
(3) Building Mesalib-7.9 without the patch in the BLFS instructions would probably work, but then the tests couldn't be conducted.
(4) Building and installing Mesalib-7.9 without the patch first, then rebuilding and reinstalling with the patch, would probably work, since it is a special case of (1).
Again, the above are my predictions; I haven't verified them.
I ran into the same problem, and did a Google, which brought me to this board and thread, the contents of which did help me figure things out I've now got a fully installed X system, but it isn't working very well (can't CTL-ALT-backspace out of the X -retro command), and when I do manage to get out of X, the screen doesn't revert back to text mode properly
Last edited by Coelacanth; 04-09-2011 at 04:22 AM.
I've now got a fully installed X system, but it isn't working very well (can't CTL-ALT-backspace out of the X -retro command), and when I do manage to get out of X, the screen doesn't revert back to text mode properly
That is the (new) default behaviour. Add the following to your xorg.conf to enable the old behaviour: