As said, xorg looks for xorg.conf in /etc/X11 first - I know this because it tried to use my XF86Config-4 file and complained about a missing synaptics driver...
Although xorg finds the libs it needs when starting using startx, once started mini-apps like xclock complain about missing libs so I guess I will need to change the symlink X --> xorg to something like this:
I have a feeling that you wouldn't need the wrapper if it was the original symlink to hd for some reason...
Some notes: Isn't xorg, Xorg? (caps) Though I'm sure PATH will be set almost all the time, LD_LIBRARY_PATH usually is not, and although having a trailing : may work, perhaps checking if it's empty first or not will be better (and then setting the appropriate string).It seems to me that the wrapper is needed for the x apps that require libraries installed into /opt/xorg72/lib. Also, if i'm understanding what you said, LD_LIBRARY_PATH *might* be set by the user prior to running Xorg, so I think it's best to include a possible existing $LD_LIBRARY_PATH when it is set rather than risk accidentally breaking other apps. A check for an existing non-zero value (test -n or test -z, for example) will work as well, but a trailing colon will do no harm.If I check the contents of the library path after running xorg, but before running xclock, I get this:
Code Sample
#echo $LD_LIBRARY_PATH
#
Where the space is deliberate - i.e. the library path is either empty or contains <space> and/or <cr>.
If I check the contents of the path, I don't remember exactly what it shows, but I remember end of the entry is ".../opt/bin:." where there is a full stop after the semi-colon - I don't know if this is significant or not.The space is deliberate only because the echo command automatically adds a space to its output. If you were to use echo's "-n" parameter (echo -n $LD_LIBRARY_PATH), or used some other method of grabbing the variable, you would not see that space. Your personal LD_LIBRARY_PATH variable, as well as that of any other DSL user who hasn't changed it, is empty (or possibly unset, although the difference between empty and unset is not important in this case). My earlier point about appending rather than replacing the variable, even if it is usually empty, is important because even though your variable is empty, someone else's may not be. If you're creating something that will be distributed to other users you shouldn't make assumptions about things like this, particularly when avoiding a potential problem is a simple task.
The dot at the end of PATH is not a full stop. It's a dot, which represents the present directory. What it means is that no matter what directory you are in, that directory becomes part of PATH so you can run commands in that directory without preceding the command with "./" (while you're in that directory). I'm not really sure why this was done, especially considering many people claim this is a potential security issue. But at least the dot is at the end of PATH, so commands in ./ do not override system commands.
Also, I see you ran the echo command as root. Each user has a unique environment, so root's LD_LIBRARY_PATH is not going to be the same as dsl's LD_LIBRARY_PATH. If the application is run by dsl, root's environment has no influence over it.Next Page...
original here.