<phant0mas>good morning jmd, did you find any solution? <jmd>Well I found a work-around. <jmd>I have to pass -B$(guix build glibc-cross-xxxx)/lib -I$(guix build glibc-cross-xxxx)/include to the compiler. <jmd>But I don't know why that should be necessary. I must be configuring something wrong in the cross-build <jmd>But I found out why my shared libraries won't run on the target. <phant0mas>did you declare CROSS_CPATH and CROSS_LIBRARY_PATH correctly? <jmd>No. Where would I set those? <phant0mas>there is an example in cross-gcc in crossbase.scm <jmd>Well if that is already there, shouldn't it have been set automatically? <jmd>I wish I understood these internals of guix better. <phant0mas>when cross-gcc gets build and has a libc as input, it normally sets the PATHS accordingly <jmd>That is what I thought. So why didn't it in my case? <phant0mas>can I see your changes? maybe then I could uderstand better what's going on <jmd>The other problem I experienced was that I should have been using hardfloat. <jmd>Using softfloat means that statically linked binaries work ok, but no dynamically linked ones run. <jmd>As you can see, I tried passing CFLAGS=-mfloat-abi= but that didn't seem to do the trick. <phant0mas>there isn't anything strange on the diff, and supposedly upstream toolchain supports arm, it should have worked <jmd>It builds ok. But the resulting toolchain doesn't work without the flags I described. <jmd>And the hard-float option is ignored. <phant0mas>wait a sec, why do you have CFLAGS over there? passing the flag --mfloat-abi=hard whouldn't it be enough? <jmd>The purpose of that entire function is not clear to me. <phant0mas>gcc-configure-flags-for-triplet is there to add extra flags depending on the target machine <phant0mas>remove CFLAGS and check if it ignores the flag then <jmd>I think I did try that too. <jmd>I did a lot of things last night before I went to bed. I was rather tired at the end of it. <jmd>Does configure-flags-for-triplet specify the flags which should be passed when building the cross-compiler, or the flags which the cross-compiler should pass when it builds things like glib or both? <jmd>I also found that my change to glibc-dynamic-linker didn't seem to have any effect. <phant0mas>specify the flags which should be passed when building the cross-compiler <jmd>And they are the flags passed to ./configure right? <jmd>then surely CFLAGS= is correct. --mfloat-abi is not something configure would recognise. <phant0mas> --mfloat-abi is needed from the cross-compiler to build libc? <jmd>phant0mas: Well for the machine I wanted to target, yes <phant0mas>well then, gcc-configure-flags-for-triplet is not the place then <jmd>I thought that might be the case. <jmd>phant0mas: It will also be needed to build (almost) everything which that compiler builds. In other words it should be the default. <civodul>re hard-fload, you may need to pass a configure flag to glibc, no? <jmd>Be even cooler if it worked :( <jmd>civodul: Yes, phant0mas and I were just discussing that. I'm not sure how to do it. <viric>playing with arm? cross-building? <phant0mas>btw civodul I think I found a way to merging cross-libc with cross-libc/hurd with the use of that glibc macro in base.scm <civodul>jmd: actually, looking at $GCC/gcc/config/arm/linux-eabi.h, you'll see it defaults to ARM_FLOAT_ABI_SOFT <civodul>so this file probably needs patching <viric>civodul: in gcc for the pi, I have: arch="armv6";fpu="vfp";float="hard" <viric>to gcc: --with-fpu=vfp --with-float=hard <jmd>viric: The question is, where, in the bootstrap.scm, gcc.scm, crossbase.scm ... must I put that? <jmd>civodul: I didn't realise this was hard coded. <jmd>So what purpose does the function glib-dynamic-linker serve? <civodul>it returns the name of the dynamic linker; what did you mean? <jmd>civodul: right. But I see that the name of the dynamic linker is also hard coded in that file you refererenced. <jmd>What does guix do with the return value of that function? <civodul>jmd: it patches the libc source code, precisely <jmd>Oh. Then it didn't seem to work for me. <jmd>Where is the code which does that patching? <civodul>it could be that it doesn't patch the right file for ARM <civodul>or that the regexp doesn't work for the ARM config headers <jmd>Right. its patching "^linux(64|-elf)?\\\\.h$ <jmd>We need gcc/config/arm/linux-eabi.h like you said <jmd>Will you do it or shall I have a go? <civodul>sneek: later tell jmd i'm happy if you give it a go! <sneek>jmd, civodul says: i'm happy if you give it a go! <jmd>There no longer seems to be a core-updates branch. <jmd>What does this stuff mean: #:optional (system (or (and=> (%current-target-system) <jmd> gnu-triplet->nix-system) <jmd> (%current-system)))) <davexunit>civodul: got guile-sdl to build. turning off the parallel build did the trick. however, the test suite fails, so I've got to resolve that now. :) <rgrau>afaik I haven't touched any options or m4 or anything <bavier>you likely don't have ACLOCAL_PATH set correctly <rgrau>oh... oks. I should have RTFH <bavier>rgrau: no problem; let us know if you have any other questions <civodul>davexunit: good, making progress :-) <civodul>jmd: this stuff means "convert the (target) system type to a GNU triplet" <civodul>so "i686-linux" => "i686-pc-linux-gnu", for instance <jmd>civodul: There is a problem here. <jmd>armel-linux-gnueabi has a different loader to armel-linux-gnueabihf <jmd>but all that glibc-dynamic-library gets is "armel-linux" <civodul>for now, you could just assume only "hf" is targeted, and leave a FIXME there so we can address it later ***nkar_ is now known as nkar
<jmd>Is it normal to see error messages like: objcopy:/gnu/store/801cv0ldbfq2j1spyyra6nw1mszb0prj-glibc-2.20/lib/stCteYMF: cannot create debug link section `/gnu/store/dyrh8i500lnx158hjz6kvgsngnqnnnqc-glibc-2.20-debug/lib/debug//gnu/store/801cv0ldbfq2j1spyyra6nw1mszb0prj-glibc-2.20/lib/libresolv.so.debug': Invalid operation <jmd>when building glibc ?