On 07/07/2016 02:15 PM, Peter Crady wrote: [your mailer isn't configured to wrap long lines, which makes it harder to read and reply] > This may be a stupid question but is there a good way to run autoconf in a chrooted environment? Do it the same way you run any other program - just run it. Remember, if you have to modify autoconf to behave differently, then you would have to modify every other program in the chroot environment in the same manner; the whole point of autoconf is to probe the actual environment it is running under. So if autoconf isn't getting the answers you want, then it is your environment at fault, not autoconf. And these days, chroot'd environments aren't as secure as cgroups, containers or virtual machines, so you may want to look into those technologies for better isolation of your test environment from your host environment. > From what I can tell the AS_UNAME function calls uname which gets information about the base kernel that is installed and not the kernel that is installed in the chrooted environment. If you're referring to uname(1) (the command line utility run by AS_UNAME), then it is up to you whatever uname(1) binary you installed into your chroot. If your uname(1) binary isn't returning the information you want, then it's your fault for building an incomplete chroot. And if your uname(1) in the chroot is returning the modified information, then AS_UNAME will see that modified information, not the base kernel information. If you're referring to uname(2) (the system call, which is generally what gets used under the hood by the uname(1) binary), then that depends on whatever kernel is actually running the binary that makes the syscall. If you are using merely chroot, then yeah, things are being run by a single kernel (chroot isolates files, but not the kernel used to run the files); which is where other technologies like containers (such as docker) or virtual machines (such as qemu) indeed let you turn on even more pieces to the point of completely running your test as if it were a different machine and kernel than the host. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf