ActiveSate tcl 8.5 strange behavior Ubuntu 8.4
in [TCL]
|
Prev: Bug in sqlite3?
Next: TLS -cadir and 8.4
From: tom.rmadilo on 28 Apr 2010 19:23 On Apr 28, 3:57 pm, kennykb <kevin.b.ke...(a)gmail.com> wrote: > On Apr 28, 3:48 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > wrote: > > > > I guess the "Ubuntu-specific" failure > > > we have here is that Ubuntu (or some Ubuntu-packaged component) is > > > causing the install of /lib64/libc even on a 32-bit system. > > > But even in that case, why would /lib64 be in the LD_LIBRARY_PATH ? > > Because the same crappy installer that put /lib64 on the system added > it > to the path? If the problem is solved by changing an environment variable, that sounds great. I use multiple versions of software all the time and if I don't set LD_LIBRARY_PATH correctly, stuff doesn't work. The main problem is that stuff usually "just works", so when it doesn't the symptoms are not familiar. That might be the best indication of a library mis-match.
From: Alexandre Ferrieux on 28 Apr 2010 19:39 On Apr 29, 12:57 am, kennykb <kevin.b.ke...(a)gmail.com> wrote: > On Apr 28, 3:48 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > wrote: > > > > I guess the "Ubuntu-specific" failure > > > we have here is that Ubuntu (or some Ubuntu-packaged component) is > > > causing the install of /lib64/libc even on a 32-bit system. > > > But even in that case, why would /lib64 be in the LD_LIBRARY_PATH ? > > Because the same crappy installer that put /lib64 on the system added > it > to the path? Or maybe it isn't, and the AT code hard-wires the list {/lib64 /lib}. Then, instead of doing specific checks about the platform's word size, it would be more elegant to just scan LD_LIBRARY_PATH for libc.so (mimicking the dynamic linker's scan when running a dependent executable). If the LD_LIBRARY_PATH is so wrecked as to have /lib64 in first position on a 32-bit kernel, then I guess even /bin/grep won't run. So we may safely use it I guess... -Alex
From: Jeff Hobbs on 29 Apr 2010 12:23 On Apr 28, 1:35 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Apr 28, 6:18 pm, Jeff Hobbs <jeff.ho...(a)gmail.com> wrote: > > > > > I did the strace on my SuSE machine and > > the [exec /lib64/libc.so.6] invokes clone(). > > Ah, but it does in the original strace too. The Tcl command [exec > foo.so] always does fork()+execve(), and fork() is a flavour of > clone(). To follow children use the -f flag to strace. In the child > you should see the execve(). No, there is no following execve in my straces, just clone, read, write and close. Jeff
From: Jeff Hobbs on 29 Apr 2010 12:24
On Apr 28, 4:39 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Apr 29, 12:57 am, kennykb <kevin.b.ke...(a)gmail.com> wrote: > > > On Apr 28, 3:48 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > > wrote: > > > > > I guess the "Ubuntu-specific" failure > > > > we have here is that Ubuntu (or some Ubuntu-packaged component) is > > > > causing the install of /lib64/libc even on a 32-bit system. > > > > But even in that case, why would /lib64 be in the LD_LIBRARY_PATH ? > > > Because the same crappy installer that put /lib64 on the system added > > it > > to the path? > > Or maybe it isn't, and the AT code hard-wires the list {/lib64 /lib}. > Then, instead of doing specific checks about the platform's word size, > it would be more elegant to just scan LD_LIBRARY_PATH for libc.so > (mimicking the dynamic linker's scan when running a dependent > executable). In essence the hard-coding is emulating the ld.so behavior, it was just incorrect with determining /lib64 over /lib. Jeff |