IRC channel logs

<mark_weaver>The most recent ffmpeg tarball release fails to build in x86_64 and i686?

<mark_weaver>one of the arguments in favor of ffmpeg over libav was that ffmpeg was supposed to be less buggy. It makes me curious whether libav compiles.

<a_e>mark_weaver: ffmpeg compiled locally on my machine. Otherwise, I would not have pushed it!

<a_e>Heureka, I have a working icecat!

<civodul>wo0t!

<mark_weaver>ffmpeg failed on my machine also: tools/crypto_bench.c:261:9: error: implicit declaration of function 'AV_READ_TIME' [-Werror=implicit-function-declaration]

<mark_weaver>a_e: that's great news about icecat!

<civodul>FYI hydra.gnu.org has 2 GiBs of RAM

<a_e>mark_weaver: This is yet another error!

<a_e>Yes, good news about icecat. I will tweak it some more (for instance, it looks like a configure parameter I needed for version 17 can be dropped in 24).

<a_e>And I will experiment with different toolkits. So far, it is gtk+-2. But it should be possible to activate gtk+-3. And even qt.

<civodul>i think the default should be GTK+

<mark_weaver>qt also failed to build on my machine. while compiling a C++ file, the assembler complained of invalid syntax :-(

<mark_weaver>civodul++

<a_e>civodul: Probably so. But rather 3 than 2 if possible, no?

<mark_weaver>yes, I think that makes sense.

<civodul>a_e: yes, the newer the better! :-)

<a_e>And I would try an icecat-qt. It it works, we could have both.

<civodul>yes

<a_e>So on this happy note, let me leave, and talk to you all in a week again!

<mark_weaver>a_e: taking some time off?

<civodul>a_e: enjoy your break! :-)

<mark_weaver>okay, have fun! talk to you in a week or so :)

<a_e>Thanks!

<civodul>mark_weaver: the ffmpeg build failure was on MIPS?

<mark_weaver>yes

<civodul>ok

*civodul attempts to build it on x86_64

<mark_weaver>I built from the guix recipe that a_e made.

<mark_weaver>I have to go offline for a while. ttyl!

<civodul>oh, test failure here

<civodul>Test lavf-xwd failed. Look at tests/data/fate/lavf-xwd.err for details.

<civodul>make: *** [fate-lavf-xwd] Error 1

*gzg` isn't sure why this ("mirror://sourceforge/projects/slim.berlios/files/slim-") isn't pulling the source. It keeps 404'n.

<gzg`>Ah, got it.

<civodul>oh slim, nice :-)

<civodul>gzg`: how's it going?

<mark_weaver>civodul: is gcc-4.7.2 unable to build gcc-4.8.2 ?

<mark_weaver>I'm not sure I understand your message "Switching to GCC 4.8

<mark_weaver>oh, maybe it's just that gcc-4.7.2 is unable to cross-build gcc-4.8.2, is that it?

<gzg`>civodul: Pretty hectic actually... not anything I want to go into here, but I'm trying to force myself to get a relevant trivial package, or two up before I'm MIA all starting Wed to Monday. :^P

<civodul>mark_weaver: in master we have gcc-4.8.2, and it builds fine

<civodul>mark_weaver: the problem i mentioned on the list is bootstrapping: our current bootstrap gcc lacks C++ headers needed to build 4.8

<gzg`>civodul: I'm guessing I should build with linux-pam and not consolekit?

<civodul>gzg`: for now, yes

<civodul>not sure what to do with consolekit in the longer term

<mark_weaver>civodul: any chance you could look at this? http://www.netris.org/~mhw/guix-texlive-config.log

<mark_weaver>it's the config.log left from trying to build texlive.

<mark_weaver>(on MIPS N32)

<mark_weaver>search in there for "undefined reference"

<mark_weaver>basically, the configure script concludes that 'gd', 'cairo', and 'pixman' are unusable, because of these link errors.

