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
The emul packages are due for a bump I suppose. I'll make this change at the same time.
for ppc64 we don't use (to my knowledge) /emul going to unCC as a result.
What about emul-linux-ppc-glibc?
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.
take an axe to it. I'm quite happy to move forward and see no issues preventing that.
*** Bug 159482 has been marked as a duplicate of this bug. ***
i've fixed up all but emul-linux-x86-java as that one is pretty funky
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.
awesome ... i'm glad you felt the need to wait until now in order to say something
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.
bug wranglers do not want this for sure... :) Assigning back.
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.
/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.
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?
@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.
(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?
(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.
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).
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
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.
you're going to have to be a little more specific than "every app" my test apps: wine, acroread, vmware
*** Bug 160147 has been marked as a duplicate of this bug. ***
unmasked and bumped in portage ... the three aforementioned apps worked for me
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
fixed in cvs, cheers
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. ----
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).
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
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.
search bugzilla, the libstdc++.so issue is not really a regression
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)
i think we're done here, right?
*** Bug 180316 has been marked as a duplicate of this bug. ***
