Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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. ***