I have the same problem like in bug report #198657. I use old version of Matlab application on product machine and it doesn't work anymore since I upgraded glibc to version 2.6.1. It's possible to compile glibc-2.6.1 with GLIBC_2.0 support? Or it's necessary to downgrade glibc to version 2.5-r4? If so, how it will be with system updates? If it doesn't work, I have to install an other distribution then Gentoo because I need support for GLIBC_2.0. $ emerge --info Portage 2.1.3.19 (default-linux/x86/2007.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23.9 i686) ================================================================= System uname: 2.6.23.9 i686 AMD Athlon(tm) MP 2400+ Timestamp of tree: Tue, 29 Jan 2008 22:30:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirror.web4u.cz http://pandemonium.tiscali.de/pub/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow acl apache2 berkdb cli cracklib crypt dri fortran gdbm gpm iconv ipv6 isdnlog logrotate mailwrapper midi mmx mudflap mysql ncurses nls openmp pam pcre perl posix pppd python readline reflection session snmp spl sse ssl unicode x86 xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nv vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
no, it is not possible ... the old glibc-2.0 compat interface requires linuxthreads which does not exist in glibc-2.6+ please review this document: http://dev.gentoo.org/~vapier/old-broken-errno-apps perhaps we could convert this into a FAQ of some sorts ...
(In reply to comment #1) > no, it is not possible ... the old glibc-2.0 compat interface requires > linuxthreads which does not exist in glibc-2.6+ > > please review this document: > http://dev.gentoo.org/~vapier/old-broken-errno-apps > > perhaps we could convert this into a FAQ of some sorts ... OK. I understand. The only solution is to mask >=glibc-2.6. Then you should keep all portage tree independent on >=glibc-2.6 because at the moment when you make some update depending in >=glibc-2.6 all systems which are running old commercial applications will be not updatable. This is also one of the different between commercial and non-commercial Linux distributions. If you manage that, Gentoo will be on the same level. I pray to you manage that, otherwise I have to move to an other distro.
Please could you add a breakpoint into the ebuild of glibc-2.6 that if somebody have USE="glibc-compat20" that he shouldn't upgrade because of the incompatibility with GLIBC_2.0? Because now, when I want to downgrade back to glibc-2.5 it will cost me a lot of time with recompiling all the packages which was compiled after the date of installing of the new glibc-2.6. Maybe I could ask you what's the best way of downgrading of glibc, because I don't wanna breakdown my system.
(In reply to comment #3) > Maybe I could ask you what's the best way of downgrading of glibc, because I > don't wanna breakdown my system. There's no way to downgrade glibc version beyond reinstall from scratch.
(In reply to comment #4) > (In reply to comment #3) > > Maybe I could ask you what's the best way of downgrading of glibc, because I > > don't wanna breakdown my system. > > There's no way to downgrade glibc version beyond reinstall from scratch. > Then I'm urging on you to you add a breakpoint into the ebuild >=glibc-2.6 to avoid to install new version for users who use USE="glibc-compat20". It's not fair to let people upgrade glibc without any notification that there is no GLIBC_2.0 support anymore!
no, i'm not adding a die to the ebuild ... a better solution is to put together a little emul package like "emul-linux-x86-glibc-2.0-compat" and have people use that
(In reply to comment #6) > no, i'm not adding a die to the ebuild ... a better solution is to put together > a little emul package like "emul-linux-x86-glibc-2.0-compat" and have people > use that OK, that sounds good! When can I expect this package in portage tree? ;o)
Created attachment 143760 [details] emul-linux-x86-glibc-errno-compat-2.5.ebuild please test
Created attachment 143762 [details] files/glibc-errno-wrapper
(In reply to comment #8) > Created an attachment (id=143760) [edit] > emul-linux-x86-glibc-errno-compat-2.5.ebuild > > please test I just installed emul-linux-x86-glibc-errno-compat-2.5 and Matlab still doesn't work: $ /etc/lmboot_TMW -u matlab /var/tmp/lm_TMW.ld: relocation error: /var/tmp/lm_TMW.ld: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference $ LD_ASSUME_KERNEL="2.4.1" /etc/lmboot_TMW -u matlab /bin/sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
you arent supposed to execute the app, you need to run it through the wrapper glibc-errno-wraper <your app>
(In reply to comment #11) > you arent supposed to execute the app, you need to run it through the wrapper > > glibc-errno-wraper <your app> OK, I didn't know how does it work. Now, I tried this: $ glibc-errno-wrapper /etc/lmboot_TMW -u matlab /usr/bin/glibc-errno-wrapper: line 2: /usr/lib/glibc-errno-compat/lib/ld-linux.so.2: No such file or directory /usr/bin/glibc-errno-wrapper: line 2: exec: /usr/lib/glibc-errno-compat/lib/ld-linux.so.2: cannot execute: No such file or directory According to "epm -ql emul-linux-x86-glibc-errno-compat", the file /usr/lib/glibc-errno-compat/lib/ld-linux.so.2 doesn't exist: $ epm -ql emul-linux-x86-glibc-errno-compat /usr/bin/glibc-errno-wrapper /usr/lib/glibc-errno-compat/lib/ld-linux.so.6 /usr/lib/glibc-errno-compat/lib/libpthread.so.0 /usr/lib/glibc-errno-compat/lib/libc.so.6 So I changed ld-linux.so.2 to ld-linux.so.6 in glibc-errno-wrapper and it still doesn't work: $ glibc-errno-wrapper /etc/lmboot_TMW -u matlab /etc/lmboot_TMW: error while loading shared libraries: /etc/lmboot_TMW: invalid ELF header Then I tried to execute the BIN file directly: $ glibc-errno-wrapper "/usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat" /usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat: error while loading shared libraries: /usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat: cannot open shared object file: No such file or directory If you need any other informations, please let me know.
the ebuild has a typoe with the ld-linux install name ... renaming it like you said works if /etc/lmboot_TMW is a shell script, then you will have to modify it so that it executes the binary with the wrapper
(In reply to comment #13) > if /etc/lmboot_TMW is a shell script, then you will have to modify it so that > it executes the binary with the wrapper That's it what I did (lm_matlab is binary file): $ glibc-errno-wrapper "/usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat" /usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat: error while loading shared libraries: /usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat: cannot open shared object file: No such file or directory But it still doesn't work.
well, what you ran doesnt make sense there is no binary named "/usr/local/matlab/etc/lm_matlab -z -c /tmp/license.dat" that would regardless of running it through the wrapper just drop the broken quotes
(In reply to comment #15) > well, what you ran doesnt make sense > > there is no binary named "/usr/local/matlab/etc/lm_matlab -z -c > /tmp/license.dat" > > that would regardless of running it through the wrapper > > just drop the broken quotes > OK, I did it without the quotes: $ exec /usr/lib/glibc-errno-compat/lib/ld-linux.so.6 --library-path /usr/lib/glibc-errno-compat/lib /usr/local/matlab/etc/glnx86/lm_matlab -z -c /tmp/license.dat and it logged me out (in case of "su -" it closed the su session; in case of ssh session it closed ssh connection) and no precess is running.
well, obviously ... that is how `exec` works added the fixed package to cvs
(In reply to comment #17) > well, obviously ... that is how `exec` works > > added the fixed package to cvs I have tested the emul-linux-x86-glibc-errno-compat from portage tree and it doesn't work. It finish with "Segmentation fault".
Created attachment 144130 [details] matlab.log Strace of command glibc-errno-wrapper /usr/local/matlab/etc/glnx86/lm_matlab
sorry, you'll need to debug it i have no old binary programs nor do i care about them
