***Server sets mode: +cnt
<fosslinux>mes.c:(.text+0x8da0): undefined reference to `__stack_chk_fail' <fosslinux>/usr/bin/gcc -static -nostdinc -nostdlib -fno-builtin -L . -nostdlib -L gcc-lib -o src/mes crt1.o gc.o hash.o lib.o math.o mes.o module.o posix.o reader.o string.o struct.o vector.o -lc <fosslinux>also my other question is, why does guix use guile for bootstrap rather than mes? <oriansj>fosslinux: because mes can't run guix yet and guile is much faster than mes <fosslinux>oriansj: what should I do for floats on m2-planet <janneke>fosslinux: re __stack_chk_fail: your gcc compiles with stack protection by default; try CFLAGS=-fno-stack-protector <janneke>fosslinux: floats are not supported until well into compiling tiny cc <oriansj>fosslinux: M2-Planet does not support floats because compilers do not require floats to work internally. In fact they don't even require signed integers (but interpreters apparently do). <oriansj>As only compilers and interpreters are the primary targets of M2-Planet. Only structs, unions, char{,*,**}, int{,*}, unsigned, long and arrays are supported. (arrays primarily to deal with strings) <janneke>vagrantc: i tried CC=tcc on debian-x86 and that `just worked' for me; have i tried to convince you to use the --host=i686-unkown-linux-gnu on a x86_64 configure? <janneke>i was using that on guix, after doing: guix environment --system=i686-linux tcc ... that sort of thing won't work on debian (unless possibly you install a tcc with a 32bit persona) <vagrantc>janneke: i haven't been using the --host= argument ... i guess maybe that could be to blame <janneke>the core of the problem here being that mes configure tries to get the host machine by doing $CC -dumpmachine; which tcc does not have <vagrantc>janneke: also, where do you --host= values come from? they don't match any sets i'm familiar with <vagrantc>i have access to a number of variables that seem almost right ... e.g. i386-linux-gnu, arm-linux-gnueabihf, etc. <vagrantc>building debian packages makes it pretty easy to get variables variables that seem *almost* right ror this purpose <janneke>vagrantc: it's what guix uses ... and so what gcc -dumpmachine or guile -c '(display %host-type)' say <vagrantc>i don't think it's what gcc -dumpmachine produces on debian <janneke>ah, but --host=i386-linux-gnu should also be OK <vagrantc>i'll try and get you a list or a way to figure out what's in the list form a Debian viewpoint <janneke>vagrantc: hmm, i just tested tcc on 64bit, and that just produces a core-dumping mes -- so tcc really only works on i386 --with-courage <vagrantc>ah, /usr/share/dpkg/tupletable seems pretty good <vagrantc>yeah, i haven't been working on 64-bit lately <vagrantc>i pretty much accept that that only builds the gcc variant for now <vagrantc>hmmm... the tupletable seems to miss some obvious ones... <vagrantc>janneke: /usr/share/dpkg/cputable also gives part of the story... <vagrantc>i guess i'll just try to get you reasonable values for i386/amd64/armhf/arm64 for now and we'll go from there <vagrantc>janneke: i might just enable --with-courage by default ... then maybe debian porters will suggest fixes :) <oriansj>well there might be a straight-forward way with get_machine <oriansj>I can add --dump-machine to get_machine and i just need to figure out how to get the userspace <janneke>oriansj: get_machine is great, but the "problem" here is a compiler on amd64/x86_64 (as get_machine correctly reports) be it i686-unknown-linux-gnu-gcc or `guix environment --system=i686-linux --ad-hoc tcc' that produces 32bit binaries <janneke>it's really on the compiler that can tell us that <janneke>hmm, so if the compiler (tcc) does not support -dumpmachine, maybe we should look at its output? <janneke>thanks for asking, and thanks for listening! <oriansj>janneke: well perhaps tcc is like M2-Planet in that one needs to specify a target output <janneke>oriansj: no, tcc -c config.c will produce a config.o of the flavour tcc was compiled for <janneke>now to read elf objects and display their architecture; perhaps add a simple `file' command to gash core utils <janneke>this is for development/distro builds only; during bootstrapping you know what you're doing anyway <vagrantc>janneke: so, $DEB_HOST_MULTIARCH gives me: arm64 aarch64-linux-gnu, armhf arm-linux-gnueabihf, i386 i386-linux-gnu and amd64 x86_64-linux-gnu ... those are the most likely targets i'd expect to b able to build based on current work-in-progress <vagrantc>janneke: from a debian perspective, anyways... <vagrantc>janneke: there are a few other permutations of $DEB_*ARCH <janneke>ah nice, do i undestand correctly that this means "tcc" could be tcc:<any-of-those-archs>? <vagrantc>yes, tcc is present on all those architectures in Debian <vagrantc>as well as armel arm-linux-gnueabi ... if you're into supporting armv4 stuff <janneke>this is going to get interesting when dannym returns to mes/arm ***ChanServ sets mode: +o rekado