143390 2006-08-09 14:00 0000 killing /emul and moving to pure lib32 2007-05-30 07:13:31 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified All Linux RESOLVED FIXED P2 enhancement --- 165270 1 vapier@gentoo.org amd64@gentoo.org diggerster@gmail.com dpblnt@gmail.com eradicator@gentoo.org gentoo@jacquido.demon.nl jadamcze@utas.edu.au jdaluz@gmail.com kugelfang@gentoo.org nigoro@gentoo.org rickard.narstrom@gmail.com thothonegan@gmail.com toolchain@gentoo.org voyageur@gentoo.org vapier@gentoo.org 2006-08-09 14:00:07 0000 can you guys please change all the emul-* packages to install into normal lib32 dirs rather than /emul ? /lib32 /usr/lib32 etc... and then stop installing env.d files to update LDPATH herbs@gentoo.org 2006-08-21 04:37:54 0000 The emul packages are due for a bump I suppose. I'll make this change at the same time. tgall@gentoo.org 2006-11-13 14:13:25 0000 for ppc64 we don't use (to my knowledge) /emul going to unCC as a result. angelos@gentoo.org 2006-11-15 10:05:30 0000 What about emul-linux-ppc-glibc? wolf31o2@gentoo.org 2006-11-15 11:07:39 0000 Well, app-emulation/emul-linux-ppc-glibc doesn't look like it is used. If that's the case, then it's probably time to remove it from the tree. This would be up to ppc64 to decide, of course. Adding them back to CC for the time being. tgall@gentoo.org 2006-12-27 09:03:41 0000 take an axe to it. I'm quite happy to move forward and see no issues preventing that. jakub@gentoo.org 2006-12-30 07:27:19 0000 *** Bug 159482 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2007-01-02 23:37:45 0000 i've fixed up all but emul-linux-x86-java as that one is pretty funky tester@gentoo.org 2007-01-03 06:28:32 0000 Wrong wrong wrong wrong... You can't do that. Many libs have hardcoded path (like GTK+ looking for themes/gdkpixbuf loaders) in a specific path. You need to rebuild them to do it. vapier@gentoo.org 2007-01-03 08:29:55 0000 awesome ... i'm glad you felt the need to wait until now in order to say something tester@gentoo.org 2007-01-03 09:36:23 0000 Now you see why I think this is not a good idea. Rebuilding the emul packages is very painful. And I still think that moving them to lib32 will cause us problem if/when we move to a true portage-managed multilib implementation. If we still really want to do the move, I guess we can move progressively has they get rebuilt to follow the rest of the stuff. jakub@gentoo.org 2007-01-03 09:37:22 0000 bug wranglers do not want this for sure... :) Assigning back. cardoe@gentoo.org 2007-01-04 08:40:44 0000 vapier: you totally broke every single ia32 application on amd64. I've been complaining about this since you made the change... but no one in amd64 has acknowledged the problem. Users in #gentoo-amd64 are complaining and are being told it's their own systems. cardoe@gentoo.org 2007-01-04 08:50:47 0000 /etc/gtk-2.0/i686-pc-linux-gnu/gdk-pixbuf.loader needs to be corrected as far as the paths go for all the loaders. Fixing that makes graphics show up on GTK+ components again for me. However the text is still broken. kevquinn@gentoo.org 2007-01-04 09:41:16 0000 four months with no contrary comments since the initial proposal - was no-one on amd64@g.o able to anticipate this was going to be a problem? tester@gentoo.org 2007-01-04 11:06:09 0000 @kevquinn: I said so a long time ago, I though everyone else involved was aware of how painful this would be. @cardoe: Its not that simple, the file is autogenerated. The actual paths are hardcoded in the libgtk. And its not the only lib that, I know at least pango, gtk+1, jack, pam and openssl have hardcoded paths. If the broken ebuilds are still there when I reach home tonight, I'll remove them. kevquinn@gentoo.org 2007-01-04 12:28:50 0000 (In reply to comment #15) > @kevquinn: I said so a long time ago, I though everyone else involved was aware > of how painful this would be. Well; there's a simple lesson :) Make sure people know by commenting it when a bug is raised to implement something you anticipate will be a problem. That way it can't be missed, forgotten, lost in the mists of IRC. > @cardoe: Its not that simple, the file is autogenerated. The actual paths are > hardcoded in the libgtk. And its not the only lib that, I know at least pango, > gtk+1, jack, pam and openssl have hardcoded paths. There has to be something wrong when paths are hardcoded - is there not an automatic mechanism for binaries to search the library paths that match their ABI? tester@gentoo.org 2007-01-04 12:58:51 0000 (In reply to comment #16) > There has to be something wrong when paths are hardcoded - is there not an > automatic mechanism for binaries to search the library paths that match their > ABI? Sadly not for plugins, hence paths get hardcoded. Mostly anything that's a subdirectory of /usr/lib /lib means hardcoded path. tester@gentoo.org 2007-01-04 17:13:50 0000 kugelfang p.masked them. I removed the gtklibs one, because it was the one causing the most problems. The rest should probably be pulled from the tree too. And if we really want to move (I certainly think its a major waste of time), then that motivated person has to rebuild the packages (and definitely needs to find a significant other). vapier@gentoo.org 2007-01-04 17:53:45 0000 they are going to be moved ... /emul was a mistake as Kevin said, if there are problems, they need to be stated or things are going to be changed where are all these mysterious paths you refer to ? i see: - config files: simple sed fixes that - hardcode rpaths: simple call to chrpath fixes that tester@gentoo.org 2007-01-04 21:14:54 0000 at least in libgtk+, the /emul/linux/x86/usr/lib/gdk-pixbuf/ is hardcoded somewhere in the lib (took me a while to figure this one when I built the gtk+ lib) as the PIXBUF_LIBDIR #define. I kind of assumed that the same thing was done for pango and the other gnomish stuff that has runtime plugins. And I guess gtk+1 also does the same, and its even more annoying to build. Anyways, if you want to rebuild them, make sure every app that uses the libs still works. vapier@gentoo.org 2007-01-04 21:29:55 0000 you're going to have to be a little more specific than "every app" my test apps: wine, acroread, vmware vapier@gentoo.org 2007-01-04 23:11:11 0000 *** Bug 160147 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2007-01-04 23:14:29 0000 unmasked and bumped in portage ... the three aforementioned apps worked for me voyageur@gentoo.org 2007-01-05 02:14:20 0000 The patchs get installed in the system in /emul-linux-x86-xlibs-*patch. Apart from this, it looks like pango/gtk dialogs of firefox-bin work again vapier@gentoo.org 2007-01-05 02:25:08 0000 fixed in cvs, cheers rickard.narstrom@gmail.com 2007-01-05 03:53:17 0000 Is this relative, or shuld I submit a new bugrepport? ---- * Applying emul-linux-x86-qtlibs-3.4.4-r3-emul.patch ... * Failed Patch: emul-linux-x86-qtlibs-3.4.4-r3-emul.patch ! * ( emul-linux-x86-qtlibs-3.4.4-r3-emul.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/app-emulation/emul-linux-x86-qtlibs-3.4.4-r3/temp/emul-linux-x86-qtlibs-3.4.4-r3-emul.patch-11763.out !!! ERROR: app-emulation/emul-linux-x86-qtlibs-3.4.4-r3 failed. Call stack: ebuild.sh, line 1593: Called dyn_unpack ebuild.sh, line 731: Called src_unpack emul-linux-x86-qtlibs-3.4.4-r3.ebuild, line 34: Called epatch 'emul-linux-x86-qtlibs-3.4.4-r3-emul.patch' eutils.eclass, line 341: Called die !!! Failed Patch: emul-linux-x86-qtlibs-3.4.4-r3-emul.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. ---- tester@gentoo.org 2007-01-05 07:46:59 0000 To your list add firefox-bin and real (the 2 most used emuled apps), a gtk+1 app (like nero linux), something that uses qt (skype non-static?), something that uses pam (I have not idea what) and something that uses jack. And I still think that pre-build stuff should not be in /usr (like we have /opt for applications, the libs should also not be there). vapier@gentoo.org 2007-01-06 09:43:41 0000 i agree it sucks having binary packages at all and cramming them in /opt would be ideal ... but that's only if it doesnt turn around and screw the rest of the toolchain which is exactly what is happening now we have too many hacks in place to try and teach the system about /emul while support for /lib32 is inherit in the system nonno.cicala@libero.it 2007-01-11 02:12:43 0000 zsnes-1.42 stops working if I install app-emulation/emul-linux-x86-compat-1.0-r2 . It says: zsnes: /usr/lib32/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by zsnes) While emerging emul-linux-x86-compat-1.0-r2 I noticed this: QA Notice: the following shared libraries lack NEEDED entries /var/tmp/portage/emul-linux-x86-compat-1.0-r2/image/usr/lib32/libc.so.5 That message doesn't appear with -r1 , and I also verified that the files installed were the same. vapier@gentoo.org 2007-01-11 16:51:13 0000 search bugzilla, the libstdc++.so issue is not really a regression nonno.cicala@libero.it 2007-01-11 20:54:34 0000 Right, if I rm /usr/lib32/libstdc++.so.6* it works. Thank you! (I thought that bugs introduced by the /emul -> /lib32 transition would have been posted here, sorry for the duplicate) blubb@gentoo.org 2007-02-06 12:47:06 0000 i think we're done here, right? jakub@gentoo.org 2007-05-30 07:13:31 0000 *** Bug 180316 has been marked as a duplicate of this bug. ***