*gzg` really, really needs to set some time away next week to learn the build-systems and how to manipulate them a lot better. It's bad when he dosen't know how to add a flag, to cmake...

<civodul>mark_weaver: looks like libgd was built without -lfontconfig -ljpeg

<sdfsgsgsfg>civodul: I still don't understand how to use ld-wrapper. I couldn't make GCC work without environment variables.

<civodul>sdfsgsgsfg: install ld-wrapper in your profile, and make sure ~/.guix-profile/bin/ld points to it, and not to the real ld

<civodul>ah but i also just noticed an issue with 4.8

<civodul>which doesn't add -rpath as it should

<sdfsgsgsfg>Uh oh.

<civodul>though i can use it flawlessly here, dunno wh

<civodul>*why

<sdfsgsgsfg>Define "here."

<civodul>in my profile, installed from 'master'

<mark_weaver>civodul: indeed, I'm looking at the command that links libgd.so.2.0.0, and it lacks -lfontconfig and -ljpeg, as well as the associated --rpaths

<mark_weaver>I wonder why this is working for anyone else

<civodul>yes, weird

<sdfsgsgsfg>civodul: Where did you notice the problem, then?

<mark_weaver>My autoconf/automake foo is far too weak to know how this kind of problem should be fixed.

<civodul>mark_weaver: apparently it works here: http://hydra.gnu.org/build/24054/log/raw

<civodul>perhaps you could compare the logs, esp. the configure diagnostics

<civodul>sdfsgsgsfg: while fiddling with bootstrap stuff in core-updates

<mark_weaver>civodul: well, yes, and gd builds properly on my system too. the gd test suite works because -ljpeg and -lfontconfig are always given alongside -lgd when linking the test programs.

<mark_weaver>the problem is that texlive's configure script is not passing -ljpeg and -lfontconfig when linking test programs with -lgd

<mark_weaver>at least not on my system.

<mark_weaver>I'm looking at the hydra gd build log, and just like on my system, -ljpeg and -lfontconfig are not given on the line that links libgd.so.2.0.0.

<mark_weaver>it's hard to compare the log files, because all the nix hashes are different

<gzg`>Okay, sorry to bother again ... but anyone care to have a quick glane at '(arguments `((#+make-flags "-DUSE_PAM=yes")))' and tell we where I'm (probably way) off, before I take a nap?

<gzg`>glance*

<civodul>gzg`: should be (arguments '(#:make-flags '("-DUSE_PAM=yes")))

<gzg`>civodul: Oh!

<civodul>you can grep the surrounding files when in doubt ;-)

<gzg`>civodul: Yeah, I really need to get into the habit of that... :^I

<civodul>mark_weaver: the line that starts with "gcc -shared gd.lo gdfx.lo gd_security.lo" does have -lfontconfig -ljpeg

<gzg`>Hm, it appears I misread the initial error (though I'll need such a flag later)? Would it make sense for fontconfig, to be built with pam support?

<mark_weaver>civodul: ah sorry, I missed that. indeed it does.

<mark_weaver>and mine doesn't.

<mark_weaver>hmm

<mark_weaver>ah, and in my build log, I see warnings like this: *** Warning: linker path does not have real file for library -ljpeg.

<mark_weaver>and ditto for -lfontconfig and -lz and -lm

<civodul>hmm, interesting

<gzg`>Here's the package thus-far and error, for those curious. http://paste.lisp.org/+2ZUA

<mark_weaver>I wonder if this is somehow related to the fact that I have a linker script libjpeg.la

<mark_weaver>apart from differing hashes, the calls to 'libtool' that link libgd.so.2.0.0 are identical.

<mark_weaver>(between hydra and my machine)

<civodul>it could be that libjpeg only has a .a and no .so, for some reason

<mark_weaver>so, I have libjpeg.so

<civodul>gzg`: looks good!

<mark_weaver>the LIBRARY_PATHs are also identical except for the hashes (as seen near the top of the build log)

<civodul>we'd need to investigate where that libtool warning comes from

<mark_weaver>I guess a more careful comparison would require converting these hashes to a canonical value, and then comparing the logs.

<civodul>yeah

<mark_weaver>I don't suppose there already exists such a thing (that folds the hashes)

<civodul>ISTR that Hydra has a log comparison tool that does something like that

<gzg`>civodul: Any guess on the "checking for one of the modules 'fontconfig' FontConfig Found PAM disabled ConsoleKit disabled'" error?

<civodul>gzg`: could you paste the complete log?

<gzg`>Yup, sec.

<gzg`>civodul: http://paste.lisp.org/+2ZUB

<civodul>aah, that's CMake

<sdfsgsgsfg>civodul: I installed ld-wrapper and gccgo, but it can't find crt1.o and crti.o. Am I supposed to set any variables even with ld-wrapper?

<civodul>sdfsgsgsfg: did you check that ~/.guix-profile/bin/ld points to the ld-wrapper, and not Binutils?

<civodul>(that's the dirty part of the story)

<sdfsgsgsfg>Yes.

<civodul>ok

<civodul>hmm

<civodul>do you have what 'guix package --search-paths' say?

<civodul>*says

<civodul>gzg`: can you get more details from CMake?

