Re: Laptop suggestions?
Gary Kline [EMAIL PROTECTED] writes: I've seen that Fn key, but don't know what it is for. What? you press it, then follow with the integers [ 1, 2, 3 ... ]? At any rate, maybe you can remap the key with ~/.xmodmaprc. They're used to access keys which won't physically fit on a laptop keyboard, such as the numeric keypad, NumLock, ScrollLock etc., and (along with function keys) to control hardware-specific functions like switching between internal and external display, turning bluetooth and wlan on and off, adjusting the backlight brightness, etc. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
Ian Smith [EMAIL PROTECTED] writes: Re your original issue, can you get any mileage out of using acpi_ibm, devd and this post and/or the other one it references: The laptop in question does not run FreeBSD. I gave up running FreeBSD on any sort of desktop or laptop computer years ago. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sched_thread_priority in ULE 8.0
Hello All, This is something I've been trying to figure out in the last couple of hours, but can't seem to understand. Sched_thread_priority() updates a threads priority to prio. If the thread is on the RUNQ, we have to pull it out and put it back at a different spot on the same queue. However, if the thread is currently running, I am missing something. If it is running shouldn't tdq-tdq_lowpri basically be same as the threads current priority (aka oldpri).. I can't seem to figure out why we need the else if check and a call to tdq_lowpri. If the thread is running and we've boosted the thread's priority, then simply changing tdq_lowpri should do it right? I've included part of the sched_thread_priority code below. Thanks Ravi The code is as follows: ... If (prio tdq-tdq_lowpri) tdq-tdq_lowpri else if (tdq-tdq_lowpri == oldpri) tdq_setlowpri(tdq, td); ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Hello: I have some weird behavior I'm trying to figure out and was wondering if someone can point me in the right direction. I'm running a FreeBSD 6.1-RELEASE-amd64 machine. If I add /usr/lib32 to my LD_LIBRARY_PATH it breaks all of my binaries on my 64-bit machine. For example: [EMAIL PROTECTED] ~]# file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped [EMAIL PROTECTED] ~]# ldd /bin/ls /bin/ls: libutil.so.5 = /lib/libutil.so.5 (0x80063) libncurses.so.6 = /lib/libncurses.so.6 (0x80073d000) libc.so.6 = /lib/libc.so.6 (0x800896000) [EMAIL PROTECTED] ~]# ls -l /libexec/ total 306 -r-xr-xr-x 1 root wheel 163864 Aug 21 2007 ld-elf.so.1 -r-xr-xr-x 1 root wheel 146420 Aug 21 2007 ld-elf32.so.1 [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# ls /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout [EMAIL PROTECTED] ~]# unset LD_LIBRARY_PATH [EMAIL PROTECTED] ~]# ls (normal ls output) [EMAIL PROTECTED] ~]# ls -l /usr/lib/libut* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so - /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a [EMAIL PROTECTED] ~]# file /lib/libutil.so.5 /lib/libutil.so.5: ELF 64-bit LSB shared object, AMD x86-64, version 1 (FreeBSD), stripped I would ASSUME that rtld would look at my LD_LIBRARY_PATH and use /usr/lib to find libraries, not /usr/lib32. Why does it insist on picking /usr/lib32 when /bin/ls is CLEARLY a 64-bit binary? This doesn't make complete sense to me just yet. Someone I'm sure is going don't do that and I agree. The issue is I'm porting a library/framework (boost) and it creates a runtime LD_LIBRARY_PATH for its gcc toolchain with the above which breaks the build ROYALLY on FreeBSD 64-bit machine. I'm trying to come up with the right heuristic here. Any help would be much appreciated! Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Alexander Sack [EMAIL PROTECTED] writes: I have some weird behavior I'm trying to figure out and was wondering if someone can point me in the right direction. I'm running a FreeBSD 6.1-RELEASE-amd64 machine. If I add /usr/lib32 to my LD_LIBRARY_PATH it breaks all of my binaries on my 64-bit machine. [...] LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 I'm surprised you have /usr/bin in there... I would ASSUME that rtld would look at my LD_LIBRARY_PATH and use /usr/lib to find libraries, not /usr/lib32. Why does it insist on picking /usr/lib32 when /bin/ls is CLEARLY a 64-bit binary? This doesn't make complete sense to me just yet. If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. Someone I'm sure is going don't do that and I agree. Well, yeah, but it should (at the very least) fail in a more graceful manner. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Dag-Erling Smørgrav [EMAIL PROTECTED] writes: If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. You can rebuild rtld(1) with debugging enabled: % cd /usr/src/libexec/rtld-elf % make clean % make DEBUG_FLAGS=-DDEBUG % make install % echo $LD_LIBRARY_PATH /home/des/lib:/opt/varnish/lib:/usr/local/lib % LD_DEBUG=1 /usr/bin/true /libexec/ld-elf.so.1 is initialized, base address = 0x80050 RTLD dynamic = 0x8006305b0 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libc.so.7 Trying /home/des/lib/libc.so.7 Trying /opt/varnish/lib/libc.so.7 Trying /usr/local/lib/libc.so.7 Trying /lib/libc.so.7 loading /lib/libc.so.7 Ignoring d_tag 1879048185 = 0x6ff9 0x80063b000 .. 0x80085efff: /lib/libc.so.7 checking for required versions initializing initial thread local storage relocating /usr/bin/true relocating /lib/libc.so.7 doing copy relocations initializing key program variables __progname: *0x5005e8 -- 0x7fffebc1 environ: *0x500878 -- 0x7fffe9a8 initializing thread locks calling init function for /lib/libc.so.7 at 0x800664da8 __sysctl in libc.so.7 == 0x80071ae00 in libc.so.7 reloc_jmpslot: *0x800845c78 = 0x80071ae00 transferring control to program entry point = 0x400420 atexit in true == 0x8006fac3e in libc.so.7 reloc_jmpslot: *0x500868 = 0x8006fac3e exit in true == 0x8006af118 in libc.so.7 reloc_jmpslot: *0x500860 = 0x8006af118 __cxa_finalize in libc.so.7 == 0x8006fa940 in libc.so.7 reloc_jmpslot: *0x800846140 = 0x8006fa940 rtld_exit() calling fini function for /lib/libc.so.7 at 0x80071ae60 _exit in libc.so.7 == 0x8006cfff0 in libc.so.7 reloc_jmpslot: *0x8008471d8 = 0x8006cfff0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 9:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. You can rebuild rtld(1) with debugging enabled: % cd /usr/src/libexec/rtld-elf % make clean % make DEBUG_FLAGS=-DDEBUG % make install % echo $LD_LIBRARY_PATH /home/des/lib:/opt/varnish/lib:/usr/local/lib % LD_DEBUG=1 /usr/bin/true /libexec/ld-elf.so.1 is initialized, base address = 0x80050 RTLD dynamic = 0x8006305b0 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libc.so.7 Trying /home/des/lib/libc.so.7 Trying /opt/varnish/lib/libc.so.7 Trying /usr/local/lib/libc.so.7 Trying /lib/libc.so.7 loading /lib/libc.so.7 Ignoring d_tag 1879048185 = 0x6ff9 0x80063b000 .. 0x80085efff: /lib/libc.so.7 checking for required versions initializing initial thread local storage relocating /usr/bin/true relocating /lib/libc.so.7 doing copy relocations initializing key program variables __progname: *0x5005e8 -- 0x7fffebc1 environ: *0x500878 -- 0x7fffe9a8 initializing thread locks calling init function for /lib/libc.so.7 at 0x800664da8 __sysctl in libc.so.7 == 0x80071ae00 in libc.so.7 reloc_jmpslot: *0x800845c78 = 0x80071ae00 transferring control to program entry point = 0x400420 atexit in true == 0x8006fac3e in libc.so.7 reloc_jmpslot: *0x500868 = 0x8006fac3e exit in true == 0x8006af118 in libc.so.7 reloc_jmpslot: *0x500860 = 0x8006af118 __cxa_finalize in libc.so.7 == 0x8006fa940 in libc.so.7 reloc_jmpslot: *0x800846140 = 0x8006fa940 rtld_exit() calling fini function for /lib/libc.so.7 at 0x80071ae60 _exit in libc.so.7 == 0x8006cfff0 in libc.so.7 reloc_jmpslot: *0x8008471d8 = 0x8006cfff0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Alright, well I found some weirdness: [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# LD_DEBUG=1 ls /libexec/ld-elf.so.1 is initialized, base address = 0x800506000 RTLD dynamic = 0x80062ad78 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libutil.so.5 Trying /usr/bin/libutil.so.5 Trying /usr/lib/libutil.so.5 Trying /usr/lib32/libutil.so.5 loading /usr/lib32/libutil.so.5 /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout That's because libutil.so.5 does not exist in /usr/lib only in /lib. The /usr/lib directory has: [EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so - /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a So rtld is looking for major number 5 of libutil, without the standard /lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but: [EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil* -r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so - libutil.so.5 -r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5 -r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a And whalah, I'm broke since there is a libutil.so.5 in there. So my question to anyone out there, WHY does /usr/lib32 contain major numbers but /usr/lib does not? This seems like a bug to me (FreeBSD 7.0-RELEASE is the same) or at least a dubious design decision. Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 10:09 PM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Thu, 23 Oct 2008 21:48:47 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Actually now that I re-read your paragraph I suppose this isn't such a bad idea but for some reason I believe that if you have /usr/lib before /usr/lib32 it should *just* work. -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008 21:48:47 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008, Alexander Sack wrote: Alright, well I found some weirdness: [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# LD_DEBUG=1 ls /libexec/ld-elf.so.1 is initialized, base address = 0x800506000 RTLD dynamic = 0x80062ad78 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libutil.so.5 Trying /usr/bin/libutil.so.5 Trying /usr/lib/libutil.so.5 Trying /usr/lib32/libutil.so.5 loading /usr/lib32/libutil.so.5 /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout That's because libutil.so.5 does not exist in /usr/lib only in /lib. The /usr/lib directory has: [EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so - /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a So rtld is looking for major number 5 of libutil, without the standard /lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but: [EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil* -r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so - libutil.so.5 -r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5 -r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a And whalah, I'm broke since there is a libutil.so.5 in there. So my question to anyone out there, WHY does /usr/lib32 contain major numbers but /usr/lib does not? This seems like a bug to me (FreeBSD 7.0-RELEASE is the same) or at least a dubious design decision. I think the distinction is this. rtld is looking for libutil.so.5 (with version number). This file has to be in /lib, in the root filesystem, so that programs can run before /usr is mounted. libutil.so on the other hand is not searched for by rtld, but by ld (driven by cc), when the program is built. /usr/lib is the traditional place for it to search; I'm not sure if it searches /lib at all. In the case of static libraries, /usr/lib is certainly the right place for libutil.a to go, so having libutil.so there makes sense in my mind. I think your best bet is to dig into whatever is setting LD_LIBRARY_PATH and get it set correctly. Remove /usr/lib32 or at least ensure that /lib is searched first. Trying to change rtld's behavior is not the right approach, IMHO. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
In the last episode (Oct 23), Alexander Sack said: On Thu, Oct 23, 2008 at 10:09 PM, Alexander Kabaev [EMAIL PROTECTED] wrote: LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Ever since the switch from static to dynamic-linked /bin and /sbin, some shared libraries are needed during the boot process. Those libraries live in /lib, and since there are no 32-bit binaries required to boot a 64-bit system, there is no need for a /lib32. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
