Bug#345904: ldd $(which bash) shows fewer libs than bash -c 'lsof -p $$'
Package: libc6 Version: 2.3.5 Compare these two reports: % ldd $(which bash) linux-gate.so.1 => (0xe000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7f85000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7f81000) libc.so.6 => /lib/tls/libc.so.6 (0xb7e49000) /lib/ld-linux.so.2 (0xb7fd6000) % bash -c 'lsof -p $$' COMMAND PIDUSER FD TYPE DEVICESIZE NODE NAME bash11555 knoppix cwdDIR7,1 149 206616792 /KNOPPIX/var/lib/dpkg bash11555 knoppix rtdDIR1,01024 2 / bash11555 knoppix txtREG7,1 649556 12280922 /KNOPPIX/bin/bash bash11555 knoppix memREG0,0 0 [heap] (stat: No such file or directory) bash11555 knoppix memREG7,1 42472 12281048 /KNOPPIX/lib/tls/libnss_files-2.3.5.so bash11555 knoppix memREG7,1 38424 12281054 /KNOPPIX/lib/tls/libnss_nis-2.3.5.so bash11555 knoppix memREG7,1 80888 12281034 /KNOPPIX/lib/tls/libnsl-2.3.5.so bash11555 knoppix memREG7,1 30428 12281042 /KNOPPIX/lib/tls/libnss_compat-2.3.5.so bash11555 knoppix memREG7,1 1266800 12280993 /KNOPPIX/lib/tls/libc-2.3.5.so bash11555 knoppix memREG7,19592 12281019 /KNOPPIX/lib/tls/libdl-2.3.5.so bash11555 knoppix memREG7,1 268396 12280976 /KNOPPIX/lib/libncurses.so.5.5 bash11555 knoppix memREG7,1 88168 12280962 /KNOPPIX/lib/ld-2.3.5.so bash11555 knoppix0u CHR 136,1 3 /dev/pts/1 bash11555 knoppix1u CHR 136,1 3 /dev/pts/1 bash11555 knoppix2u CHR 136,1 3 /dev/pts/1 bash11555 knoppix 255u CHR 136,1 3 /dev/pts/1 Note that lsof shows bash loading a number of libraries not reported by ldd. I wanted to put bash and some other executables, plus their libraries, in a rescue directory. I was hoping ldd would tell me which libraries to include. This did not work for bash (but it did for the others). Is this incomplete behavior expected? To compensate for it, I had to include a lot of stuff to read the output of lsof and find the name of the symlink pointing to each listed file (since the executables use the symlink names, not the physical file names). Yuck. Thanks, -- Dana L. How [EMAIL PROTECTED] +1 650 804 5991 cell
Bug#328183: Xen and TLS. Patch avaliable
retitle 328183 permit user-level-controlled TLS thanks Hi, We too would like to easily control TLS from user space, so as to be able to provide TLS in our user-level thread library. Note that the proposed patch is actually already included upstream, hence in the debian package too. The only remaining bit is to add the -mno-tls-direct-seg-refs option to BUILD_CFLAGS, and rebuild. This will add a very little extra cost to single thread-specific variable accesses, but it shouldn't be noticeable at all. So please just do it :) Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#211610: gcc-3.3: Simple TLS code segfaults
Hi, Isn't this bug fixed ? The testcase works fine now. Regards Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312927: Recibimos su correo con exito...[Re: Mail Delivery (failure [EMAIL PROTECTED])]
Hola, le informamos que hemos recibido y redireccionado su mensaje al area que corresponde para ser analizado y asi responder prontamente a su requerimiento. Recuerde que dependiendo del tipo de consulta (si es aplicable) que haga la respuesta puede ser de instantanea a demorar hasta 48 horas. -- Saludos, Servilink WebHosting. Recomendacion: Busque la palabra servilink en los principales buscadores y vea los comentarios de la gente, solo asi sabra realmente el por que somos los mejores. 43281641 www.servilink.com.ar (siempre mejor!) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339482: patch to fix dpkg usage in glibc when /usr isnt mounted yet
This one time, at band camp, higuita said:
> Hi
>
> tested in debian mips, works fine in my machines
>
> replaced all (but one already commented) dpkg call with plain and old
> if tests
>
> in the end, checking if the machine is running the correct architecture
> is hard to check and should be extremely rare, so i tweak it up and
> comment it
I think your logic in the checks is off. Imagine this:
ver=2.6.14
if [ ${K_MAJOR} -lt 2 ] || [ ${K_MINOR} -lt 4 ] || [ ${K_REV} -lt 19 ] || [
"${ver[4]}" == "-pa17" ]
false falsetrue
false
evaluates to true, I would think.
This particular test is a little difficult6 to rewrite so
straightforwardly (evaluating the string bit at the end is not trivial)
The other tests are fairly straightforward and could be replaced things
like:
if [ ${K_MAJOR} -le 2 ] && [ ${K_MINOR} -le 4 ] && [ ${K_REV} -lt 19 ]
This tests pretty accurately that the numeric part is less than 2.4.19.
Once you start also testing for extensions like -pa17, it will get much
harder to handle. Additionally, the == construct is a bashism. Better
to use = for string tests or -eq for integer tests.
Take care,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
