EUREKA!!!!Forum: DSL Ideas and Suggestions Topic: EUREKA!!!! started by: Fordi Posted by Fordi on Jan. 06 2005,06:06
I was just puttering around.I got the idea of making my personal DSL system look more like Windows - you know, just to see if it could be done. First, let me mention that there are very few - and not well-written - windows-alike file managers around (X-Plorer looks promising, but is, as yet, unavailable) Anyway, I came across FileGarden, which is a pretty good-looking filemanager, and I decided to try it out. Well, it installs itself entirely in opt, along with some libs. Part of the installation instructions was to add a line to /etc/ld.so.conf After further investigation, I discovered that you could store libraries ANYWHERE on your linux system, as long as that path was in that file. So, the solution? In the next version of DSL, have mountci add /opt/$APPNAME/lib to /etc/ld.so.conf and run ldconfig! With that, you don't even need to link the libs into the filesystem (the more one can limit this, the better)! *pant* *pant* Sorry, I'm getting too old for raving like a lunatic. *implements it in the squashfs.dsl I'm working on* Posted by ke4nt1 on Jan. 06 2005,06:47
That's a way-old-time cheat for us "older " linux guys..Problem is that ldconfig also sometimes screws with lib symlinks. Causing "unknown" issues with packages later on. And who wants your path to be running thru a dozen extra directories, possibly finding the WRONG copy of libGL.so.1, or libXft.so.2 , which links to an even older version of libXft.so, that corresponds to your package? A search from an application will simply stop at the first copy it finds, whether that copy corresponds to that app or not.. Uh Oh.. ( assuming your placing a copy of each needed lib in every installed-to-opt application, and then simply setting the ld.so.conf path to include that dir. ) I suggest you test your theory with many different installed extensions first.. One or two installed extensions may fly, but once you begin to mix gtk+ and gtk2, or different versions of perl, python, etc, then things get hairy. And I don't really want 10 copies of libXYZ in my ramspace anyway. Most of the contributed extensions were built by other users and individuals. They are not "integrated" to work with eachother, but remain as separate as possible, thus the .uci and .tar.gz extension methods. The same thing you are describing can be done with a simple shell wrapper, adding to the path for ONLY THAT SHELL the app runs in. When you exit the app, and the shell closes, the temporary path disappears, leaving your default path pristine and untouched.. There's no need to make a global filesystem change to the path statement. For an example, look at my qcad.tar.gz extension, which makes a nice .uci as well.. Look in the /opt/start_qcad file. You'll see the exported path statements for linking to libs within the extension, as well as exporting paths for python, WITHOUT using mkwritable on the filesystem or symlinking any files. Once you exit, your back to the pristine DSL build. Keep trying, and don't be hesitant to ask us questions. cbagger01, roberts, john, SU, mikshaw, many others, and myself are very familiar with DSL filesystems and the "layout of the land" . and all of us are eager to help guide you thru your personal builds... We'll be happy to show you the ropes, and teach/share what we can. 73 ke4nt Posted by Fordi on Jan. 06 2005,06:53
Hm... I see your point...But, in a pinch, I think a script would work for some of the hairier programs to build (php is one of these) IE: back up ld.so.conf, modify it to have the extra lib line, run ldconfig, run the program, undo the change, run ldconfig... Wow... that's a lot of work, especially for something like php which will be run for each page load under monkey - and held on-line continually under apache, it wouldn't work at all. dern it. Oh, and I take back what I said about poorly written windows-alike filemanagers. Xfe is pretty sleek for its size. Posted by ke4nt1 on Jan. 06 2005,07:16
Xfe, eh?So, I can expect to receive an xfe.tar.gz extension from you in the near future? I haven't seen any contributions posted under your name so far.. Xfe would be an excellent addition to the repository.. Send it with a .info and .md5.txt file to either.. ke4nt [at] damnsmalllinux [dot] org - or extensions [at] damnsmalllinux [dot] org 73 ke4nt Posted by mikshaw on Jan. 06 2005,14:56
nucpc had suggested a while ago to use /opt/lib/ as a catch-all lib directory for tar.gz extensions. In this case only one additional directory is added to the ld search. I thought it was a good idea, but still has the possibility of problems with multiple versions of a single lib.That said, it's still the best thing I've tried for working with extra libs, and I use this method in my own DSL setup. Along with a /home/dsl/bin directory added to my $PATH it removes the need for wrapper scripts. So far I haven't run into any problems, but then I generally use only a small handful of extensions....and they are mostly recompiled against the same libs. Posted by mikshaw on Jan. 06 2005,23:25
I just noticed that $LD_LIBRARY_PATH doesn't always work...apparently some applications ignore this variable.I'm trying to make a green extension of screen, and a couple of libs are not found:
It only seems to work if I run /etc/init.d/mkwriteable and then copy the files into /lib Posted by ke4nt1 on Jan. 07 2005,00:59
Could those be only symlinks in your /opt/screen/lib dir?Frequently, libs ending in .so.0 are only symlinks, pointing to some other location.. All your other listed libs have numbers greater than zero, and they are all found, which is why I thought to ask.. I usually see these files/symlinks grouped. libelf.so.0 => libelf.so.0.6.4 libutempter.so.0 => libutempter.so.0.5 And yes.., you are correct.. Depending on how an application was compiled, or even if the author went to the effort of allowing alt paths, some apps simply will not run without seeing files in certain places. This is no fault of the extension, the OS, or the libs, and can often be worked around by setting a more proper path for your design in the configure file before compile-time. Here is some more data, from a "sun" perspective, on how it can work for you, against you, not at all, or even as a necessity to an app even running.. < http://www.visi.com/~barr/ldpath.html > Again, if you recompile, you can usually set the lib path to your wishes.. I've also seen where a path statement is forced by editing the global path to include checking the LD_LIBRARY_PATH first, like PATH=$LD_LIBRARY_PATH,$PATH Which forces a search for libs to check thru your LD_LIBRARY_PATH variable BEFORE your usual path, which may prevent the error - that it did not find it in the suggested or usual compiled-in path location. 73 ke4nt Posted by mikshaw on Jan. 07 2005,03:08
No, they were files I added myself. Those same files worked when copied into /lib after mkwriteable.
I tried LDFLAGS=-L/opt/screen/lib during configure, but it apparently didn't help. I've noticed some configure scripts are a bit more flexible than others...screen didn't seem to have many options.
I read something similar not long ago, which made me start thinking about alternatives. What I've come up with so far is a confirmation of the old "the more I learn, the more I learn how much more I have to learn".
I didn't know the two paths could work together like that...always thought PATH was for executables and LD_LIBRARY_PATH was for libs, and never the twain shall meet...I'll have to try that out, thanks. Posted by ke4nt1 on Jan. 07 2005,03:35
You may be correct about the path/exec never meeting, as I cannot find any further documentation to support this. I may be following someone else's bad advice or example here that I came across, or perhaps I am using improper syntax. This works great with the PYTHONPATH statements, but those are executables or 'py files as well. I'll forward this issue to an 'email committee" , and collect their thoughts, while I continue to search for other information on the lib paths. 73 ke4nt Posted by mikshaw on Jan. 07 2005,04:12
I think I fixed it.I tricked the compiler by moving the libs out of /usr/lib and into /opt/screen/lib (rather than just copying), and putting them back after compiling. I haven't tested yet, but I'm guessing that if those were the only libelf and libutempter available, and the compile succeeded, then it should look for the libs in that directory at runtime. This might be a useful method for avoiding LD_LIBRARY_PATH in the future. Posted by mikshaw on Jan. 07 2005,04:25
I spoke too soon. No idea why, but those two libs are still not being found in DSL.
Posted by mikshaw on Jan. 07 2005,05:56
I found the cause of the trouble, but not a solution yet. This is from the ld.so manpage:The shared libraries needed by the program are searched for in various places: ... Using the environment variable LD_LIBRARY_PATH. Except if the executable is a setuid/setgid binary, in which case it is ignored. the screen binary is setuid. Posted by ke4nt1 on Jan. 07 2005,06:56
Ah yes, I have read about that a few times .. I think it was mentioned in the link I posted.. Hmm, wonder why setgid/uid ? So.. what happens if you remove the sticky gid/uid? Is that needed for running in a gnome or kde environment? Usually NOT needed, and many times considered a securty risk. If you don't have any luck, I'll get screen tomorrow, and browse thru it with you.. What happens if you simply run the app as sudo? Sticky bits be damned... 73 ke4nt Posted by mikshaw on Jan. 07 2005,15:21
Found a little more info:
These features don't seem to be too important for a DSL system, so I've removed the UID....still have to test it out. It still requires libelf, which i find odd. The screen package I have installed in suse is a single minor version difference, and it does not require libelf. Also since ELF seems to be a very large part of Linux systems I'm curious why none of my other extensions want it. Fordi: sorry for the hijack. When I started typing it seemed to fit into this thread perfectly...but evolved into a different issue. Posted by mikshaw on Jan. 07 2005,17:58
well....good and bad news...After looking through Makefile and config.h I got it to compile without the extra libs, and now it seems to work. Unfortunately it seems to work only in an X terminal, which makes the whole thing rather pointless. I don't know if it's because of the way DSL was built, or if it's something I can fix myself, but I tried both with and without setuid and I get the message "can't open /dev/tty1". This occurs with my extension as well as with a precompiled version including the extra libs. Comparing /dev/tty* in DSL with /dev/tty* in suse I can't see any difference in the files themselves, so I'm at a wall with no visible doors or windows...not understanding much about how terminals work I think I'll have to put this project aside until I learn a bit more. I won't be posting about this in this thread anymore....again, Fordi, sorry about taking your thread in the wrong direction. |