<civodul>if you run "guix build --keep-failed slim" you'll be able to inspect the build tree

<sdfsgsgsfg>civodul: It suggests to set CPATH and LIBRARY_PATH. Should I do so?

<sdfsgsgsfg>So, does ld-wrapper only allow to avoid LD_LIBRARY_PATH?

<mark_weaver>civodul: I stripped the hashes from the build logs of gd on hydra vs my machine, and here are the relevant differences:

<mark_weaver>hydra: checking how to recognise dependent libraries... pass_all

<mark_weaver>mine: checking how to recognise dependent libraries... file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )

<mark_weaver>mine has: checking for file... no

<mark_weaver>(that line doesn't appear on hydra)

<mark_weaver>hydra: checking dynamic linker characteristics... ./configure: line 7473: /usr/bin/file: No such file or directory

<mark_weaver>GNU/Linux ld.so

<mark_weaver>mine: checking dynamic linker characteristics... GNU/Linux ld.so

<gzg`>civodul: What would you want, the CMakeList.txt?

<mark_weaver>the only other difference being that in my link line for libgd.so.2.0.0, mine is preceded by all those warnings and then does not include -ljpeg -lfontconfig -lz or -lm

<mark_weaver>(there are warnings for all four of those libraries)

<mark_weaver>I'm guessing that the "how to recognise dependent libraries" bit is a problem.

<mark_weaver>I'm searching through all my build logs now for occurrences of "checking how to recognise dependent libraries"

<mark_weaver>and in most cases, the result is "pass_all" on my machine.

<mark_weaver>so I'm guessing that gd was bootstrapped with an old version of libtool or autoconf or automake or something, and that the version is too old to do the right thing on MIPS N32.

<mark_weaver>yeah, that must be it.

<civodul>gzg`: a log, if there's one (i'm not familiar with CMake)

<mark_weaver>yes, in all of my build logs, that anomalous result for "checking how to recognise dependent libraries" occurs for only two packages: liboop and gd

<civodul>mark_weaver: yeah, either gd, or the dependent libs

<mark_weaver>(and at this point, I've tried to build just about everything in the distro)

<civodul>aah, so that would confirm your hypothesis of a too old libtool

<civodul>woow

<mark_weaver>what do you think is the best way to upgrade libtool in one of these packages? (I'm unfamiliar with the process)

<mark_weaver>(I was also burned by libtheora having an ancient version of config.guess; I minimally patched it to fix mips64el, but maybe that's not the best solution, dunno)

<mark_weaver>thoughts?

<civodul>fixing it is inconvenient: you have to copy the 'libtool' script from that of the latest Libtool package

<mark_weaver>is it just that one file?

<civodul>that could be done conditionally for mips64el

<civodul>hmm

<civodul>and ltmain.sh, i think

<mark_weaver>should I just upgrade libtool via a patch file?

<civodul>rather via an extra phase and extra input, i'd say

<civodul>because the patch would basically be twice as large as the script

<mark_weaver>well, the extra input would mean that libtool would have to be built on systems with --no-substitutes

<mark_weaver>and whatever is done, I'm inclined to do it for all systems, not just mips64el

<mark_weaver>it seems like minimizing platform-specific differences is a good thing, no?

<civodul>right, it doesn't hurt to do it everywhere

<civodul>yes

<mark_weaver>so, do you want libtool to be a native-input for liboop and gd on all systems?

<civodul>i think so

<civodul>WDYT?

<civodul>actually it's libtool-bin

<mark_weaver>the other thing is, a patch will break if liboop or gd is upgraded and contains a newer libtool, which would remind us to rip out this hack later.

<mark_weaver>(and that is, of course, the best solution: to get them to fix it upstream)

<civodul>yes, that's why i'd prefer a phase that just copies 'libtool' and 'ltmain.sh'

<civodul>gotta go, but you can mail the list with whatever you end up with

<mark_weaver>hmm, okay. thanks!

*civodul always leaves in the middle of technical discussions :-)

<mark_weaver>haha

<civodul>not on purpose, i promise ;-)

<civodul>good day/night!

<mark_weaver>sleep well!

<mark_weaver>okay, I just pushed fixed versions of 'gd' and 'liboop' to the 'loongson' branch. Now I'm trying to rebuild 'texlive'. it's gotten past the problem it had before, so I'm hopeful...

IRC channel logs

2013-11-02.log