Bug 439324 – sys-apps/proot - User-space implementation of chroot, mount --bind, and binfmt_misc

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description James Le Cuirot 2012-10-22 21:18:40 UTC]

Created attachment 327178 [details]
proot-2.2.ebuild

The embedded guys will love this one. It's a userspace implementation of chroot that transparently handles binfmt_misc. No more headaches with building and copying static QEMU binaries!

[Comment 1 Jeroen Roovers (RETIRED) 2012-10-23 09:55:05 UTC]

Comment on attachment 327178 [details]
proot-2.2.ebuild

RDEPEND=""

Not needed.

src_compile() {
     cd src || die

Not needed.

		CFLAGS="${CFLAGS} -Wall" \

Why do you add to CFLAGS? You should document it. If you can't you should remove it.

     cd tests || die

Not needed.

[Comment 2 James Le Cuirot 2012-10-24 08:05:40 UTC]

Created attachment 327286 [details, diff]
proot-2.2.ebuild

Better?

[Comment 3 James Le Cuirot 2013-01-23 07:30:01 UTC]

Created attachment 336544 [details]
proot-2.3.1.ebuild

New version.

[Comment 4 James Le Cuirot 2013-01-23 07:30:38 UTC]

Created attachment 336546 [details, diff]
proot-2.3.1-gnu-define-fix.patch

This patch fixes some undefined references. It has been applied upstream.

[Comment 5 James Le Cuirot 2013-01-23 08:02:49 UTC]

Created attachment 336548 [details]
proot-2.3.1.ebuild

Forgot the multilib eclass.

[Comment 6 Sergey Popov (RETIRED) 2013-01-23 12:14:12 UTC]

Comment on attachment 336546 [details, diff]
proot-2.3.1-gnu-define-fix.patch

Change patch name

[Comment 7 Sergey Popov (RETIRED) 2013-01-23 12:15:33 UTC]

Created attachment 336578 [details]
proot-2.3.1.ebuild

Updated ebuild(reorganize CFLAGS/LDFLAGS workaround in makefile patch)

[Comment 8 Sergey Popov (RETIRED) 2013-01-23 12:16:19 UTC]

Created attachment 336580 [details, diff]
proot-2.3.1-makefile.patch

Patch for makefile to correctly handle CFLAGS and LDFLAGS

[Comment 9 Sergey Popov (RETIRED) 2013-01-23 12:37:33 UTC]

Created attachment 336582 [details, diff]
proot-2.3.1-libpath-fix.patch

James, what's the problem with ldso_paths, that you need to fix them? I suggest simple patch just for removing unneeded paths, the rest upstream logic seems fine.

[Comment 10 Sergey Popov (RETIRED) 2013-01-23 12:38:53 UTC]

Created attachment 336586 [details, diff]
proot-2.3.1-libpath-fix.patch

Attaching correct patch, previous had incorrect paths

[Comment 11 James Le Cuirot 2013-01-23 13:09:05 UTC]

I was emulating i386 on x86_64 (long story) and it was using the host's lib32 directories over those inside the root for every binary, because it adds these directories to LD_LIBRARY_PATH. You probably wouldn't use a 32-bit QEMU on a 64-bit system (certainly not if it's installed through Portage) so I figured just adding libdir was the best option. If you really do want other directories added then you can do so manually by setting LD_LIBRARY_PATH before starting proot.

I tend to avoid patches when it's not too messy because it's more likely to work with future versions but it's fine. Not sure if it's Gentoo policy or your own preference.

[Comment 12 Sergey Popov (RETIRED) 2013-01-23 13:21:30 UTC]

(In reply to comment #11)
> I was emulating i386 on x86_64 (long story) and it was using the host's
> lib32 directories over those inside the root for every binary, because it
> adds these directories to LD_LIBRARY_PATH. You probably wouldn't use a
> 32-bit QEMU on a 64-bit system (certainly not if it's installed through
> Portage) so I figured just adding libdir was the best option. If you really
> do want other directories added then you can do so manually by setting
> LD_LIBRARY_PATH before starting proot.

Well, in this case i think using 64-bit qemu with apropriate options for emulating 32-bit applications is possible.

> I tend to avoid patches when it's not too messy because it's more likely to
> work with future versions but it's fine. Not sure if it's Gentoo policy or
> your own preference.

Your seds was not so clear, i need to generate diff to discover what's going on. In such cases patches are preferrable.

I will double-check all things(tests also) and do some cleanups, then i will add it to tree.

[Comment 13 James Le Cuirot 2013-01-23 14:22:31 UTC]

(In reply to comment #12)
> (In reply to comment #11)
> > I was emulating i386 on x86_64 (long story) and it was using the host's
> > lib32 directories over those inside the root for every binary, because it
> > adds these directories to LD_LIBRARY_PATH. You probably wouldn't use a
> > 32-bit QEMU on a 64-bit system (certainly not if it's installed through
> > Portage) so I figured just adding libdir was the best option. If you really
> > do want other directories added then you can do so manually by setting
> > LD_LIBRARY_PATH before starting proot.
> 
> Well, in this case i think using 64-bit qemu with apropriate options for
> emulating 32-bit applications is possible.

Not sure what you mean? proot will execute binaries natively if it can, regardless of whether you've specified QEMU via the -q option. You can force the use of QEMU by setting the undocumented PROOT_FORCE_FOREIGN_BINARY=1 option, but even then, it'll still use libraries from the host's lib32 directory instead of the root's own libraries.

[Comment 14 Sergey Popov (RETIRED) 2013-01-24 08:56:21 UTC]

+  24 Jan 2013; Sergey Popov <[e-mail]> +proot-2.3.1.ebuild,
+  +files/proot-2.3.1-gnu-define-fix.patch,
+  +files/proot-2.3.1-lib-paths-fix.patch, +files/proot-2.3.1-makefile.patch,
+  +metadata.xml:
+  Initial commit, wrt bug #439324, thanks to James Le Cuirot