IRC channel logs

2024-10-24.log

back to list of logs

<aggi>nope, musl libc.so dynamic loader still errors with "illegal instruction", when compiled with tcc
<aggi>no big deal yet, because i hacked full static linking support into my system profile for i486-tcc-linux-musl
<aggi>however, then i can't keep perl/autotools for system integration, which is a whole other debate
<aggi>strangely, when musl-libc is compiled/linked with gcc then $ file libc.so # dynamic loader identifies as "LSB shared object .. dynamically linked"
<aggi>when compiled/linked with CC|LD=i386-tcc then $file libc.so identifies as "LSB shared object .. static-pie linked"
<aggi>no clue where the static-pie linked comes from, i think tcc handles this differently, when stuffing together ELF sections
<aggi>and although the _dlstart entry point of libc.so matches the adress, when executing ./libc.so "illegal instruction" is reported
<aggi>weird
<aggi>as a consequence, when musl-libc is compiled/linked with tcc, it can't support dynamic loading of shared objects
<aggi>hence, i can't keep Perl/autotools, for example, because it needs dynamic loading
<stikonas>perl should work statically
<aggi>ok, that's my main concern here, because i can live with static-linking
<aggi>but i failed to emit a fully working perl interpreter that is needed for autotools/automake
<aggi>stikonas: there's some hackjob floating on the internet, to support static-linking of perl, but that's much hazzle
<stikonas>you could always take a look at live-bootstra
<stikonas>we did get perl statically linked
<stikonas>feel free to borrow build scripts from there
<aggi>stikonas: i too got it, but it failed to support some extras needed by autotools/automake
<aggi>question, could you confirm autotools/automake/autoreconf?
<stikonas>I think mostly old ones
<stikonas>definitely not the latest
<stikonas>let me check
<aggi>i tested with perl-6.8.6 and automake-1.15.1 iirc
<aggi>*5.8.6
<stikonas>automake 2.15.1 and autoconf 2.69
<stikonas>1.15.1
<stikonas>yes
<stikonas>and perl 5.6.2 worked
<aggi>with a statically linked perl interpreter? this would be awesome stikonas !
<stikonas>haven't tried 5.8
<stikonas>yes
<aggi>ok, good enough
<stikonas> https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
<stikonas>there is no dynamic linking here till much later
<aggi>have you tried to spawn an autoreconf with any project?
<stikonas>we have used these steps to build perl https://github.com/fosslinux/live-bootstrap/blob/master/steps/perl-5.6.2/mk/main.mk
<stikonas>yes, almost surely
<aggi>ok
<aggi>good, i just tried the latest perl-version that tcc could digest; but perl-5.6 is fine if that is known to work
<stikonas>see that build script
<aggi>thanks!
<stikonas>you might have been missing some perl modules
<stikonas>they can be build statically into it
<stikonas>in particular here https://github.com/fosslinux/live-bootstrap/blob/master/steps/perl-5.6.2/mk/main.mk#L115
<stikonas>there are various extra extensions that are then built into perl statically
<stikonas>I guess normally those are dynamic
<oriansj>Googulator: thinking further on your UART question; if we use hardware flow control and if the builder-hex0 kernel stalls if the uart buffer is full, until it has capacity. Any speed would be acceptable (just slower speed terminals wouls significantly slow down the total process)
<oriansj>(There should be some good discrete 8bit UARTs that should meet that requirement)
<qbit>hi!
<stikonas>qbit: hi
<stikonas>fossy: looks like we again have some openssl trouble...
<stikonas> https://github.com/fosslinux/live-bootstrap/actions/runs/11507728726/job/32034492388
<aggi>don't mean to interrupt; there's another open question related to python, since i tried to statically compile/link that with tcc too
<aggi>the python bootstrapping isn't done with tcc to my knowledge, i didn't manage to see a python-3.18 pass with tcc
<aggi>and i didn't succeed with statically linking python with gcc/binutils either
<aggi>question is, if i had missed anything, because i can't keep python self-hosting with tcc/static-linking, hence will loose portage
<aggi>far less critical issue than the perl one, to keep autotools instead of rewriting hundreds of configure.ac/makefile.am