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. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
