IRC channel logs
2016-01-01.log
back to list of logs
<rekado>built gcc for armel over night, but it still segfaults when trying to link the axoloti firmware. <rekado>I wonder if our armhf cross-compiler does something weird. I certainly don't understand it. <rekado>could be that it's because of prebuilt objects that were built with a different compiler. <rekado>"error: required section '.rel.plt' not found in the linker script" <rekado>"final link failed: Invalid operation" <rekado>now I'm trying again to build another cross compiler, this time with triplet "arm-none-eabi". <rekado>(I don't really know what I'm doing here. I cannot just download this prebuilt compiler toolchain like anyone else seems to suggest.) <rekado>bleh, this isn't working. Does anyone here happen to know how to cross-compile for a cortex-m4, for a non-linux target? <cehteh>rekado: ah yes building toolchains is a big pita .. i use some prebuild ones too <cehteh>*if* you manage to make that working for guix that would be awesome <davexunit>(I'm currently trying to figure out a bug in guile master) <davexunit>strangely, the following code evaluates to #t in guile master: <davexunit>(= (sizeof (list uint32 '* int)) (sizeof (list uint32 '* int int))) <civodul>it's expected: the last two ints can be packed together <civodul>in the first case, there's 4 bytes of padding at the end <davexunit>I get distinctly different results in 2.0.11 <davexunit>if I'm trying to calculate the byte offset of a value in a struct <davexunit>I'm trying to parse values out of a struct without using parse-c-struct <rekado>cehteh: the stm32f4 is a chip with m4 core --- if the axoloti firmware is to be trusted. <rekado>I really just need to pop in the right compiler toolchain and the script should build me the firmware. <rekado>but it seems that our armhf compiler isn't what I need. <rekado>I don't understand how it was made and I don't see what the difference is between this and the toolchain everybody suggests to be used. <civodul>davexunit: i'm on stable-2.0, which may have a fix or two compared to 2.0.11 <civodul>davexunit: see Guile commit 67d8ccc0 <civodul>efraim: what's the status of your various python-* patches? <rekado>is there a difference between arm-linux-eabi and arm-linux-gnueabi? AFAIU the vendor field ("linux") doesn't really matter; but does the difference between "eabi" and "gnueabi" matter? <rekado>I need a bare-metal compiler toolchain. <rekado>seems that it does make a difference. Will try to build arm-none-eabi again... <rekado>eabi is for bare-metal; gnueabi is for GNU on ARM. <davexunit>civodul: thanks, I guess I'm left wondering how to correctly calculate byte offsets into C structs. <davexunit>I don't want to have to parse the whole struct upon every operation. it's enough for me to just know where in the bytevector to pluck values from. <civodul>rekado: there's no vendor field here; "linux-gnu*" is the OS field <civodul>but yeah, "arm-none-eabi" looks like the bare-metal variant <civodul>davexunit: define-c-struct in (guix build syscalls) might be interesting in that regard <davexunit>I'm going to get by with parse-c-struct for now <rekado>so, I got arm-none-eabi now (without glibc), and built "newlib" with "--target=arm-none-eabi". <rekado>still fails to link, unfortunately, but I think I'm getting closer. <rekado>firmware was successfully compiled <rekado>hmm, arm-none-eabi-g++ isn't built; I see that "--enable-languages=c" is passed when no libc is provided. <civodul>rekado: i don't recall why --enable-languages=c was used, maybe just to speed things up <rekado>I'm commenting the line for now; ultimately, I think our cross-gcc procedure needs to be a little more flexible. <rekado>I'm building the firmware for the axoloti board. <rekado>actually, the firmware itself has been built already, but audio patches require g++, so I'm stuck there. <rekado>I already got sound out of the board (a short click indicating that the firmware was applied and the audio output was initialised), but to actually get it to play synth patches I need to compile them with cross-g++. <rekado>civodul: there's a comment above the "--enable-languages=c", but I'm not sure it applies in my case. Will see. <davexunit>man, I don't know if I can handle guix-help, too many people insisting that we are doing everything wrong. <davexunit>first we had people suggesting we use Docker and use pre-build jars, and now there are suggestions that we should use sysvinit <rekado>davexunit: yeah, ... I don't know how to deal with this. Maybe we should write more blog posts so that people actually read a little about how Guix works (nobody seems to read the manual). <rekado>civodul: the comment is correct. When c++ is not disabled we eventually get this error when building the cross compiler: "checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES." <rekado>but how can I get g++ for arm then...? <civodul>is it enough to disable libstdc++ builds <rekado>trying that now. It's a pity this all takes so very long. <rekado>hmm, that didn't work. I passed "--disable-hosted-libstdcxx" but that was not enough to disable building libstdc++. <civodul>rekado: "--disable-libstdc++-v3"; see commencement.scm <davexunit>civodul: well, at least they'll get one more language out of the way <rekado>civodul: thanks for the hint with "--disable-libstdc++-v3". It works now! <rekado>I still don't have sound from the board, but at least the compiler seems to work. <civodul>rekado: great you're making progress :-) <rekado>I hope I'll be able to submit some patches for this soon. <rekado>I have much more trust in what I'm doing since it's all declared in Guix package expressions. <rekado>much nicer than running some half-baked "installer" script written in bash that downloads prebuilt binaries from somewhere and glues them together in some manner. <rekado>will continue tomorrow. Gotta go now. <sprang>I'm poking around trying to package erlang. the build instructions have this step before ./configure: export ERL_TOP=`pwd` <sprang>any advice about how to insert that into the build phases? <civodul>sprang: the phase body would be: (setenv "ERL_TOP" (getcwd)) <civodul>as to how to add a phase, check for 'modify-phases' in gnu/packages/*.scm <civodul>hopefully there are simple examples to copy from :-) <sprang>ah, thanks, have the modify-phases part, but didn't know how to setenv