IRC channel logs
2020-08-29.log
back to list of logs
<dannym_>janneke: What is build-aux/check.sh.in' LIBS for ? <dannym_>janneke: It seems that it's never exported, so it's local to that file? What does that help? <dannym_>janneke: Instead, in build-aux/test-c.sh, there's a case analysis that sets LIBS. But that always uses -l mescc right now. If we want -l gcc for gcc and -l mescc for mescc, that script has to know what it's compiled by--which it doesn't right now <dannym_>janneke: Also, for gcc, we have to be explicit and link: -lc -lgcc -lc (not a typo) <dannym_>janneke: If we didn't disable gcc's automatic resolving none of this weirdness would be visible in our build scripts, and check.sh.in would not have to distinguish between the two compilers <dannym_>I guess we can't enable gcc's automatic resolving of that because we have different libc's with different names <dannym_>But then build-aux/test-c.sh needs to know whether $compiler = gcc <dannym_>janneke: The reason for the -lc -lgcc -lc is because gcc uses an external raise(), which is in libc. The linker resolves symbol references only in the order they are seen, not globally. <dannym_>janneke: If you want, could you give me (daym) push access to git@gitlab.com:janneke/tinycc.git ? <dannym_>janneke: If not, please modify build-32.sh so that it says at the very end: libc.a -lgcc libc.a <dannym_>janneke: (i.e. add one libc.a at the end) <dannym_>janneke: Otherwise libgcc.a cannot resolve raise(), which is in libc. <janneke>dannym_: thanks, pushed -lgcc libc.a -lgcc to tinycc at gitlab <janneke>dannym_: i don't really know about LIBS in check.sh.in; we just have to revisit that <janneke>dannym_: it's either a leftover or something that's not finished <dannym_>janneke: Pushed workaround to mes wip <janneke>test-c.sh took many iterations -- in a way it's nice if the user can override CFLAGS in configure <dannym_>janneke: 0 test failures for gcc-lib, 0 test failures for mescc-lib <janneke>...but giving the user (too much) control makes things fragile -- i dunno, it's tricky <janneke>dannym_: i've been afk most of the day, and my time at the keyboard i've been rebooting all the time working on the childhurd secrets...first draft is finally done <dannym_>janneke: I'm improving on it even more ;) <janneke>yeah, it's terrible, i can't start a vm inside a vm, so to properly test it i must reboot <janneke>dannym_: nice, first get it working...then go from there -- i like it <dannym_>Also gcc-compiled tcc works (small tests) kinda <dannym_>janneke: Pushed better fix to mes wip as commit 17211c9c9c23fd2b6d0a5caffbc53e203571449c (Support "mescc --print-libgcc-file-name"), but it doesn't work for some reason. <dannym_>janneke: If you have a minute could you check what's up with it? Kinda embarassing not to get option parsing to work, but ehhh <dannym_>Also, small note: ./pre-inst-env of mes doesn't work outside a guix environment. I get error:include-from-path: not found: :(nyacc/lex.scm). That's different to guix's ./pre-inst-env which (as far as I know) provides all dependencies, too <janneke>it could be that configure doesn't take good care of GUILE_LOAD_PATH, which should include nyacc <dannym_>GUILE_LOAD_COMPILED_PATH="$abs_top_builddir/scripts:$abs_top_builddir/module${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" <dannym_>GUILE_LOAD_PATH="$abs_top_srcdir/module:$abs_top_srcdir/mes:$abs_top_srcdir/guix${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" <janneke>dannym_: line 188: (print-libgcc-file-name (display "-lmescc\n")) probably wants a "?" appended and <janneke>also wants something like (print-libgcc-file-name? (option-ref options 'print-libgcc-file-name #f)) <janneke>dannym_: hmm...that looks OK ... so what's going on; does running with -v or MES_DEBUG=2 help? (i'll have a look at this as well) *vagrantc smiles seeing work on mes