April 1, 2017: making the "Encyclopédie Hachette Multimédia 2006" work
In Ubuntu 16.04
I have bought the Encyclopédie Hachette Multimédia 2006 (EHM) years ago.
It has not been working anymore in Ubuntu since around 2010. As we are going to see, the problem is at least partly related to the switch from i386 to x86_64 architecture. My first idea was to reinstall the EHM; but when following the installation procedure, a popup window is obtained:
This installation doesn’t support unknown on Linux / x86_64.
It would be necessary to use a 32 bits virtual machine, or a 32 bits chroot environment (cf here). Instead I have tried to make the EHM work with the installation directory created by the installer when my Linux distribution was still compiled in i386. This installation directory is:
$ cd /usr/local/non_src/ehm/;ls application common indexes ehm licence.txt readme.txt uninstall
When running the ehm shell script in this directory, we get two warnings and nothing more happens, though it does not return:
$ ./ehm ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR Gtk-WARNING **: Failed to load module "libgail.so": libgail.so: cannot open shared object file: No such file or directory Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory
No window appears, though ehm-bin seems to work:
$ pgrep ehm 26447 ehm 26450 run-ehm.sh 26456 ehm-bin
The first idea is that some dynamic libraries are missing (not a surprise after all these years). Without updating LD_LIBRARY_PATH, we get:
$ echo $LD_LIBRARY_PATH
:/usr/lib/:/usr/local/lib:/home/jscordia/local/lib
$ ldd ehm-bin
linux-gate.so.1 => (0xf7732000)
libgkgfx.so => not found
libjsj.so => not found
libmozjs.so => not found
libxpcom.so => not found
libplds4.so => not found
libplc4.so => not found
libnspr4.so => not found
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76dd000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76d8000)
libgtk-1.2.so.0 => /usr/local/lib/libgtk-1.2.so.0 (0xf7592000)
libgdk-1.2.so.0 => /usr/local/lib/libgdk-1.2.so.0 (0xf755a000)
libgmodule-1.2.so.0 => /usr/local/lib/libgmodule-1.2.so.0 (0xf7557000)
libglib-1.2.so.0 => /usr/local/lib/libglib-1.2.so.0 (0xf7530000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xf751d000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf7508000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf73bd000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7368000)
libstdc++-libc6.2-2.so.3 => /usr/local/lib/libstdc++-libc6.2-2.so.3 (0xf731f000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7169000)
/lib/ld-linux.so.2 (0x565c9000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7143000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf713f000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7138000
When improving LD_LIBRARY_PATH, the libraries seem to be found, though the file paths are not indicated explicitly by ldd:
$ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/non_src/ehm/application"
$ ldd ehm-bin
linux-gate.so.1 => (0xf7717000)
libgkgfx.so (0xf76eb000)
libjsj.so (0xf76cf000)
libmozjs.so (0xf765b000)
libxpcom.so (0xf7555000)
libplds4.so (0xf7552000)
libplc4.so (0xf754d000)
libnspr4.so (0xf751e000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf74ce000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf74c9000)
libgtk-1.2.so.0 => /usr/local/lib/libgtk-1.2.so.0 (0xf7383000)
libgdk-1.2.so.0 => /usr/local/lib/libgdk-1.2.so.0 (0xf734b000)
libgmodule-1.2.so.0 => /usr/local/lib/libgmodule-1.2.so.0 (0xf7348000)
libglib-1.2.so.0 => /usr/local/lib/libglib-1.2.so.0 (0xf7321000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xf730e000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf72f9000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf71ae000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7159000)
libstdc++-libc6.2-2.so.3 (0xf710f000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6f59000)
/lib/ld-linux.so.2 (0x56569000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6f33000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6f2f000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6f27000)
We remark that libstdc++-libc6.2-2.so.3 is no more linked explictly to a library, though no "not found" message is displayed, exactly as e.g. libmozjs.so. Without doubt this is because the current directory is /usr/local/non_src/ehm/application and libmozjs.so, libstdc++-libc6.2-2.so.3, etc. are available in this directory. In other words this is just a display choice for ldd (note that using ldd shipped with Ubuntu 17.04, the full absolute path is displayed for this library — this is far clearer).
We note that the two libraries indicated in the warnings, libgail.so and libatk-bridge.so, are not listed by ldd. The first idea is that they are called from some of the libraries listed above. We would like a recursive ldd. However it is already the case according to here and here. So it seems that all libraries have been found by ldd. But we have the same problem as before: the EHM does not run.
Another trail is given here:
If you’ve managed to install all the "not found" libraries from the i386 debian packages so that ldd isn’t complaining, it’s still possible that your proprietary binaries don’t work. This is because some applications also use techniques like dlopen() to load shared libraries, instead of asking ldd to link them. How can you figure out which libraries are needed if you don’t have the source code? One way is to use strace.
So I have done:
$ DUMPDIR=$(mktemp -d)
$ strace -o $DUMPDIR/strace.out -f ./ehm
./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR
Gtk-WARNING **: Failed to load module "libgail.so": libgail.so: cannot open shared object file: No such file or directory
Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory
^C
$
$ \grep open $DUMPDIR/strace.out | \grep ’\.so’ | tail -60
3278 open("/usr/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/local/non_src/ehm/application/components/libgkplugin.so", O_RDONLY|O_CLOEXEC) = 15
3278 open("/usr/local/non_src/ehm/application/libgtkxtbin.so", O_RDONLY|O_CLOEXEC) = 15
3278 open("/usr/local/non_src/ehm/application/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/local/non_src/ehm/application/plugins/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
3278 open("/lib/i386-linux-gnu/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/lib/i386-linux-gnu/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/lib/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/lib/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/local/non_src/ehm/application/components/libgfx_gtk.so", O_RDONLY|O_CLOEXEC) = 17
3278 open("/usr/local/non_src/ehm/application/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/local/non_src/ehm/application/plugins/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/sse2/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/sse2/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/i686/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/sse2/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/sse2/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("tls/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/sse2/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/sse2/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("i686/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("sse2/cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("sse2/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("cmov/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 17
3278 open("/lib/i386-linux-gnu/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/lib/i386-linux-gnu/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3278 open("/usr/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("/usr/local/non_src/ehm/application/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("/usr/local/non_src/ehm/application/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("/usr/local/non_src/ehm/application/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("/usr/local/non_src/ehm/application/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3283 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
3283 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
So in this case libc.so.6 is found (in /lib/x86_64-linux-gnu/; strange as the application should look for a 32 bit version), as well as libgfx_gtk.so, but not libXp.so.6, nor libXt.so.6. Indeed on my machine:
$ locate -i -regex "libXt\." /usr/lib/x86_64-linux-gnu/libXt.a /usr/lib/x86_64-linux-gnu/libXt.so /usr/lib/x86_64-linux-gnu/libXt.so.6 /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0
We have only a 64 bits version, as indicated by wajig:
$ wajig which-package /usr/lib/x86_64-linux-gnu/libXt.so.6 INSTALLED MATCHES (x1) ---------------------- libxt6:amd64: /usr/lib/x86_64-linux-gnu/libXt.so.6 UNINSTALLED MATCHES (x2) ------------------------ libxt6: /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0 libxt6: /usr/lib/x86_64-linux-gnu/libXt.so.6
The package to install is the 32 bits version is libxt6:i386:
$ wajig install libxt6:i386 [...]
After that libXt.so.6 is found as expected:
$ strace -o $DUMPDIR/strace.out -f ./ehm
./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR
Gtk-WARNING **: Failed to load module "libgail.so": libgail.so: cannot open shared object file: No such file or directory
Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory
^C
$ \grep open $DUMPDIR/strace.out | \grep ’libXt.so.6’
23894 open("/usr/local/non_src/ehm/application/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("/usr/local/non_src/ehm/application/plugins/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/i686/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/i686/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/i686/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/i686/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("tls/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("i686/sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("i686/sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("i686/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("i686/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("sse2/cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("sse2/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("cmov/libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("libXt.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
23894 open("/usr/lib/i386-linux-gnu/libXt.so.6", O_RDONLY|O_CLOEXEC) = 9
Concerning libXp.so.6, the package libxp6 is no more available in recent Ubuntu releases. A solution is given here: download the Ubuntu 12.04 (Precise) package at this location. It indeed contains libXp.so.6:
$ dpkg --contents libxp6_1.0.1-2ubuntu0.12.04.2_i386.deb drwxr-xr-x root/root 0 2015-04-13 14:57 ./ drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/ drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/lib/ drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/lib/i386-linux-gnu/ -rw-r--r-- root/root 30528 2015-04-13 14:57 ./usr/lib/i386-linux-gnu/libXp.so.6.2.0 drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/share/ drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/share/doc/ drwxr-xr-x root/root 0 2015-04-13 14:57 ./usr/share/doc/libxp6/ -rw-r--r-- root/root 1499 2015-04-13 14:56 ./usr/share/doc/libxp6/changelog.Debian.gz -rw-r--r-- root/root 3128 2015-04-13 14:56 ./usr/share/doc/libxp6/copyright lrwxrwxrwx root/root 0 2015-04-13 14:57 ./usr/lib/i386-linux-gnu/libXp.so.6 -> libXp.so.6.2.0
We have two solutions: extract libXp.so.6 and put it in /usr/local/lib. It only makes necessary to append /usr/local/lib to LD_LIBRARY_PATH (which is already done on my machine). The second solution is to install the package directly, since /usr/lib/i386-linux-gnu/ still exists in Ubuntu 16.04; but it has to be re-installed for each new Linux re-installation. I choose the second solution; I put all such packages in /usr/local/packages/installed/.
$ cd /usr/local/packages/installed/ $ dpkg-scanpackages . /dev/null | gzip -c -9 > Packages.gz $ wajig update $ wajig install libxp6
After these installations, the EHM runs correctly. Note that other i386 packages may have to be installed on your machine; using strace as explained above you should be able to find which ones are needed. We still obtain the above warnings at startup:
Gtk-WARNING **: Failed to load module "libgail.so": libgail.so: cannot open shared object file: No such file or directory Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory
I have not tried to make them disappear.
In Xubuntu 17.04
After a fresh installation and additional installation of some packages not related to EHM:
$ ./ehm ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR ./application/ehm-bin: error while loading shared libraries: libXi.so.6: cannot open shared object file: No such file or directory
After installation of libxi6:i386:
$ ./ehm
./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR
Fatal error: glibc detected an invalid stdio handle
/usr/local/non_src/ehm/application/run-ehm.sh: line 159: 8774 Aborted (core dumped) "$prog" ${1+"$@"}
Contrary to Ubuntu 16.04, it seems that all libraries are found by open() (see procedure described above). And ldd does not show any problem:
$ ldd ehm-bin
linux-gate.so.1 => (0xf77bc000)
libgkgfx.so (0xf778f000)
libjsj.so (0xf7773000)
libmozjs.so (0xf7700000)
libxpcom.so (0xf75fa000)
libplds4.so (0xf75f7000)
libplc4.so (0xf75f2000)
libnspr4.so (0xf75c3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7574000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf756f000)
libgtk-1.2.so.0 => /usr/local/lib/libgtk-1.2.so.0 (0xf7429000)
libgdk-1.2.so.0 => /usr/local/lib/libgdk-1.2.so.0 (0xf73f1000)
libgmodule-1.2.so.0 => /usr/local/lib/libgmodule-1.2.so.0 (0xf73ee000)
libglib-1.2.so.0 => /usr/local/lib/libglib-1.2.so.0 (0xf73c8000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xf73b5000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf73a0000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7255000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf71ff000)
libstdc++-libc6.2-2.so.3 (0xf71b6000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6ffa000)
/lib/ld-linux.so.2 (0x56555000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6fd4000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6fd0000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6fc9000
This page related to a similar problem suggests to install libstdc++ in version 5. But doing
$ wajig install libstdc++5:i386
does not change the result of ldd above. The same page suggests to use LD_PRELOAD (concerning this environment variable, see indications here):
$ LD_PRELOAD="/usr/lib/i386-linux-gnu/libstdc++.so.5" ldd ehm-bin
ERROR: ld.so: object ’/usr/lib/i386-linux-gnu/libstdc++.so.5’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
[...]
libstdc++-libc6.2-2.so.3 (0xf704c000)
[...]
Not better when indicating the 64 bits version:
$ LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libstdc++.so.5" ldd ehm-bin
ERROR: ld.so: object ’/usr/lib/x86_64-linux-gnu/libstdc++.so.5’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
[...]
libstdc++-libc6.2-2.so.3 (0xf719d000)
[...]
In fact this error "cannot be preloaded" is obtained independently from the problem with EHM:
$ export LD_PRELOAD=’/usr/lib/x86_64-linux-gnu/libstdc++.so.5’ $
No error is obtained; but when indicating the 32 bits version:
$ export LD_PRELOAD=’/usr/lib/i386-linux-gnu/libstdc++.so.5’ ERROR: ld.so: object ’/usr/lib/i386-linux-gnu/libstdc++.so.5’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. [...]
I don’t know why with ldd both wrong ELFCLASS32 and wrong ELFCLASS64 are obtained; anyway libstdc++-libc6.2-2.so.3 is correctly found in ehm/application, as in Ubuntu 16.04. The problem has to be found elsewhere. This page points to two libc.so copies in the same process:
Fiddle::TestImport#test_io = Fatal error: glibc detected an invalid stdio handle
uncommon.mk:612: recipe for target ’yes-test-almost’ failed
make: *** [yes-test-almost] Aborted (core dumped)
[...]
libio vtable verification fails because there are two copies of libc.so.6 in the process:
0x00003fffb79413a8 - 0x00003fffb7941f78 is __libc_IO_vtables in /lib64/power8/libc.so.6
0x00003fffb74213c0 - 0x00003fffb7421f90 is __libc_IO_vtables in /lib64/libc.so.6
In my case, the glibc "invalid stdio handle" is obtained not after having opened a second version of libc, but on opening libstdc++-libc6.2-2.so.3:
$ strace -f ./ehm 2>&1 |\grep libc|\grep -v "No such file"
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24437] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24438] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24439] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24438] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24440] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24441] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24443] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24444] open("/usr/local/non_src/ehm/application/libstdc++-libc6.2-2.so.3", O_RDONLY|O_CLOEXEC) = 3
Fatal error: glibc detected an invalid stdio handle
[pid 24444] open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid 24444] writev(5, [{"Fatal error: glibc detected an i"..., 52}], 1) = 52
[pid 24446] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
What is libstdc++-libc6.2-2.so.3? It is probably the C++ library, built using libc6 version 2.2 (i.e. GNU libc, in other words glibc, version 2.2). The numbering is not so clear, but is also suggested by the file names in a .deb package I have somewhere on my machine (not related to EHM):
$ dpkg-deb -c libstdc++2.10-glibc2.2_2.95.4-27_i386.deb drwxr-xr-x root/root 0 2006-07-13 18:48 ./ drwxr-xr-x root/root 0 2006-07-13 18:47 ./usr/ drwxr-xr-x root/root 0 2006-07-13 18:47 ./usr/share/ drwxr-xr-x root/root 0 2006-07-13 18:47 ./usr/share/doc/ drwxr-xr-x root/root 0 2006-07-13 18:47 ./usr/share/doc/libstdc++2.10-glibc2.2/ -rw-r--r-- root/root 3941 2006-07-13 18:30 ./usr/share/doc/libstdc++2.10-glibc2.2/README.Debian -rw-r--r-- root/root 2460 2004-01-31 16:30 ./usr/share/doc/libstdc++2.10-glibc2.2/copyright -rw-r--r-- root/root 30029 2006-07-13 18:24 ./usr/share/doc/libstdc++2.10-glibc2.2/changelog.Debian.gz -rw-r--r-- root/root 2481 2004-01-31 16:30 ./usr/share/doc/libstdc++2.10-glibc2.2/README.Bugs.gz drwxr-xr-x root/root 0 2006-07-13 18:47 ./usr/lib/ -rw-r--r-- root/root 1295276 2006-07-13 18:39 ./usr/lib/libstdc++-3-libc6.2-2-2.10.0.so lrwxrwxrwx root/root 0 2006-07-13 18:47 ./usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so
Though the description of the package mentions glibc version 2.3.6:
$ dpkg-deb -I libstdc++2.10-glibc2.2_2.95.4-27_i386.deb new debian package, version 2.0. size 329662 bytes: control archive=912 bytes. 488 bytes, 15 lines control 417 bytes, 5 lines md5sums 259 bytes, 12 lines * postinst #!/bin/sh 16 bytes, 3 lines * prerm #!/bin/sh 62 bytes, 1 lines shlibs Package: libstdc++2.10-glibc2.2 Version: 1:2.95.4-27 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.6-6) [...]
Note that no libstdc++ available in Ubuntu 17.04 repositories mentions the libc6 version being used.
$ wajig list-all|grep "stdc++.*libc" $
Indeed there is backward compatibility in libc6 versions, and a old libstdc++ library as ehm/application/libstdc++-libc6.2-2.so.3 should be able to use the libc6 version of Ubuntu 17.04. In fact the problem is that this libstc++ library has been compiled in 32 bits, whereas above the strace output shows that a 64 bits version of libc6 is opened at runtime:
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
and this, independently from the fact that above ldd showed a dependence on a 32-bits version of libc6:
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6ffa000)
The solution is to avoid loading a 64 bits version of libc6 by all means. This is achieved by preloading the 32 bits version of Ubuntu 17.04. The output of strace obtained by
$ LD_PRELOAD="/lib/i386-linux-gnu/libc.so.6" strace -o $DUMPDIR/strace.out -f ./ehm-bin
shows that still one package has to be installed: libxp6:i386. Once it is done, the EHM GUI starts correctly. But when trying to make a search, a popup is obtained "La connexion a été perdue avec le serveur, l’application ne peut plus fonctionner correctement.". Indeed a suitable environment has to be set for the GUI, and this is done by the right program to run in the parent directory:
$ LD_PRELOAD="/lib/i386-linux-gnu/libc.so.6" ./ehm ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. [00000143] main input: playlist item ‘file:///tmp/empty.mov’ [00000143] main input: EOF reached [00000143] access_file input: closing ‘file/:///tmp/empty.mov’ ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Then EHM works perfectly. I don’t know the root cause for the "cannot be preloaded" messages, but clearly in our case they are more warnings than errors. Finally I have created a new launcher in Xfce menu (right-click on "Whisker menu" i.e. the mouse icon to start applications in the panel bar -> edit applications), and set the "Command" field so as to run the "ehm" script with the right LD_PRELOAD:
/bin/sh -c ’LD_PRELOAD=/lib/i386-linux-gnu/libc.so.6 /usr/local/non_src/ehm/ehm’
Indeed it is not possible to set environment variable in the Xfce/Xubuntu GUI allowing to create new application launchers, such that it is necessary to encapsulate the LD_PRELOAD variable and ehm path in ’sh -c’.
In Debian Stretch 9.4
After installation of libxi6:i386, we get
$ ldd ehm-bin linux-gate.so.1 (0xf77ca000) libgkgfx.so (0xf779e000) libjsj.so (0xf7782000) libmozjs.so (0xf770d000) libxpcom.so (0xf7607000) libplds4.so (0xf7604000) libplc4.so (0xf75ff000) libnspr4.so (0xf75d0000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7595000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7590000) libgtk-1.2.so.0 => /usr/local/lib/libgtk-1.2.so.0 (0xf744a000) libgdk-1.2.so.0 => /usr/local/lib/libgdk-1.2.so.0 (0xf7412000) libgmodule-1.2.so.0 => /usr/local/lib/libgmodule-1.2.so.0 (0xf740f000) libglib-1.2.so.0 => /usr/local/lib/libglib-1.2.so.0 (0xf73e7000) libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xf73d4000) libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf73bf000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7271000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf721c000) libstdc++-libc6.2-2.so.3 (0xf71d3000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf701c000) /lib/ld-linux.so.2 (0xf77cc000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6ff0000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6fec000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6fe5000) libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf6fc7000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf6fbe000)
But
$ ./ehm ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR Fatal error: glibc detected an invalid stdio handle Aborted
This is the same problem as in Ubuntu 17.04. So we try
$ LD_PRELOAD="/lib/i386-linux-gnu/libc.so.6" ./ehm ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object ’/lib/i386-linux-gnu/libc.so.6’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Gtk-WARNING **: Failed to load module "libgail.so": libgail.so: cannot open shared object file: No such file or directory Gtk-WARNING **: Failed to load module "libatk-bridge.so": libatk-bridge.so: cannot open shared object file: No such file or directory
Thus we install libatk-bridge2.0-0:i386 and libgail-common:i386, but not better. So strace has to be used:
$ DUMPDIR=$(mktemp -d) $ strace -o $DUMPDIR/strace.out -f ./ehm ./application/run-ehm.sh ./application/ehm-bin -contentLocale FR -UILocale fr-FR Fatal error: glibc detected an invalid stdio handle Aborted $ \grep open $DUMPDIR/strace.out | \grep ’\.so’ | tail -100 […] 6924 open("/usr/local/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/usr/local/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/usr/local/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/home/jscordi/local/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/home/jscordi/local/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/home/jscordi/local/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/home/jscordi/local/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 6924 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 6924 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 4 $
So in this case all libraries are found; and libc.so.6 is found (in /lib/x86_64-linux-gnu/; strange as the application should look for a 32 bit version). This is misleading, strace must be run with the LD_PRELOAD mentioned above:
$ LD_PRELOAD="/lib/i386-linux-gnu/libc.so.6" strace -o $DUMPDIR/strace.out -f ./ehm
With this the result is different:
$ \grep open $DUMPDIR/strace.out | \grep ’\.so’ | tail -100 […] 7721 open("libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/usr/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/usr/local/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/home/jscordi/local/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 18 7721 open("/lib/i386-linux-gnu/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/usr/lib/i386-linux-gnu/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 7721 open("/usr/lib/libXp.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) $
So the same problem as in Ubuntu appears; the same solution is used: installation of the libxp6 package of Ubuntu 12.04. Also, libxt6:i386 has to be installed:
$ wajig install libxt6:i386 libxp6
After that the EHM starts correctly.
In Xubuntu 20.04
Cf my note of April 1, 2017. Problem when I try to install libxp6:
$ wajig install libxp6 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libxp6:i386 : PreDepends: multiarch-support:i386 but it is not installable E: Unable to correct problems, you have held broken packages.
This is because this package multiarch-support has recently disappeared. I have followed the procedure indicated at here, i.e. downloaded in my local repository:
$ cd /usr/local/packages/installed $ wget http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/multiarch-support_2.27-3ubuntu1.2_amd64.deb $ wajig install libxp6 $ ./update_packages_gz.sh $ wajig update […] $ wajig install libxp6 Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: multiarch-support The following NEW packages will be installed: libxp6:i386 multiarch-support 0 upgraded, 2 newly installed, 0 to remove and 6 not upgraded. Need to get 0 B/25.4 kB of archives. After this operation, 323 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 file:/usr/local/packages/installed multiarch-support 2.27-3ubuntu1.2 [6,920 B] Get:2 file:/usr/local/packages/installed libxp6 1:1.0.1-2ubuntu0.12.04.2 [18.5 kB] Selecting previously unselected package multiarch-support. (Reading database ... 583630 files and directories currently installed.) Preparing to unpack .../multiarch-support_2.27-3ubuntu1.2_amd64.deb ... Unpacking multiarch-support (2.27-3ubuntu1.2) ... Setting up multiarch-support (2.27-3ubuntu1.2) ... Selecting previously unselected package libxp6:i386. (Reading database ... 583633 files and directories currently installed.) Preparing to unpack .../libxp6_1.0.1-2ubuntu0.12.04.2_i386.deb ... Unpacking libxp6:i386 (1:1.0.1-2ubuntu0.12.04.2) ... Setting up libxp6:i386 (1:1.0.1-2ubuntu0.12.04.2) ... Processing triggers for libc-bin (2.31-0ubuntu9.1) ... N: Download is performed unsandboxed as root as file ’/usr/local/packages/installed/./multiarch-support_2.27-3ubuntu1.2_amd64.deb’ couldn’t be accessed by user ’_apt’. - pkgAcquire::Run (13: Permission denied)
After that it works correctly.
