I installed emul-linux-x86-*-20100915-r1. Although ebuilds don't say so, they seem to need glibc >= 2.11. When I try to run 32bit firefox (www-client/firefox-bin-3.6.10), the following message is printed: ---------- $ firefox-bin & $ /opt/firefox/firefox-bin: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libcairo.so.2) /opt/firefox/firefox-bin: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libfreetype.so.6) /opt/firefox/firefox-bin: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libpng14.so.14) /opt/firefox/firefox-bin: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libICE.so.6) ---------- I have sys-libs/glibc-2.9_p20081201-r2 with "multilib" flag on. Downgrading to 20100611 series fixes. (Right now I don't feel like updating sys-libs/glibc.) Thanks in advance. Reproducible: Always
@reporter, glibc-2.11 is stable, now. please upgrade if you want to run this emul-linux-x86 version @pacho, please add the glibc-2.11 dep since this version is build against it.
emul packages are supposed to be run on latest stable, otherwise, we would need to add tons of blockers against old gtk+, perl, libpng... versions to every emul package to "support" people mixing latest stable with some random old tools. The solution is simple: run latest emul stable package on an updated system
I see, but unless you share the knowledge, the same bug reports will be done. So something like below should be added to ebuilds: pkg_postinst() { elog "emul-linux-x86-* packages implicitly depend on many packages." elog "(It's not specified in ebuilds because there're too many, including" elog "blockers.) You may have to upgrade other packages to the latest stable" elog "versions." } If you want, I'll send a patch for all emul-linux-x86-* ebuilds. It should also made be sure that old versions are not removed too soon from the portage tree. Upgrading all is a tough task (You have to read all logs, and decide what to with /etc updates.), and not all have fast enough machines. ;) If new emul-linux-x86-* doesn't work and you don't have much time, the quickest fix is to downgrade. If it's more than clear for all developers, it's ok, but if not, it also has to be written somewhere. Thanks a lot anyway. I understand being a developer is a demanding task, and less thanked than they deserve.
(In reply to comment #3) > I see, but unless you share the knowledge, the same bug reports will be done. > So something like below should be added to ebuilds: But this is the first bug report about this problem I have seen, then, seems that your setup (using old glibc) is not common enough to worth the effort of updating all emul packages ebuilds and update blockers each time problems mixing latest emul packages with old stable systems appear. > It should also made be sure that old versions are not removed too soon from the > portage tree. Upgrading all is a tough task (You have to read all logs, and > decide what to with /etc updates.), and not all have fast enough machines. ;) > If new emul-linux-x86-* doesn't work and you don't have much time, the quickest > fix is to downgrade. > I was planning to drop old emul packages in the near future but, ok, will keep them a bit more time, but please remember to update as soon as possible :-) > If it's more than clear for all developers, it's ok, but if not, it also has to > be written somewhere. > > Thanks a lot anyway. I understand being a developer is a demanding task, and > less thanked than they deserve. > No problem at all :-)
*** Bug 351164 has been marked as a duplicate of this bug. ***
It is my understanding that emul-linux-x86-* is mostly self contained and only relies on 32 bit toolchain packages. So 64 bit "old gtk+, perl, libpng..." would not cause failure.
But 32 bits version of glibc is provided by sys-libs/glibc directly, and the failures are caused by other 32 bits libraries being compiled on a chroot with glibc-2.11 and affected people trying to use them on a system still with older glibc versions
Exactly what I meant, glibc is the only package causing problems when there is an old version. And maybe gcc through libstdc++. So no tons of blockers.
But I am not sure about if it's really interesting to add that blockers to the eclass since: - That blockers should be updated from time to time (on glibc updates) in eclass depending on available emul packages in the tree. For example, version 2009xxxxxx could work with older glibc than 2010xxxxx or any other combination. This would make eclass more complex and (see next point) - I don't want people trying to use emul packages with too old systems, since I already saw problems in the past related with other libs that needed to be used on updated systems. Also, I always prefer to make people to run the most updated version if possible since older versions usually contain more security problems, known bugs only fixed in newer versions...
*** Bug 409671 has been marked as a duplicate of this bug. ***
*** Bug 442562 has been marked as a duplicate of this bug. ***
@amd64, Would having the blocker at emul-linux-x86-baselibs be enough? In that case it could be easily bumped on every emul set bump depending on glibc I use to build them. Also, would be better a blocker or a RDEPEND
*** Bug 444910 has been marked as a duplicate of this bug. ***
New set bumped
*** Bug 448768 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > @amd64, Would having the blocker at emul-linux-x86-baselibs be enough? In > that case it could be easily bumped on every emul set bump depending on > glibc I use to build them. Also, would be better a blocker or a RDEPEND RDEPEND=">=sys-libs/glibc-2.15" # Bump this to whatever the build box uses
(In reply to comment #16) > (In reply to comment #12) > > @amd64, Would having the blocker at emul-linux-x86-baselibs be enough? In > > that case it could be easily bumped on every emul set bump depending on > > glibc I use to build them. Also, would be better a blocker or a RDEPEND > > RDEPEND=">=sys-libs/glibc-2.15" # Bump this to whatever the build box uses I fixed it in latest emul set
