pUPnGO 2012
Excuse me for asking - a while back there was discussion here based on the output of strace, where it seemed that the dynamic linker was looking in many strange places for libs (like /lib/tls, etc) before finally looking in just /lib, /usr/lib, etc. does anyone remember the discussion and could redirect me to it. If this is true, I'd like to do something about it by patching glibc to skip all those locations...
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I'm pretty sure it's ld-x.xx.so (whatever ld-linux.so.2 links to). the question is where do we find where that list is being composed in the linker code?
techno, "library paths from the build environment with gcc", do you mean during the build of glibc or the program in question?
Or maybe it's just strace's own output?
techno, "library paths from the build environment with gcc", do you mean during the build of glibc or the program in question?
Or maybe it's just strace's own output?
http://stackoverflow.com/questions/9922 ... earch-path
Creating the searched directory structure (/lib/tls/i686/sse2) and symlinking /lib/libc.so.6 there stops the search.
Using less to view content of ld-2.6.1.so and text search for tls or sse2 does not show anything.
Using strace on dynamic linked uclibc binaries does not have these extra search path (goes for "/lib/libc.so" first).
Creating the searched directory structure (/lib/tls/i686/sse2) and symlinking /lib/libc.so.6 there stops the search.
Using less to view content of ld-2.6.1.so and text search for tls or sse2 does not show anything.
Using strace on dynamic linked uclibc binaries does not have these extra search path (goes for "/lib/libc.so" first).
What is the output of:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
on your machine. The command appears to only show locations which are in ld.so.conf, plus the standard locations.
Here, I get:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/local/lib:
/usr/i586-kiss-linux/lib:
/usr/lib/seamonkey:
/lib:
/usr/lib:
And the content of /etc/ld.so.conf is:
/usr/local/lib
/usr/i586-kiss-linux/lib
/usr/lib/seamonkey
Whose glibc are you using anway?
ldconfig -v 2>/dev/null | grep -v ^$'\t'
on your machine. The command appears to only show locations which are in ld.so.conf, plus the standard locations.
Here, I get:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/local/lib:
/usr/i586-kiss-linux/lib:
/usr/lib/seamonkey:
/lib:
/usr/lib:
And the content of /etc/ld.so.conf is:
/usr/local/lib
/usr/i586-kiss-linux/lib
/usr/lib/seamonkey
Whose glibc are you using anway?
I am using libs provided with standard Puppy 412...output is:
and content of /etc/ld.so.conf is/lib:
/usr/lib:
/usr/X11R7/lib:
/opt/qt4/lib:
/opt/mozilla.org/lib:
/root/my-applications/lib:
/usr/lib/tls: (hwcap: 0x8000000000000000)
/lib
/usr/lib
/usr/X11R7/lib
/opt/qt4/lib
/opt/mozilla.org/lib
/opt/samba/lib
/root/my-applications/lib
/usr/lib/tls: (hwcap: 0x8000000000000000)
Okay! That's the one which is hidden and generated in some mysterious way. It either has to do with CPU specs and is generated at runtime or it has to do with configure options to glibc and is being determined at glibc compile-time. The key is the 'hwcap' part.
I have asked about this all over at linuxquestions.org -but no takers yet.
Aha! Just found an LKML thread where The Man(Roland McGrath) himself talks about this:
https://lkml.org/lkml/2007/4/24/3
He seems to be saying that these paths are generated at runtime -using entires in /etc/ld.so.conf.d, and/or they depend on options used at glibc compile-time.
On my self-built system here, I don't get any of those extra paths. Guess the upshot is that you need to be using Gilbert's super-duper KISS linux -where most of the nonsense is missing... Or maybe you'd like to roll your own glibc -even BK doesn't do that.
"libs provided with standard Puppy 412" The problem is that that still doesn't tell us where they came from or who built them! The output of `/lib/libc.so.6` will help a little bit -did you know that trick? Here's another 2 which will tell you some things -sometimes clearing up questions about compiling/linking problems:
gcc -dumpspecs
gcc -dumpmachine
Here's another link with tips to the location(s) in the sources.
http://www.unixresources.net/linux/clf/ ... 88306.html
find -name dl-procinfo.h
sysdeps/generic/dl-procinfo.h
sysdeps/i386/dl-procinfo.h
sysdeps/powerpc/dl-procinfo.h
sysdeps/s390/dl-procinfo.h
sysdeps/sparc/dl-procinfo.h
sysdeps/unix/sysv/linux/i386/dl-procinfo.h
sysdeps/unix/sysv/linux/s390/dl-procinfo.h
sysdeps/unix/sysv/linux/x86_64/dl-procinfo.h
And there's this:
http://blog.ijun.org/2012/01/debugging- ... ssues.html
Does your system have a non-empty /etc/ld.so.conf.d directory?
Okay, getting warmer...
Starting at line 52 of sysdeps/i386/dl-procinfo.c:
Those are the possible CPU features (hwcap) which constitute most of the list of possibly-weird locations. 'tls', and perhaps others, depends on the compile-time options for glibc.
Well, I'm just glad I have this clean, nearly vanilla system so that I don't have 14 open()'s being called before the right location is found!
Okay! That's the one which is hidden and generated in some mysterious way. It either has to do with CPU specs and is generated at runtime or it has to do with configure options to glibc and is being determined at glibc compile-time. The key is the 'hwcap' part.
I have asked about this all over at linuxquestions.org -but no takers yet.
Aha! Just found an LKML thread where The Man(Roland McGrath) himself talks about this:
https://lkml.org/lkml/2007/4/24/3
He seems to be saying that these paths are generated at runtime -using entires in /etc/ld.so.conf.d, and/or they depend on options used at glibc compile-time.
On my self-built system here, I don't get any of those extra paths. Guess the upshot is that you need to be using Gilbert's super-duper KISS linux -where most of the nonsense is missing... Or maybe you'd like to roll your own glibc -even BK doesn't do that.
"libs provided with standard Puppy 412" The problem is that that still doesn't tell us where they came from or who built them! The output of `/lib/libc.so.6` will help a little bit -did you know that trick? Here's another 2 which will tell you some things -sometimes clearing up questions about compiling/linking problems:
gcc -dumpspecs
gcc -dumpmachine
Here's another link with tips to the location(s) in the sources.
http://www.unixresources.net/linux/clf/ ... 88306.html
In topdir of glibc sources:If this stuff is causing you a problem, you can turn it off by patching dl-procinfo.h in glibc
find -name dl-procinfo.h
sysdeps/generic/dl-procinfo.h
sysdeps/i386/dl-procinfo.h
sysdeps/powerpc/dl-procinfo.h
sysdeps/s390/dl-procinfo.h
sysdeps/sparc/dl-procinfo.h
sysdeps/unix/sysv/linux/i386/dl-procinfo.h
sysdeps/unix/sysv/linux/s390/dl-procinfo.h
sysdeps/unix/sysv/linux/x86_64/dl-procinfo.h
And there's this:
http://blog.ijun.org/2012/01/debugging- ... ssues.html
Does your system have a non-empty /etc/ld.so.conf.d directory?
Okay, getting warmer...
Starting at line 52 of sysdeps/i386/dl-procinfo.c:
Code: Select all
#ifndef PROCINFO_DECL
= {
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
"cx8", "apic", "10", "sep", "mtrr", "pge", "mca", "cmov",
"pat", "pse36", "pn", "clflush", "20", "dts", "acpi", "mmx",
"fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe"
}
#endif
Well, I'm just glad I have this clean, nearly vanilla system so that I don't have 14 open()'s being called before the right location is found!
amigo: Thanks for all this info! A lot to test and think about. For now only the output of /lib/libc.so.6
COOL!GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.2.
Compiled on a Linux >>2.6.21.7<< system on 2007-10-18.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
Now I've maybe found the shortcut here:
http://ubuntuforums.org/archive/index.php/t-222492.html
But, it doesn't seem to be in later versions of glibc sources at all. Having an empty /etc/ld.so.conf.d may do the same thing.
http://ubuntuforums.org/archive/index.php/t-222492.html
I remember reading about ld.so.nohwcap before...touch /etc/ld.so.nohwcap
This step is optional, but it reduced my startup time to half of what it used to be.
But, it doesn't seem to be in later versions of glibc sources at all. Having an empty /etc/ld.so.conf.d may do the same thing.
Created a static build of Xorg (X11R-6.7.0) - pet-package including xorgwizard, ddcprobe & dmidecode for easy configuration - can be downloaded here
Its quite big (7,7Mb uncompressed) but I can run it on machinery with 36Mb ram. It seems to display fonts OK. It holds a lot of display drivers so if you have problems getting pupngo2012 running on you hardware this might solve the problem.
Its quite big (7,7Mb uncompressed) but I can run it on machinery with 36Mb ram. It seems to display fonts OK. It holds a lot of display drivers so if you have problems getting pupngo2012 running on you hardware this might solve the problem.
When I boot the standard pupngo2012 on a Toshiba TE2100 the display starts up in 800x600 and everything looks correct. (I can change the res if I need to, but Im just testing in 800x600 for the purposes of this problem..)
When I use the same CD to boot on an older Toshiba (2180CDT) which only has an 800x600 capable screen the display is clear, but all drive icons and program icons are missing unless I start xorg. Also, if I click "file manager" in the menus it does nothing, but if I locate the rox icon and click it, filemanager starts up ok.
Q1) Any ideas why the icons are not displaying under xvesa?
Q2) Is there a cli method of listing running processes?
Q3) Is rox different to rox-filer, and is there a rox-pinboard running on pupngo? Is thats whats not running on my older system?
Q4) Which file describes the position location for the drive icons on pupngo?
Thanks for any pointers.
When I use the same CD to boot on an older Toshiba (2180CDT) which only has an 800x600 capable screen the display is clear, but all drive icons and program icons are missing unless I start xorg. Also, if I click "file manager" in the menus it does nothing, but if I locate the rox icon and click it, filemanager starts up ok.
Q1) Any ideas why the icons are not displaying under xvesa?
Q2) Is there a cli method of listing running processes?
Q3) Is rox different to rox-filer, and is there a rox-pinboard running on pupngo? Is thats whats not running on my older system?
Q4) Which file describes the position location for the drive icons on pupngo?
Thanks for any pointers.
View running processes in CLI: ps (or top for the top ones)
Try look in /tmp/xerrors.log - should report problems - maybe ROX fails to start?
Pinboard should run in pupngo. The geometry is determined at startup and placement of icons set in root/Choices/ROX-Filer/puppupin
Best guess is that ROX are having problems at startup.
Try look in /tmp/xerrors.log - should report problems - maybe ROX fails to start?
Pinboard should run in pupngo. The geometry is determined at startup and placement of icons set in root/Choices/ROX-Filer/puppupin
Best guess is that ROX are having problems at startup.
Thanks for the answers - that is very helpful. As part of this troubleshooting I am changing the desktop layout, and have put the jwm tray at the top (instead of the bottom) and I want to move the drive icons towards the top aswell. I can move these drive icons successfully by changing the puppypin file, but after I do that I notice that new usb drives I plug in still display at the bottom of the screen.goingnuts wrote:Pinboard should run in pupngo.
It appears as if maybe Rox has a predetermined positioning for anything that is not specifically mentioned yet in the puppypin file?
It seems to me that the tray which holds new drive icons is probably specified in the file .create_jwmrc_drives.sh by the line:
Code: Select all
<Tray layout="horizontal" x="-38" y="0" height="40" layer="0" border="1">" # > /root/.jwmrc-drives
Does every possible drive icon HAVE to be listed in puppypin?? What if I don't know how many drives the end user might have?
Is there some way to change the drive_icon_positioning_behaviour without specifying it in puppypin?
- Attachments
-
- TLpngo12.jpg
- (26.36 KiB) Downloaded 454 times
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
The problem with rox is that it doesnt accept negative values for placement (distance from right or bottom) like jwm does, so it is a little harder to get exactly right. It probably wouldn't be a difficult thing to patch but then compatibility issues arise. it would look like:
if (x<0) x+=gdk_screen_get_widthgdk_screen_get_default());
//similar for y
if (x<0) x+=gdk_screen_get_widthgdk_screen_get_default());
//similar for y
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Thanks for the clues. I have made some alterations to pupngo2012 so that the menu and drive icon display functions are referenced to the top left corner instead of the "calculated" bottom_of_screen and my 2180cdt is now booting correctly. I plan to try this approach on some of my other machines that struggle to boot/display puppy correctly, and have started a thread here:
http://www.murga-linux.com/puppy/viewto ... 684#683684
http://www.murga-linux.com/puppy/viewto ... 684#683684
I am working on getting icewm running in pupngo - and almost done with a draft. I am using xli as desktop background setter, have a pm-icewm-menu/winoptions done and modified smaller things in xinitrc and xwin. One problem remains though: How to swallow the freememapplet or other applets in icewm? Ohh - I think the solution is icewmtray!
Icewmtray should address the "swallow" problem.
Happy to hear that IceWM might be in the works ... It's my favorite WM. Puppy Xtreme (420) is still one of my favorite Puppies ... no pinboard or wallpaper just a black screen with my most used apps on a double height taskbar (quick launch) plus battery, eth0 or wlan0, and CPU monitors (no tray). 13 basic running processes including eth0, 15 with wifi up. JWM work too but you do not have system monitors.
I've been playing around with PuPnGo2012, Plus and TLC for a few days now on my older acer lappy. All are running from a single USB flashdrive booting from Grub4DOS. PiPnGo2012 works well .... Only problem noted is that freememapplet doesn't report free RAM or savefile correctly.
Keep up the good work .... KJ
Happy to hear that IceWM might be in the works ... It's my favorite WM. Puppy Xtreme (420) is still one of my favorite Puppies ... no pinboard or wallpaper just a black screen with my most used apps on a double height taskbar (quick launch) plus battery, eth0 or wlan0, and CPU monitors (no tray). 13 basic running processes including eth0, 15 with wifi up. JWM work too but you do not have system monitors.
I've been playing around with PuPnGo2012, Plus and TLC for a few days now on my older acer lappy. All are running from a single USB flashdrive booting from Grub4DOS. PiPnGo2012 works well .... Only problem noted is that freememapplet doesn't report free RAM or savefile correctly.
Keep up the good work .... KJ