Re: glibc 2.2 vs 2.3 issue back again




However, you can play by the complete rules, switching the _entire_
glibc package, including ld-linux, for one execve() [command-line
process]:
      http://BitWagon.com/rtldi/rtldi.html

More careful strace-ing (forgot the -f option for children) revealed that the code calls shell scripts and therefore I switched to using rtldi (with LD_LIBRARY_PATH the libc-2.2 shell, of course, fails to start). Nifty tool, indeed :)



Either copy all libraries listed by 'rpm -ql glibc' on FC4, or run
Mathematica on FC4 and examine /proc/<mathematica-pid>/maps

Nice tip, I found only two new libs to include (Xcursor.so.1 and Xrender.so.1). Also some libs are still loaded from the default libc-2.2 set on my system (/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 and xlcDef.so.2 in the same dir) because several locations, such as /usr/lib/gconv/ and /usr/X11R6/lib are hardcoded, i.e., LD_LIBRARY_PATH is not observed. I edited the relevant strings in the .so files as a solution.


I also copied /usr/lib/locale/locale-archive since it is in the map-list on Fedora and this fixed the initial locale warnings. For some reason NLSPATH does not work (though the C library is supposed to care), therefore I changed the default locale dirs in the Fedora libc to point to my copy of /usr/lib/locale.


regarding chroot

I also managed to free up some room on the hard disk and tried chroot. It appears quite a pain because of X. From the chroot "box" there seems to be no way to access /tmp/.X11-unix/X0 to communicate with the X server - and thus all X programs fail. Based on info on the WWW, everything will have to run on a second X server. It may be useful, still, because by trimming the chroot-ed system down one can find the bare essentials needed to run the software.


-----------------

Some further developments:

Turns out the Mathematica kernel process can be started by hand, and it works 100% of the time, as long as there is no graphics involved. It brings up a shell where one can simplify expressions, integrals, etc. So it has to be something with the front-end, or communication between the two. Also, this means that all libs used by the kernel are loaded fine.

Even with rtldi, Fedora 4 locales, and updated default dirs in the libs (see above) the end result is failure. At least no more error messages but calculations requests from the front-end are silently "eaten" - the program waits, apparently doing something, but then returns with no output.

-----

It might be something with X, given that the Mathematica kernel NEVER crashes, only the front-end (some 30% of the time, immediately at startup). However, with the current setup both 'xterm' and 'xv' from Fedora work flawlessly, even if the locales are taken from the old glibc-2.2 version (i.e., when hardcoded paths in the libs are not patched).

My other guess is that it is something with the threads. For one, I keep getting "defunct" processes, even when the main executable is still running. According to the strace logs, the front-end would start sending "Y" through the pipe to the kernel but that fails with "broken pipe" (EPIPE) - I guess because by then the other process is dead. It would be useful to try a libc-2.3 but kernel-2.4 system as a baseline.

** Paul, which Fedora version do you have? **

Denes
.



Relevant Pages