[blfs-dev] Xorg Chapter

Armin K. krejzi at email.com
Wed Aug 22 04:23:02 PDT 2012

On 08/21/2012 01:28 AM, Armin K. wrote:
> Hey guys, as you may know dj made big upgrade by removing the wget files
> and provided instructions to make ones in order to simplify upgrades. He
> also included loops as default there with an option to choose a method
> how to install package by introducing AS_ROOT var.
> There is, however, one small problem.
> when running su -c make install, bash -e shell will exit on error
> because that command is incorrect - it would try to run "make" as user
> "install" ... It should be su -c "make install". I am unsure tough if
> "make install" would do any harm if run like that with sudo or without
> any prefix command.
> I also noticed that "Xorg Libraries" page has still sudo hardcoded at
> the end of the loop ->  sudo /sbin/ldconfig . Should we use AS_ROOT there
> too? It is not really necesary when prefix is /usr, but it is when
> prefix is something else than /usr. This will also make bash -e shell
> exit on error if sudo is not present, even tough if AS_ROOT is not set
> or is set as su -c (which doesn't work very well just yet).
> Now regarding MesaLib ...
> MesaLib is not part of Xorg release, but it is required and used by Xorg
> Server/Drivers specificaly. I don't know if anyone remembers, but there
> were two issues on blfs-support list where MesaLib was not installed in
> /usr and it break some packages.
> There is also another issue which Bruce had with Freeglut tests and
> prefix other than /usr.
> But since the MesaLib is not part of Xorg Release and it can be used by
> different versions, plus it is very well known that GL api hasn't
> changed for years, only DRI/Gallium drivers were improved, I suggest we
> install MesaLib, libdrm and Freeglut in /usr by default.
> Do note, however, that we already symlink GL headers into /usr/include
> from $XORG_PREFIX/include and that already makes it "not seperate".
> It would also help binary drivers (which assume DRI drivers are
> installed in /usr/lib/dri and libGL.so.1 is installed in /usr/lib) to
> work flawlessly on BLFS (I know that we don't officially support them,
> but we shouldn't break them, either). Symlinks and additional
> configuration are needed if prefix is anything else.
> I would also like to add here a note about LLVM dep and MesaLib itself.
> LLVM may not be heavy dep for MesaLib, but it is dependency by default
> unless different instructions are used (I set it to recommended because
> there were complaints). LLVM is used by Radeon r300 and r600 gallium
> drivers as well as llvmpipe driver, which is gallium swrast - it
> outperforms older DRI swrast in most cases.
> So in order to satisfy everyone, I'll set it as required if I upgrade
> MesaLib. MesaLib 8.1 should've been released at half of August, but it
> was delayed, and instead it will be MesaLib 9.0 because it will probably
> bring OpenGL 3.1 support. For anyone interested in this, there is a mail
> on freedesktop mailing lists.
> http://lists.freedesktop.org/archives/mesa-dev/2012-August/025478.html
> For anyone that wants to complain about LLVM being hard dep (yes it is a
> pain to build) because you don't use it (intel or nvidia users), feel
> free to modify instructions for yourself dropping llvm dependency. (I
> put this just for reference in the future).
> MesaLib 9.0 should be branched soon (it should've been today acording to
> the mail) and I will make necesary preparations. I noticed they migrated
> to autotools for most of their stuff, so I guess we would need to modify
> patches. I've also enabled some instructions that are now enabled by
> default in MesaLib dev, like shared glapi and shared dricore so we could
> test if something goes wrong.
> Again, if anyone elsee is interested in MesaLib upgrade, please speak. I
> will look forwared to bring it as soon as possible in the BOOK (as soon
> as it is released maybe) because it holds on new libdrm (because of
> nouveau stuff being rewritten in 2.4.34) which also holds new Xorg
> drivers - Intel, Radeon and Nouveau ones.
> Sorry for the typos, mail got longer than I expected.

I would appreciate if some of the devs replied at least to the MesaLib 
prefix thing, since I'd like to hear different opinions.

More information about the blfs-dev mailing list