Re: [dev] obase - Sta.li moving forward?

From: Strake <strake888_AT_gmail.com>
Date: Tue, 5 Jun 2012 07:48:56 -0500

On 05/06/2012, Jens Staal <staal1978_AT_gmail.com> wrote:
> Hi
>
> I was playing with packaging Christian's obase for Arch
> https://aur.archlinux.org/packages.php?ID=56826

Thanks, never knew that before.

> and an easy-to-chroot package to complement it
> https://aur.archlinux.org/packages.php?ID=59735
>
> The idea I had was that one could use this environment as a gradual
> experimental environment to build up a complete alternative OS by a
> custom init chrooting into /opt/obase.
> When it has been completely assembled and self-hosting, one could make
> it into an independent system.
>
> I hope to update both to musl and complete static in the near future.
>
> At the moment I have some issues with that the binaries refuse to be
> 100% static
> an output of ldd gives:
>
>> ldd ./ksh
> linux-vdso.so.1 => (0x00007fffff393000)
> libc.so.6 => /lib/libc.so.6 (0x00007fd020358000)
> /lib/ld-linux-x86-64.so.2 (0x00007fd0206f9000)
>
> as long as those dynamic dependencies are present, the chroot idea
> will not work.

Against which C library?

The first is not a file, but rather code kept in the kernel and loaded
in the memory space of every proc on the system.

http://www.trilithium.com/johan/2005/08/linux-gate/

Thus, it ought to not make grief, in this way at least.
Clearly the others will.

> and adding static as CC="$CC -static" or in CFLAGS or LDFLAGS does not help
> :(

With which linker? If GNU, which is likely on Linux, then it may be
broken as designed.

One method to build a full system is to build a toolchain unable to
dynamic link at all, and itself static-linked, and then with it build
the other wares. Crosstool-ng can build such a toolchain.

Cheers,
strake
Received on Tue Jun 05 2012 - 14:48:56 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 05 2012 - 15:00:08 CEST