Re: HURD and Linux on same partition
>On Tuesday, December 11, 2018 05:58:51 PM deloptes wrote:
>> Marek Mosiewicz wrote:
>> > |Just asked if it is technically possible. Application do not call
>> > kernel directly and they are using glibc library for example. I'm just
>> > curios how many libraries are there for abstracting kernel and if it is
>> > possible in future release to have common libraries which base on this
>> > abstraction. I'm just curios so I ask.
>> obviously you have no idea, so give it up, please!
>Well, I'm not the OP, but I am somewhat interested more out of curiosity than
>any real intent to try the HURD.
>I suspect the following:
> * Libraries (and other software) in source form might be valid / work for
>either kernel, but they have to be compiled for the specific kernel they are to
>be used on, and once in compiled / binary form, they won't work on the other
> * Is there any way to have libraries compiled for both kernels on the same
>partition -- well, I suppose so (different directories, or maybe even named
>differently?), but the complexity and potential for confusion just wouldn't
>seem worth it to me -- what would be the reason to do that?
Yes, it should work. With multi-arch in Debian (which moves most
libraries to specific architecture and kernel specific paths), the
*only* thing that might break for most binaries would be the path to
the dynamic loader, ld.so. For most recent systems they've been
deliberately specified to be different, so you can easily have
co-existing systems installed. See
for an overview of those. Some common examples:
so they're compatible.
As an example of this working, the very machine I'm using to send this
message is arm64 natively, but it's also set up with a small i386
installation on the same rootfs using multi-arch so I can also still
run some i386 binaries using qemu when needed. It used to be an x86
machine, but I've recently migrated to new hardware.
For cross-kernel setups like Linux and Hurd, you might find other
problems like clashing configurations in /etc. But it's not
Steve McIntyre, Cambridge, UK. firstname.lastname@example.org
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html