IRC channel logs
2013-10-23.log
back to list of logs
<mark_weaver>I strongly suspect that on more mainstream platforms, the latest linux-libre works just fine. <mark_weaver>also, it should be mentioned that I'm not talking about the pristine linux-libre, but rather the heavily patched version for YeeLoong. <Infiltrator>I wasn't sure whether you mean technical problems or policy problems. (If it were the latter, I would be quite curious.) <a_e>Yes indeed. Lots of work, congratulations! <mark_weaver>I compiled a whole load of stuff on MIPS N32 so far. <a_e>Me, almost nothing; even with a fresh checkout, the code from nix compiles, but the guile compilation fails with <mark_weaver>there is some duplication in there, because I had to rebuild lots of stuff after fixing libffi. <a_e>Quite a lot indeed, including X, perl and python. <a_e>I am using guile-2.0.5 from debian wheezy. <mark_weaver>a_e: hmm, I have a vague recollection of seeing that, and perhaps it was fixed with a "make clean" ? <a_e>Yes, the loongson branch. <a_e>I would be surprised if "make clean" helped, as it happens on a pristine checkout. <a_e>Trying again, nevertheless, just in case. <mark_weaver>a_e: I'm using guile-2.0.9. You might try upgrading. I seem to recall that there are still some lingering prblems with 2.0.5. <Steap>a_e: do you also own a loongson machine ? <a_e>Steap: viric sent me one. <mark_weaver>a_e: I'm also using libgc-7.2d, which is highly recommended. a simple "./configure && make && make check && sudo make install" of the upstream libgc source worked well for me on wheezy. <a_e>Hm, how about simply updating to debian testing? Would that not be the easiest solution? <mark_weaver>I'd recommend "apt-get build-dep guile-2.0", and then install libgc-7.2d from upstream source, and then install guile-2.0.9 from upstream source. <mark_weaver>a_e: yeah, I suppose that might work also, but I never tried jessie on the Yeeloong. <a_e>Maybe I am naive. But I would have argued that if version n works, then so does version n+1 ;-) <mark_weaver>well, that tends to be the case with more popular hardware, but the Yeeloong doesn't really fall under that category. <mark_weaver>fwiw, the newer linux-libre 3.10.15 kernel (with loongson patches) I've been playing with has some problems on the YeeLoong, whereas linux-libre 2.6.39.1 works flawlessly. <Steap>mark_weaver: gonna be a hell of a 'git bisect' <mark_weaver>specifically: 3.10.15 locks up hard if I try to use the built-in wireless, and even if I avoid it, it sometimes locks up, whereas 2.6.39.1 is rock solid. <a_e>mark_weaver: "make clean" did not help. I will compile libgc and guile. <a_e>mark_weaver: In debian, I am using 3.2.0-4-loongson-2f. It does not lock up, but I do not have a wireless card either. <mark_weaver>a_e: okay, thanks! maybe I'll try something close to that. <a_e>These slow machines are very relaxing. You watch the lines "checking..." flow by on the screen... <a_e>How long does guile take to compile on the fuloong? <mark_weaver>if you like, you can copy the .go files from a faster box, as long as it has the same pointer size and endianness. <mark_weaver>but if you do that, make sure you copy from a pristine build of upstream guile-2.0.9. <a_e>It is probably safer to compile natively (and I have only one machine anyway). <mark_weaver>btw, the GUILEC jobs will get much faster later on. the early ones are slow because the compiler itself has not yet been compiled, so the compiler is being interpreted. <a_e>So far, it is SNARFing files ending on .x. What is this? <mark_weaver>a_e: after you've compiled the C code, then it has to compile the .scm files to .go files. the first couple of them take a *long* time, so long that you might think it's hung. Be patient. after the first few it gets gradually faster, as more and more components of the compiler are compiled. <mark_weaver>those compilations are shown as GUILEC in the make output. <mark_weaver>for the first few, what's actually happening is this: a very limited (unoptimized) Scheme interpreter written in C is used to interpret a better interpreter written in Scheme (also unoptimized), which is used to interpret the compiler. <mark_weaver>bootstrapping a language written mostly in itself is tricky :) <mark_weaver>but at least we don't punt and require that you have a binary executable of Guile to compile itself, like many other projects do. <mark_weaver>fortunately, if you track Guile using git, then you almost never have to go through that process. <a_e>I have heard about compilers compiling compilers, but interpreters interpreting interpreters... <a_e>GEN guile-procedures.texi <a_e>/home/privat/guile-2.0.9/libguile/.libs/lt-guile: symbol lookup error: /home/privat/guile-2.0.9/libguile/.libs/libguile-2.0.so.22: undefined symbol: GC_set_all_interior_pointers <mark_weaver>a_e: it sounds like you need to re-run configure. did you run configure before installing libgc? <a_e>Yes, I did. Still, the library links to /usr/lib/libgc.so.1 <a_e>Instead of /usr/local/lib/libgc.so <a_e>mark_weaver: Thanks, that was it! <mark_weaver>a_e: you'll probably need to re-run configure, since the autoconf tests probably linked with the old libgc and made measurements based on that. <a_e>Okay. Just to be on the safe side! <mark_weaver>you'll need to run 'ldconfig' after installing guile too, btw. <a_e>I will try to think of it tomorrow... <mark_weaver>hmm. Guix compiled 'cairo', and then 'poppler', and now its recompiling 'cairo' again. <a_e>This is normal; look at poppler in pdf.scm. <a_e>Poppler depends on cairo and vice versa. <a_e>So we first compile a cairo without poppler input as an input to poppler. <a_e>And then cairo with this poppler input. <a_e>After running "ldconfig", I am now entering the GUILEC phase. <mark_weaver>okay, I've built the final cairo, harfbuzz, and pango. currently building gtk+ <mark_weaver>and after that, it should build emacs, which was my goal for the moment :) <a_e>So you can write your patches on the machine ;-) <mark_weaver>oh, this is already my only local machine. outside of guix I have my home-built N32 system based on CLFS. <mark_weaver>my thinkpad, which I was previously using, developed a backlight problem shortly after I got my new YeeLoong. <Steap>a_e: do you think it's fine to update cmake in the master branch ? <a_e>Steap: Why not? You should give it a try and check if Qt still compiles/ <Steap>a_e: yeah, that's why I'm wondering whether it should go in core-updates <Steap>I think bumping to the latest version might solve Nikita's issue with Lapack <Steap>And I think there are probably no huge regression in cmake <a_e>No, it would need to go into core-updates if it triggered a rebuild of nearly everything. <a_e>If it is only about a few packages, master is fine. <Steap>For 4.8.5, the URL seems to be wrong; 'single' should not be in it, could you take a look at it ? <a_e>Right, thanks for spotting this! I just pushed a fix. <a_e>It might still not compile, because it needs pulseaudio, which also fails on hydra. <a_e>But it did compile on my local machine. <Steap>it takes a long time on my machine <Steap>But I've just seen that the .tar.gz is huge