| 1 |
On 2017-02-06 22:40, Walter Dnes wrote: |
| 2 |
|
| 3 |
> Right now, I'm using a 32-bit CentOS QEMU VM to build Pale Moon for |
| 4 |
> older machines. There's the usual processing overhead of a VM, plus |
| 5 |
> it has to have it's own virtual disks with safety margin of space, |
| 6 |
> plus 5 gigabytes of swap space inside the VM. |
| 7 |
> |
| 8 |
> What I'd like to do is a 32-bit CentOS chroot inside my 64-bit Gentoo |
| 9 |
> desktop host. I'm looking at rsync'ing the / directory from inside |
| 10 |
> the CentOS VM file system to a directory on the 64-bit host, and then |
| 11 |
> chroot into the copy on the host. |
| 12 |
> |
| 13 |
> Is it possible? Any booby-traps? Has anybody here done something |
| 14 |
> similar? |
| 15 |
|
| 16 |
It depends on how good the Pale build system is. What you would be |
| 17 |
doing is similar to cross-compiling, and you need the build system be |
| 18 |
ready for that kind of thing. |
| 19 |
|
| 20 |
A naive build system will pick up wrong configuration information by |
| 21 |
doing build-time checks that won't be valid at run-time. This is true |
| 22 |
even with a chroot, because checks can query directly the kernel via |
| 23 |
syscalls or stuff in /proc and /sys. There are probably other ways for |
| 24 |
the host system environment to leak, too. |
| 25 |
|
| 26 |
This is one reason why many stick to GNU auto* thingies despite their |
| 27 |
surface ugliness: they're actually battle tested in this situation. |
| 28 |
|
| 29 |
Unfortunately I'm not intimate with the Mozilla/Pale build system so I |
| 30 |
can't give you yea or nay, but maybe you can search for information |
| 31 |
whether it can be (really) cross-compiled. If yes, then your scenario |
| 32 |
should work too. |
| 33 |
|
| 34 |
-- |
| 35 |
Please *no* private Cc: on mailing lists and newsgroups |
| 36 |
Personal signed mail: please _encrypt_ and sign |
| 37 |
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html |
Archives