Xorg 7.1 - Finally Up - and GCC notes

Kevin Day thekevinday at gmail.com
Fri Jun 30 02:05:46 PDT 2006


Contains any notes I made during the process of getting it to work.

I have only 1 test left to try, and that is 3d-accel.  I cannot seem to
get "permission" to enable 3daccel while running on host OS that has
gdm and a windowmanager running. So I once the remainder of my system
gets auto-installed, I will then try to get 3daccel working and report
any findings.

Okay, so I decided to fall back to gcc-3.4.6
And was proven that the gcc version had absolutely nothing to do with
the problem. In fact, there were only three obvious differences between
the compilers (3.4.6 & 4.1.1).
1) -ffast-math problem exists on 4.1.1 (hopefully resolved in 4.2.0)
2) 3.4.6 requires the find program from findutils whereas 4.1.1 no
longer uses it. (I noticed when I switched back that I had forgotten to
install findutils in my toolchain and 3.4.6 would not compile, but
4.1.1 would)
3) The specs file is hardcoded into gcc-4.1.1. (at least by default now)

Now, in order to find the problem, Xorg failed in all manners to help.
First, the screen goes blank.  Once that happens, and Xorg crashes for
some reason, it doesn't always like to give the screen back.  Which
causes problems.
My solution to this was to have links & DirectFB installed (may work
with normal FB graphical mode as well).  I compiled links with
graphical mode enabled.  By blindly switching to a terminal
Ctrl+Alt+F2, I was able to login.  With some luck, I made it past the
login, and typed 'links -g'.  This 'links -g' program retook control of
the monitor and returned it to me so that I could see once again.

Once I had the monitor back, I was able to find the real problem.  Xorg
does not log errors that happen when it fails to get a dlloadable
"object" (thus missing symbol errors..).  Instead, it outputs it to the
screen. Xorg also does not give the screen back to see the user,
resulting in a black screen of death :)

Toying around with setting up module loading in Xorg's config file, I
was able to reproduce this bug. This occurs when Xorg doesn't understand
dependencies that are required for some modules.  Take "exa", if I add
Load "exa" to the modules list, you will get the black screen of death,
that I described above. (apparently, it is supposed to Load "fb" before
"exa". The auto-load for "exa" properly detects the needed dependency,
but the manually added 'Load "exa"' fails to detect that it needs
'Load "fb"', and Xorg fails in many ways as far as documentation
goes to make any easily findable notes on this..

With some very quick observation, I can see this as a possible security
problem whereas a local/remote user, program, or script can cause the
local users screen to black on the user, if the user/app/script can gain
access to the "monitor resource".  But I might be pushing it on that
thought.

Back to the problem at hand, libglx.so was failing to load the symbol
'_glapi_tls_context'.  Apparently, Xorg fails to detect whether or not
this symbol exists when --enable-glx-tls is passed.  Changing it to
--disable-glx-tls I was able to glx.so to properly load.

As a side-note, I am staying with 3.4.6 simply due to convenience of
already being installed. However, I have noticed that gcc-4.2.0 is
planned to have a compiler option that allows for passing
-march=generic or something like that. (AKA safe optimizations).
With any luck the -ffast-math bug will be removed in gcc-4.2.0.



More information about the hlfs-dev mailing list