Problem compiling xfree86

Steven Michalske michalsc at
Wed Mar 26 10:54:16 GMT 2003

Hash: SHA1

On Wednesday 26 March 2003 7:44 am, Nick Hudson wrote:
> -------Original Message-------
> From: Grigorios Prasinos <green at>
> Sent: 03/26/03 08:16 AM
> To: "Lunar Linux Mailing List! (all are welcome)" <lunar at>
> Subject: Re: Problem compiling xfree86
> > Hello again
> >
> >Thanks for the reply.
> >If I understand correctly it seems that I can
> >safely ignore the "Unresolved symbols" messages (my xfree86 seem >to run
> >well anyway). My card is an Ati mobility radeon 7500.
> Yeah you can safly ignore those and just install the correct DRI module for
> your card.  I dont have a DRI/DRM based card so i really dont know which
> one it would be. Let me know if you cant get that to work.
> >As for the configure options, I don't want to do anything >special, I
> >just ask so as to know how much control (or trouble!) I can have >when
> >I install a module. I'm satisfied with the options lunar passes
> >automatically.
> Well the only way to do that is just put it into the BUILD script of each
> module, I hate to say that but that is the only way atm.
that is not true there is a localsa config feature that was put in  i dont use 
that but it is avaliable,  others that use it or know how it works please 

> >However I do not like the idea of having a 10gb partition for >lunar.
> >I can run a Mandrake installation with gnome etc. in under 2gb. >I
> >though that lunar, by being a lean and efficient distro could >live on
> >less space.
> Well Mandrake/RH can live on less space because the binary isnt optimized
> therefore its smaller in size.  Yes most of the time the rpm itself is
> bigger than the source in some cases the total binary is smaller.  Also you
> have a choice to install dev packages with rpms.  As for source you dont
> you get the whole package as one, with opts the binary gets bigger.  Also
> with RH/Mandrake it doesnt keep the rpm file on disk where Lunar and other
> source distros do.  Lunar for instance keeps a copy of the source in
> /var/spool/lunar and keeps a copy of each compiled package in
> /var/cache/lunar so really you have 2 coipes of each source on your disk
> which cuts down on space.  Lets say there are  7 source packages for X well
> altogether lets just say it totals up to 300 megs, well the compiled source
> in /var/cache/lunar  would be alot bigger lets say around 700 megs ... so
> in that case you have 300+700 is 1000 megs which is almost a gig of space
> taken up by one module.  Now another case is Mozilla.  Mozilla is  30+ megs
> as a source tarred up.  Now while its compiling the untarred source grows
> to over a gig of source code.  See now why you will need more than 2 gigs
> of space.  Im not saying it cant be done ... im just saying that you will
> run out of space real quick expecially when you have X and Gnome2/Mozilla
> installed.
> >Concering combreloc: I didn't have any problems so far (compiled
> >binutils, glibc, xfree86 with it) but I read on some forums that
> >its use may be problematic so I just wanted to know what is the
> >experience of the other lunar users.
> Well read Chucks email, seems he has problems with it with emacs.  I dont
> use emacs so I havent experienced any problems.
the emacs module removes combreloc so it is safe to turn on,  but dont try 
turning on options on a per module baises that we have turned off :-P

> >As for openmosix the "stable" moonbase does not have it... Maybe
> >a module is in development?
> Yeah its in our Dev or testing moonbase which is called "crater".  You can
> get it from cvs just checkout crater from cvs and look for it.
> >Thanks again for your reply,
> >-Grigoris Prasinos
> hth
> Nick Hudson
> _______________________________________________
> Lunar mailing list
> Lunar at
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the Lunar mailing list