Package dependencies on glibc 2.11.
David Brown
32-bit programs, such as firefox:
/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)
Should these libraries have a dependency on 2.11 of libc? Is the best
thing for me to do is just mask out these newer builds of these
libraries?
Thanks,
David
David Brown
Ok, that didn't work.
Trying these masks:
=app-emulation/emul-linux-x86-gtklibs-20100915
=app-emulation/emul-linux-x86-xlibs-20100915
=app-emulation/emul-linux-x86-baselibs-20100915
Gives me this, so I guess I'd have to track down more, and possibly
end up masking a lot of stuff:
Total: 0 packages, Size of downloads: 0 kB
!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:
app-emulation/emul-linux-x86-gtklibs:0
app-emulation/emul-linux-x86-xlibs:0
!!! The following installed packages are masked:
- app-emulation/emul-linux-x86-gtklibs-20100915 (masked by: package.mask)
/etc/portage/package.mask:
# These conflict with glibc < 2.11
- app-emulation/emul-linux-x86-xlibs-20100915 (masked by: package.mask)
- app-emulation/emul-linux-x86-baselibs-20100915 (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
So, am I better off trying to unmask libc, and moving forward with
that?
Thanks,
David
Ryan Harris
nspluginwraper-1.3.0
<snip>
-lgtk-x11-2.0 -lgdk-x11-2.0 -lgobject-2.0 -ldl -lglib-2.0 -lX11 -lXt -
ldl -lpthread -lgthread-2.0 -lsupc++
npviewer-npw-malloc.o: In function `memset':
/usr/include/bits/string3.h:82: warning: memset used with constant
zero length parameter; this could be due to transposed parameters
/usr/lib32/libcairo.so.2: undefined reference to
`__longjmp_chk@GLIBC_2.11'
collect2: ld returned 1 exit status
make: *** [npviewer.bin] Error 1
make: *** Waiting for unfinished jobs....
<snip>
Ryan Harris
> >/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 closed firefox after my last post.
> So, am I better off trying to unmask libc, and moving forward with
> that?
unmasking newer glibc. I see 2.11 is in the funtoo tree but i also
know that 2.12 is in gentoo. I'll wait to see what version, if any,
we're going to move to next. Besides it's not the end of the world ,
my links browser still works :).
Daniel Robbins
>
> I'm going to wait on comment from one of the funtoo devs before
> unmasking newer glibc. I see 2.11 is in the funtoo tree but i also
> know that 2.12 is in gentoo. I'll wait to see what version, if any,
> we're going to move to next. Besides it's not the end of the world ,
> my links browser still works :).
The emul-linux-x86 packages in gentoo, which are also now in funtoo,
are depending on glibc-2.11.
emul-linux-x86 is a really ugly situation to begin with - I need to
explore alternatives to it. Originally, for amd64, I chose a direction
of pure 64 bit and then using a Gentoo chroot 32-bit install for
32-bit apps. This would allow easy emerging of 32-bit applications,
which could be configured through some trickery to connect to your
64-bit X server. Other devs decided it would be better to go the
multilib route, but unfortunately they didn't add any features to
Portage to support this. So the 32-bit libs are all a hack on top of
Gentoo.
Regarding the immediate issue, Piotr and I are considering options for
dealing with it.
Regards,
Daniel
d2_racing
I have the same problem as David Brown.
My firefox lag big time when I'm on youtube or anything that use
flash.
Robert William Fuller
> emul-linux-x86 is a really ugly situation to begin with - I need to
> explore alternatives to it. Originally, for amd64, I chose a direction
> of pure 64 bit and then using a Gentoo chroot 32-bit install for
> 32-bit apps. This would allow easy emerging of 32-bit applications,
> which could be configured through some trickery to connect to your
> 64-bit X server. Other devs decided it would be better to go the
> multilib route, but unfortunately they didn't add any features to
> Portage to support this. So the 32-bit libs are all a hack on top of
> Gentoo.
I've been using a 32-bit chroot to run 32-bit applications from my
64-bit installation for years. It helps to bind mount the 64-bit /tmp,
/dev, /dev/shm, and /etc directories over the 32-bit chroot. I haven't
had any problems running 32-bit X clients. I can even boot my 32-bit
install if I chose, not that I ever do. I've been running funtoo with
the no-multilib profile, even though this isn't explicitly supported.
I never could get any kind of stability from the emul-linux-x86 stuff.
Rob
Daniel Robbins
<hydrolo...@gmail.com> wrote:
>
> I've been using a 32-bit chroot to run 32-bit applications from my 64-bit
> installation for years. It helps to bind mount the 64-bit /tmp, /dev,
> /dev/shm, and /etc directories over the 32-bit chroot. I haven't had any
> problems running 32-bit X clients. I can even boot my 32-bit install if I
> chose, not that I ever do. I've been running funtoo with the no-multilib
> profile, even though this isn't explicitly supported.
>
> I never could get any kind of stability from the emul-linux-x86 stuff.
>
> Rob
Rob, where have you been all my life? Can you get me a quick write-up
of how you config your system and what apps you are using in this
configuration? Much thanks!
Regards,
Daniel
Ryan Harris
> emul-linux-x86 is a really ugly situation to begin with - I need to
> explore alternatives to it.
multilib CLFS. I never had any issues with using it. Basically you
just build every package that had libs twice, once with 32bit flags ,
once with 64bit flags. Had to move a few files, add a few links, and
the mulitiarch wrapper took care of choosing the right lib for
packages that needed it. Not sure how much that will help you come up
with an alternative, but you might want to look at what they are
doing.
Oleg
packages are what i really hated, until I realized that non-multilib
is not supported by funtoo, had to reinstall everything for "supported
stuff". So, if 32 support fixed for funtoo, can we expect non-
multilib, pure 64 bit, builds?
On Sep 16, 8:20 pm, Daniel Robbins <drobb...@funtoo.org> wrote:
> On Thu, Sep 16, 2010 at 10:17 AM, Robert William Fuller
>
Daniel Robbins
> I used funtoo about 6 monthes with non-multilib profile. emul-linux-*
> packages are what i really hated, until I realized that non-multilib
> is not supported by funtoo, had to reinstall everything for "supported
> stuff". So, if 32 support fixed for funtoo, can we expect non-
> multilib, pure 64 bit, builds?
Yes, I will probably do that but I need more feedback from you and
others on what worked, what didn't, what issues you ran into, etc.
Regards,
Daniel
Jean-Francis Roy
--
You received this message because you are subscribed to the Google Groups "Funtoo" group.
To post to this group, send email to funto...@googlegroups.com.
To unsubscribe from this group, send email to funtoo-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/funtoo-dev?hl=en.
Oleg
one of my comp X-less, around 200 packages in total, and no one of
them really needs multilib support (except grub, probably). The
problems appears for desktop users: adobe flash, firefox, wine, skype
requires emul-linux-* packages.
On Sep 16, 9:37 pm, Jean-Francis Roy <jeanfrancis...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 2:15 PM, Daniel Robbins <drobb...@funtoo.org> wrote:
> > > I used funtoo about 6 monthes with non-multilib profile. emul-linux-*
> > > packages are what i really hated, until I realized that non-multilib
> > > is not supported by funtoo, had to reinstall everything for "supported
> > > stuff". So, if 32 support fixed for funtoo, can we expect non-
> > > multilib, pure 64 bit, builds?
>
> > Yes, I will probably do that but I need more feedback from you and
> > others on what worked, what didn't, what issues you ran into, etc.
>
> > Regards,
>
> > Daniel
>
> I'm willing to help for that. I used a no-multilib profile in the past with
> Gentoo without much issues. One would have been Flash (but with the new
> release of Flash Square in beta today, it's resolved as soon as there are
> official ebuids for it), and the other issues I had were with proprietary
> software that I don't use anymore anyway.
>
> ~JF
>
>
>
>
>
>
>
>
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Funtoo" group.
> > To post to this group, send email to funto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Pavel Volkovitskiy
David Brown
Here's what I've done to make a usable 32-bit chroot. Not sure how
much I really like it, but it does seem to work:
- Make a filesystem, and mount /gentoo32
- Unpack a stage 3 into the directory.
- Configure make.conf
- Copy /etc/resolv.conf, passwd* group* shadow* to the /gentoo32/etc
Run the following script to create the bind mounts
----------------------------------------------------------------------
#! /bin/bash
b() {
mount --bind /"$1" /gentoo32/"$1"
}
b dev
b dev/pts
b dev/shm
b proc
b sys
b usr/portage
b home
cp /etc/resolv.conf /gentoo32/etc/resolv.conf
----------------------------------------------------------------------
$ linux32 sudo chroot /gentoo32 /bin/bash
to enter the chroot
Within the chroot do emerges of the packages I need. I share portage
directories, so I don't do a --sync in the chroot. It seems to work.
Then for each 32-bit program I want to run, I make a symlink of the
same name as the program to this 'run32' script.
----------------------------------------------------------------------
#! /bin/bash
base=$(basename "$0")
if [ -e /gentoo32/usr/bin/$base -o -L /gentoo32/usr/bin/$base ]; then
prog=/usr/bin/$base
elif [ -e /gentoo32/opt/bin/$base -o -L /gentoo32/opt/bin/$base ]; then
prog=/opt/bin/$base
else
echo "Unable to find $base executable"
exit 1
fi
sudo chroot /gentoo32 sudo -u davidb -H env -u SUDO_COMMAND \
-u SUDO_USER \
-u SUDO_UID \
-u SUDO_GID \
$prog
----------------------------------------------------------------------
So far, I'm running firefox, acrobat, and chromium-bin. Firefox and
flash seem to actually work better this way.
David
Daniel Robbins
>
> So far, I'm running firefox, acrobat, and chromium-bin. Firefox and
> flash seem to actually work better this way.
Do the 32-bit apps inherit the DISPLAY environment variable when you
run the script and connect to your 64-bit X server with no issues?
Regards,
Daniel
Piotr Karbowski
I use mask like:
>app-emulation/emul-linux-x86-baselibs-20100611
>app-emulation/emul-linux-x86-gtklibs-20100611
>app-emulation/emul-linux-x86-medialibs-20100611
>app-emulation/emul-linux-x86-opengl-20100611
>app-emulation/emul-linux-x86-soundlibs-20100611
>app-emulation/emul-linux-x86-xlibs-20100611
>app-emulation/emul-linux-x86-compat-20100611
>app-emulation/emul-linux-x86-qtlibs-20100611
>app-emulation/emul-linux-x86-sdl-20100611
Can you test it? If it will work, I will push it to funtoo.
-- Piotr.
David Brown
Everything seems to work, I'm not even really quite sure why, since I
forgot to bind mount /tmp which is where the X socket is. Bind
mounting /tmp should fix that. Basically, X should be fine as long as
/tmp and the user's home directory are present. It is important that
the chroot invocations set the user's home directory properly.
Running strace on a program shows that it is still opening
/tmp/.X11-unix/X0 and the 'connect' works. This seems like a weakness
in chroot.
David
David Brown
>I use mask like:
>>app-emulation/emul-linux-x86-baselibs-20100611
>>app-emulation/emul-linux-x86-gtklibs-20100611
>>app-emulation/emul-linux-x86-medialibs-20100611
>>app-emulation/emul-linux-x86-opengl-20100611
>>app-emulation/emul-linux-x86-soundlibs-20100611
>>app-emulation/emul-linux-x86-xlibs-20100611
>>app-emulation/emul-linux-x86-compat-20100611
>>app-emulation/emul-linux-x86-qtlibs-20100611
>>app-emulation/emul-linux-x86-sdl-20100611
>
>Can you test it? If it will work, I will push it to funtoo.
I tried masking them. It seems that the same change that added the
new builds of the emul libraries, also removed the earlier ones.
David
Daniel Robbins
>
> Everything seems to work, I'm not even really quite sure why, since I
> forgot to bind mount /tmp which is where the X socket is. Bind
> mounting /tmp should fix that. Basically, X should be fine as long as
> /tmp and the user's home directory are present. It is important that
> the chroot invocations set the user's home directory properly.
>
> Running strace on a program shows that it is still opening
> /tmp/.X11-unix/X0 and the 'connect' works. This seems like a weakness
> in chroot.
Interesting. I will need to try this out. Also interested in looking
into the X socket and how it is getting used.
Thank you for sharing this information.
Regards,
Daniel
Robert William Fuller
My formula is pretty similar to David Brown's. I have a few more
directories that I'm bind mounting, notably /proc/bus/usb and /tmp. As
David correctly noted, X window's socket, among other essentials, is in
/tmp.
mount -o bind /dev /linux32/dev
mount -o bind /dev/pts /linux32/dev/pts
mount -o bind /dev/shm /linux32/dev/shm
mount -o bind /proc /linux32/proc
mount -o bind /proc/bus/usb /linux32/proc/bus/usb
mount -o bind /sys /linux32/sys
mount -o bind /tmp /linux32/tmp
mount -o bind /root /linux32/root
Again, I'm copying resolv.conf:
cp -pf /etc/resolv.conf /linux32/etc
One thing that I've done differently is convenient, yet insecure, but I
really don't care for my desktop system:
cp /bin/chroot /bin/schroot
chmod u+s /bin/schroot
This made it easier for me to write a shell function called l32() which
will let me run 32-bit versions of programs. That way I can do things
like this:
l32 acroread foo.pdf
l32 skype
l32 firefox
Unfortunately, the function l32() is so ugly that I cannot bring myself
to e-mail it to a public forum. In fact, trying to make that function
presentable is the reason it has taken so long to reply, but I might be
persuaded to share it privately :-)
Lastly, and THIS IS KEY, my /etc/auto.master mounts things to both / and
/linux32. This makes my home directory accessible under both /linux32
and /. It means l32() can do ugly things like change the directory so
that your "l32 acroread foo.pdf" gets run in the correct directory, such
as your home directory.
My auto.master looks like this:
/auto /etc/autofs/auto.auto
/linux32/auto /etc/autofs/auto.auto
/home /etc/autofs/auto.home
/linux32/home /etc/autofs/auto.home
The key drawback to the 32-bit chroot approach is identifying which
directories need to be mounted to /linux32. For example, dbus seems a
little touchy about the chroot environment. Once it has been started
from your 32-bit Linux, things are okay though. You never have to
explicitly start it again, regardless of rebooting. I think it must be
squirreling away state in an odd place (/var?), but I have not delved
into it.
I hope this (belated) reply helps.
Rob
David Brown
>One thing that I've done differently is convenient, yet insecure, but I
>really don't care for my desktop system:
>
> cp /bin/chroot /bin/schroot
> chmod u+s /bin/schroot
Well, I added
%wheel ALL = NOPASSWD: /usr/bin/chroot
to my sudoers, so it's pretty much the same thing, except that I then
have to unset the environment variables that sudo sets or acroread
won't run.
David
Jon Scruggs
I have had long discussions with my brother concerning 64 bit and 32
bit applications on the same system. My brother knows the Intel CPUs
inside and out with his job at Intel, so I trust what he says. My
argument is that all current OSes do things incorrectly. There are
essentially two operating systems installed the system ... one for 64
bit apps and one for 32 bit apps since they don't let them talk to
each other. My brother agrees with this. At Intel they have special
testing software where they have 64 bit compiled libraries calling 32
bit compiled libraries and vise versa. If you want an absolute true
solution to this, make the 32 bit apps work with 64 bit compiled code
and vise versa. The processor is smart enough to know what code it is
dealing with and switches modes automatically. The one thing that
needs to be done is to make sure both codes can handle the data
correctly, ie knowing that a certain library is returning 32 bit data
and expects 32 bit data, or the same with 64 bit libraries. It may be
harder work to set up and some patches need to be done to GCC so that
it actually links correctly, but it is worth it. When 128 bit
processors come out, will you expect to have people have 3 systems
installed on the system: one for 32 bit legacy, one for 64 bit and
then one for 128 bit stuff? No. That's ludicrous. The situation needs
to be fixed now so that users have one system and 32 bit compiled
binaries play nicely with 64 bit compiled binaries. Then no more of
the emul stuff and no more chroots. They can work together. The
programs my brother uses at Intel prove they can. The CPUs can
support, so why not use it? Linux needs to be fixed. MS Windows has
two separate directories as well. It's just insane to have everything
twice on computer just to run 32 bit stuff. And pretty soon, it will
be three times everything.
My two cents. I can go on longer about it and more in depth, but I
figured I would give you all the shortened for of our discussions.
Because, both emul packages and chroots feel like a hack rather than a
real solution. We need real solutions here, and this is one. :)
d2_racing
/opt/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib32/libc.so.6:
version `GLIBC_2.11' not found (required by /usr/lib32/libfreetype.so.
6)
Piotr Karbowski
Due new emul-linux thing. Use mask what I posted here, work for me, I
will push it to funtoo anyway.
-- Piotr.
Daniel Robbins
> Daniel,
>
> I have had long discussions with my brother concerning 64 bit and 32
> bit applications on the same system. My brother knows the Intel CPUs
> inside and out with his job at Intel, so I trust what he says. My
> argument is that all current OSes do things incorrectly. There are
> essentially two operating systems installed the system ... one for 64
> bit apps and one for 32 bit apps since they don't let them talk to
> each other.
[snip]
> My two cents. I can go on longer about it and more in depth, but I
> figured I would give you all the shortened for of our discussions.
> Because, both emul packages and chroots feel like a hack rather than a
> real solution. We need real solutions here, and this is one. :)
I would love to see this issue truly fixed. In the interim, I like the
chroot solution because it avoids doing screwy things with all 64-bit
systems to hack in 32-bit support, and it's optional for those users
who don't need 32-bit. Which seems like an improvement.
That being said, I would love to get some sample code from your
brother showing how 64->32 bit calls and 32->64 bit calls should be
handled, and if you and he are willing to push this forward, I am
definitely willing to support it from a distro perspective and help
get it adopted in the Linux community. I can support the effort where
I can but low-level ELF hacking and x86 asm is not my forte. I'm sure
many users would love to be free of all the problems associated with
this "two worlds" problem. Sort of seems like the current approach was
designed by George Costanza of Seinfeld -- "Anybody knows, you gotta
keep your worlds apart!!!"
that snippet of this from Seinfeld:
http://www.youtube.com/watch?v=uPG3YMcSvzo&feature=related
Full 10 min video from that episode:
http://www.youtube.com/watch?v=RLDxaJlblaY&feature=related
-Daniel
David Brown
>> I have had long discussions with my brother concerning 64 bit and 32
>> bit applications on the same system. My brother knows the Intel CPUs
>> inside and out with his job at Intel, so I trust what he says. My
>> argument is that all current OSes do things incorrectly. There are
>> essentially two operating systems installed the system ... one for 64
>> bit apps and one for 32 bit apps since they don't let them talk to
>> each other.
>
>[snip]
>
>> My two cents. I can go on longer about it and more in depth, but I
>> figured I would give you all the shortened for of our discussions.
>> Because, both emul packages and chroots feel like a hack rather than a
>> real solution. We need real solutions here, and this is one. :)
>
>I would love to see this issue truly fixed. In the interim, I like the
>chroot solution because it avoids doing screwy things with all 64-bit
>systems to hack in 32-bit support, and it's optional for those users
>who don't need 32-bit. Which seems like an improvement.
In general, I would guess this isn't a readily solvable problem.
The kernel itself presents two independent syscall interfaces, one for
64-bit and one for 32-bit. The kernel API is relatively simple, but
for a large number of these calls, it ends up having separate entry
points. Some are just wrappers that fixup structs and such. Others
are separate code. For calls like 'ioctl', there is quite a lot of
code that has to be kept up to date for every ioctl present in the
system. The code has to know the details of every ioctl, and what
direction the data flows in. It is also made by hand.
The problem is that simple data structures that are used in calls end
up being different:
struct foo {
struct bar *other;
int a;
long b;
};
has different sizes and offsets for every field in the structure. It
would be far from trivial to automatically somehow convert between
these structures, and do so correctly. It is especially difficult
since C doesn't have any way of specifying which direction data is
supposed to flow through an API.
Probably the only practical way of doing this, aside from a chroot,
would be to get all of the necessary libraries to build with multilib.
David
Daniel Robbins
> The problem is that simple data structures that are used in calls end
> up being different:
>
> struct foo {
> struct bar *other;
> int a;
> long b;
> };
Yep, I think that is the heart of the problem. It is a problem with
the C language that defines "int" to mean one thing on a 32-bit system
and another on a 64-bit system. But I think if this were not the case
and an "int" (and pointers) were always the same thing, then 64-bit to
32-bit calls would be relatively easy to do.
I am wondering if you place all your 32-bit calls in a single object
file that is compiled 32-bit, if this could resolve the issue.
Basically you would abstract away the size differences in the 32-bit
object file, then link the 32-bit object file with your 64-bit code.
Then the calls go like this:
64 bit code -> 32-bit high-level wrapper -----32-bit data
structure----> 32-bit kernel call
and the result is passed this way:
32-bit kernel call ----> 32-bit data structure --> 32-bit high-level
wrapper -> 64-bit code.
I could see this working even if header files have ambiguous "ints"
and such in them since you have a layer of abstraction that you wrote
using 32-bit conventions (you would treat "int" as 32-bit in this
code, and use "int64" or whatever when you were explicitly defining a
64-bit structure to be consumed by the 64-bit code.) But I'm not a
kernel programmer so I'm not familiar with the potential issues --
though I'd like to learn more about this.
At least I see this working for ints. When it comes to pointers,
that's when things get tricky, but maybe Intel has an approach for
this.
Regards,
Daniel
Jean-Francis Roy
Daniel Robbins
This is probably something that I can address in the funtoo profile in
development.
Regards,
Daniel
d2_racing
Use that specific version :
www-plugins/adobe-flash-10.2.161.22_pre20100915
David Brown
>On Fri, Sep 17, 2010 at 09:24:25AM -0600, Daniel Robbins wrote:
>>On Thu, Sep 16, 2010 at 11:32 PM, David Brown <dav...@davidb.org> wrote:
>>>
>>> So far, I'm running firefox, acrobat, and chromium-bin. �Firefox and
>>> flash seem to actually work better this way.
>>
>>Do the 32-bit apps inherit the DISPLAY environment variable when you
>>run the script and connect to your 64-bit X server with no issues?
>
>Everything seems to work, I'm not even really quite sure why, since I
I've just discovered my first non-working thing with the chroot:
32-bit apps don't see any of the printers defined in cups in the
64-bit world. I'm not familiar enough with cups to know how to share
this, maybe I just need to copy some more files from /etc/cups.
David
Daniel Robbins
> I've just discovered my first non-working thing with the chroot:
> 32-bit apps don't see any of the printers defined in cups in the
> 64-bit world. I'm not familiar enough with cups to know how to share
> this, maybe I just need to copy some more files from /etc/cups.
I think you should be able to share printers out from 127.0.0.1 on the
64-bit side, and have 32-bit apps "see" them... don't know if you'll
need to run 2 versions of cups, one 64-bit and another 32-bit? That
would stink.
-Daniel
David Brown
I figured out a better way. I just need to bind mount /var/run into
the chroot. Cups keeps it's socket in there. Now the cups library
just talks directly to the 64-bit cups server, which fortunately seems
to work in this configuration.
David