<aggi>
re-created the entire toolchain, backed down to armv6j-hardfloat-linux-musleabihf, which is armv6/vfpv2
<aggi>
if am not mistaken again, this should be a most broadly compatible choice among aarch32 systems
moteen has quit [Ping timeout: 480 seconds]
<aggi>
not sure, if the EABI4/EABI5 mismatch of arm-tcc and gcc/binutils will hit some other issues
sunshavi has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
sunshavi has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
Guest5186 is now known as palmer
moteen has quit [Remote host closed the connection]
<karlp>
I must be misunderstanding something, you're not using any recent compilers because the compiler is written in c++? and that's a blocker for you?
<aggi>
karlp: yes, and it's not the only criteria
<aggi>
furthermore, the downgrade to gcc-4.7 served as a preparation to fully integrate arm-tcc or arm64-tcc (or anything else long-term stable)
moteen has joined #linux-sunxi
<karlp>
what are the other criteria?
<aggi>
without mentioning all technical details: a clean and reproducible bootstrapping procedure, 100% source-based workflow, ideally down to hardware
<aggi>
although i am not aware of any recent aarch32 with Verilog/HDL available for an opensource SoC FPGA deployment
<aggi>
to remain on the software-side, with aarch32/64 the integration of arm-tcc will certainly remain blocked for a while, until linux kernel can be compiled (without gcc or clang)
<aggi>
with uboot loader there is another block (python-swig/c++)
chewitt has quit [Read error: Connection reset by peer]
<aggi>
hence, i focus on userspace first with aarch32, to fully integrate arm-tcc, including bootstrapping gcc-4.7 with arm-tcc (which bootstrappable.org reported some success for, couldn't verify)
moteen has quit [Remote host closed the connection]
<aggi>
meaning, the idea too is, to close a huge gap of a reproducible bootstrapping of the GNU-toolchain
moteen has joined #linux-sunxi
NekoMay has quit [Ping timeout: 480 seconds]
NekoMay has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen_ has quit [Remote host closed the connection]
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
hlauer has joined #linux-sunxi
<hramrach>
is GNU toolchain not reporoduciblE?
<aggi>
hramrach: backtracked GNU toolchain to version gcc-2.7, which GNU guix maintained some bootstrapping with... good luck
<hramrach>
???
<aggi>
i blocked at gcc-4.7/binutils-2.22 for now, hoping for this passes with arm-tcc (or x86_64-tcc)
<aggi>
2022-07-27 18:24:06 <hramrach> is GNU toolchain not reporoduciblE? it is NOT.
<hramrach>
in what way?
<aggi>
depends on the definition of reproducible
<hramrach>
yes, yours seems to be somewhat curious
<aggi>
in any case, i cannot reverse-engineer a binary tarball of 100MiB gibberish to verify against "trust attack"
<aggi>
besides other benefits arm-tcc potentially has
<hramrach>
why do you need to reverse-engineer a binary tarball? GNU tools are distributed as sources
<aggi>
sure, which require a binary tarball full of gibberish, to compile those dozens of millions of LoC sources
<hramrach>
which binary tarball?
<aggi>
any you wish, gentoo offers some stage3, or any other
<aggi>
backtracking this, you'll arrive at GNU GUIX and gcc-2.7... just as said, good luck with that
<hramrach>
so your problem is that you need a working compiler to build a compiler?
<aggi>
it's not "your problem", i consider GNU toolchain wrecked since it switched to c++ internally
<aggi>
and aarch64 is only supported by this particular GNU toolchains, as a side note
<hramrach>
and that's a problem why exactly
<aggi>
hramrach: ever tried to maintain some toolchains/cross-compilers?
<aggi>
another side-note, tinycc compilers/cross-compilers finish compilation in a few secconds
<hramrach>
not seriously, just build a cross-toolchain for some obscure arch a few times
<hramrach>
and yes, it was gcc based
<aggi>
i want to remove both: GNU/FSF GCC, and Mapple LLVM/clang
<aggi>
that's not "free software" as in free as in free
<aggi>
and as far as "open source" was concerned, several dozen millions of LoC for the toolchain alone, is too much
<aggi>
besides, other _practical_ benefits
<aggi>
tinycc is fast!
<hramrach>
what's nonfree about them?
<aggi>
it's a marketing scam
<hramrach>
gcc has been even somewhat successfully forked
bauen1 has quit [Ping timeout: 480 seconds]
<hramrach>
you can cream "wretched!" "marketing scam!" all day long but without any actual argument it's pointless
<hramrach>
like if you want to fully audit your sources, and unlike gcc for tcc it is somewhat feasible I can understand that
<hramrach>
that does not mean that gcc is broken or non-free, though
<aggi>
i am not willing dispute over the interpretation of the facts already mentioned, concerning both, GNU/FSF gcc toolchain or Mapple/LLVM one
<hramrach>
which facts? that they use c++ and need a compiler to build?
<aggi>
and there is more problems, to discuss
<hramrach>
none of that is inherently a problme, and the altter is surely the case for tcc as well
<aggi>
btw. tcc is C99 compliant, some C11, some GNU extensions, it's pretty complete
<aggi>
nonetheless, good luck feeding GNU/Linux into tcc
<hramrach>
it was a problem with llvm as wwell, initially
apritzel has joined #linux-sunxi
<aggi>
hramrach: i focus on the _userspace_ parts with arm-tcc first
<hramrach>
especially the kernel realies on a lot of compiler-specific behavior simply because nobody ever built it with something that behaves differently
<hramrach>
so what?
<aggi>
it is alot of work
<aggi>
to cleanup, the creation of a c-only toolchain system profile, this was almost one year of work
<aggi>
only this
<hramrach>
yes, and I still have absolutely no idea why you would do it
<aggi>
to retain a package set passing the minimum acceptance criteria
<aggi>
good question, i consider a c-only toolchain system profile worth a fortune, regardless
<hramrach>
may be the key is in the 'minimum acceptance criteria' that's known only to you
<aggi>
i do not lock out any upgrade path with compilers/cross-compilers anywhere else neither
<aggi>
it is GNU/FSF and Mapple/LLVM who locked out myself
<aggi>
question will be, if @arm.com was interested in supporting arm-tcc toolchain integration
<aggi>
for long-term stability, of the entire aarch32 (and aarch64) plattform
<aggi>
which seems, another benefit of arm-tcc in comparison to GNU toolchain: stability
<aggi>
linux kernel, just recently, locked out any alternative, with C11 feature creep, and minimum compiler version requirements
<hramrach>
basically by now C is obsolete, and the only reason we cannot move on is that no replacement gained enough momentum - mostly due to project management/PR issues
<hramrach>
and of course the kernel will use new features in C that are useful for kernel development
<aggi>
useful how? to vendor-lock?
<aggi>
because THIS is what they did recently
<hramrach>
useful for writing the kernel code
<aggi>
and how had C90/99 not proven useful for this?
<aggi>
btw. linux kernel-2.4/2.6 was known to fully support tinycc... not anymore
<hramrach>
it might spite you that they used a feature that your compiler does not have but they don't prevent you from pimplementiong it as well
<aggi>
blowing up a standard compliant, sane, fast and efficient compiler with feature creep isn't any idea i follow
<aggi>
same with linux kernel, which did just that, in recent weeks
<aggi>
locking into C++ compilers
<hramrach>
it's no longer standards-complient if it does not implement C11
<aggi>
C11 is only fully supported by c++-compilers (compilers/toolchains written in c++ with c++ dependencies)
<aggi>
of cause, if you mention standards, than mention those type of "standards" which apply, which is the entire C++ realm then
<hramrach>
I don't understand the your problem with the compiler using c++ or D or brainfuck internally for their code
<jakllsch>
you can't bootstrap them trivially
<hramrach>
certainly the gcc bootstrap is non-trivial internally, nonetheless it tends to work pretty trivially for the user
<aggi>
GNU/FSF GCC didn't retain a bootsrapping procedure similar to what they did with gcc-2.7 and GNU GUIX, that is a gap of 20years now
<aggi>
this was the GCC->EGCC transition, another recent one was any later than gcc-4.7 switched to c++ internally
<aggi>
and the most recent "minor" issue was C11 feature creep
<aggi>
with linux kernel vendor-locking against it
<hramrach>
they are certainly not vendor-locking, if they did they would not support llvm
<hramrach>
it's just your compiler does not have the features they decided they want for whriting their code
<jakllsch>
there's a reason llvm pretends to look like GCC to some degree..
<aggi>
which instead should be #if C90 #message "OK" #endif
<aggi>
and this is some kernel-related "minor" issues only
<jakllsch>
kernels are difficult to write in pure C
<hramrach>
they use non-standard compiler extensions because without some it's basically impossible to write kernel code so they cannot support arbitrary compiler
<aggi>
linux was fully supported with tinycc
<hramrach>
so if somebody made it possible to build mainline kernel with tcc and mainteined the support that ifdef might get a third branch but C90 does not cut it
<hramrach>
was but is no more
<aggi>
too, userspace parts were, and i already did sanitize those userspace parts, verified against gcc-4.7/c-only
<aggi>
with arm-tcc, 320/700 builds already passed too
<aggi>
which is another bare minimum of "free software", to retain those userspace parts passing minimum acceptance criteria with a c-only toolchain system profile
<aggi>
and this too was, effectively, wrecked
<hramrach>
what's the point of c-only toolchain?
<aggi>
"free software"
<hramrach>
and c++ is non-free how exactly?
<aggi>
the compilers/toolchain are vendor-locked
<aggi>
bloated, slow, inefficient, inpossible to review, a burden to maintain
<aggi>
although, i did NOT lock-out c++ or any "upgrade" path to "improve" "free software" with, i can and still do compile/cross-compile wherever i wish to
<aggi>
it is GNU/FSF and Mapple/LLVM who had LOCKED OUT ME
<hramrach>
bloated, slow, inefficient, inpossible to review, a burden to maintain - that I would understand. Nonetheless that does not equal non-free nor vendor-locked. The spec is free, alternative implementations do exist, and you can write c++ that compiled with GNU, msvc, and icc if you really want
<hramrach>
and no, I don't call vendor lock-in when some compilers implement new features, and people start using them because they think it makes their code easier to write or read
bauen1 has joined #linux-sunxi
<aggi>
ok, assume if, tinycc got a C99(partial V11 and GNU) compiler and linker... see for yourself how far you'll get with what's advertised as "free software"
<hramrach>
A lot of software uses GNU extensions so it will obviously not work without those.
<hramrach>
you cannot have a useful compiler without extensions because the C standatd sucks so that's where we are
JohnDoe_71Rus has quit []
moteen has quit [Remote host closed the connection]
<aggi>
apritzel: if there is any interest @arm.com me pushing support for arm-tcc, please let me know