ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
aggi has left #linux-sunxi [#linux-sunxi]
ftg has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
kilobyte_ has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
kilobyte_ has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
Danct12 has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
aggi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
indy has quit []
indy has joined #linux-sunxi
indy has quit []
moteen has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
indy has quit []
indy has joined #linux-sunxi
indy has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Danct12 has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
gnarface 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]
chewitt has joined #linux-sunxi
bauen1 has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.6]
megi has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
aggi_ is now known as aggi
juri_ has quit [Ping timeout: 480 seconds]
NekoMay has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
juri_ has joined #linux-sunxi
NekoMay has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
cnxsoft has quit []
ftg has joined #linux-sunxi
moteen 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
<aggi> "lowest worthwhile CPU implementation is Armv7-A ... VFPv3-D16 as they represent the miminum specification"
<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
<aggi> linux: <somewhere>/compiler.h #if GCC #elif LLVM #else message "we don't support free software" #endif
<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
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]