IRC channel logs

<aggi>i fear musl-libc may not support dynamic linking with libc.so when compiled/linked by tcc-toolchain

<aggi>tcc-linker is missing -e<ENTRY> option, which i wouldn't know how to quickly implement this

<aggi>nor a way to hack around this (libc.so dynamic loader got it's entry point at a function named _dlstart, whose -T<text-address> is variable)

<aggi>next, i tried to compile all musl object files with tcc (which works), and link with gcc/ld temporarily -> this segfaults libc.so

<aggi>otherwise, when statically linking against libc.a, this does work already as it should (for the few binaries that i chose explicitely for static linking)

<aggi>i'll have to postpone dynamic linking support with tcc, and switch the entire profile to static linking

<andydude>aggi: dynamic linking is a nightmare

<aggi>now i remember, how the entire GNU-buildsystem tree collapsed: static linking

<aggi>if for some reason, static-linking was necessary, perl with it's XSLoader doesn't work, that is needed for the installperl target however

<aggi>then next, of cause, automake will be missing perl that it needs, and without automake, GNU-buildsystem is completely defunct

<aggi>back to musl-libc where this problem originated, it can't be used with dynamic linking when compiled by tcc

<aggi>for example, tcc linker can't do tcc -e _dlstart, to set a special executable entry point

<aggi>as a consequency, currently, the entire system profile is locked against gcc/binutils and gnu-buildsystem

<aggi>next i tried to compile musl-libc with tcc, and link it with binutils-ld -> Segfault (for no obvious reason yet, because static linking against the exact same libc objects yields working executables)

<aggi>i'll be loosing several crucial build-time depenencies all at once: python/portage, perl, automake

<aggi>since this seems unavoidable, i may not waste too much time, and transition towards the lua/oasis-linux style system integration soon

<aggi>it is probably no coincidence, the developer restricted his approach to static linking too (i think he chose musl+cproc+binutils)

<aggi>currently it is _not_ feasible to keep gentoo/portage/perl/gnu-buildsystem self-hosting with tcc-toolchain

<aggi>oriansj: besides, there seems an important difference between oasis-linux and guix/scheme

<aggi>oasis-linux re-implements both, the packaging (ebuild equivalent) AND GNU-buildsystem (completely removing automake/configure etc); while guix/scheme seem to implement the packaging but relies upon GNU-buildsystem still

<aggi>even if i managed to hack into tcc linker for -e<entrypoint> support (required for dynamic linking against libc.so), then the whole python/portage/libffi issue remains unresolved, and patching libffi is beyond my abilities i fear

<aggi>so there was either notable amounts of efforts needed to maintain something i wouldn't necessarily want, that is python/portage/gnu-buildsystem

<aggi>or there is giant amounts of efforts needed to approach oasis-linux doing a full re-integration for tcc-toolchain and the no-c++ system-profile over there

<andydude>aggi: this just reinforces my irrational fear of perl5

<andydude>or rather, gives it justification and brings it closer to rational

IRC channel logs

2024-08-03.log