IRC channel logs


back to list of logs

<a_e>jmd`: With your patch, pspp now does not compile any more, raising the following error:
<a_e>xgettext: Language "glade" is not supported. xgettext relies on expat.
<a_e> This version was built without expat.
<a_e>make[2]: *** [po/pspp.pot] Error 1
<a_e>I tried adding expat as an input to pspp, but it does not change anything.
<a_e>Also, I tried adding expat as an input to gettext, but I do not think it can make a difference: There is no trace of "expat" in config.log.
<a_e>Do you have an idea?
<jmd`>a_e: Yes.
<a_e>Good. What is it?
<jmd`>The problem is, that pspp is bootstrapped before uploading to
<jmd`>That means, that the program xgettext (not gettext) is required to generate the pspp.pot file.
<jmd`>We ship pspp.pot as part of the distribution.
<a_e>xgettext is there as a part of gettext.
<a_e>So you mean, pspp.pot is not included in the tarball on
<a_e>Or that our way of applying patches mixes up the dates?
<jmd`>No. It is included.
<a_e>File modification dates, I mean, so that pspp.pot is recreated.
<jmd`>The problem is, because you have patched one of pspp's source files it has to be rebuilt.
<jmd`>The question is, why is the guix gettext not up to the job?
<a_e>gettext has the following configure flag:
<a_e>Would I need to explicitly use it? So far, the configure of gettext does not even seem to look for expat.
<jmd`>What version of gettext is it?
<civodul>Hello Guix!
<jmd`>Hmm. On my local machine I have 0.18.1
<a_e>Hello civodul!
<jmd`>I don't know what expat is supposed to be doing.
<civodul>howdy a_e :-)
<jmd`>Hi Ludo
<a_e>xgettext is called with --language=glade. According to the error message, this seems to require expat.
<jmd`>a_e: I think this is now a gettext problem; not a pspp problem - although we could probably work around it in pspp
<jmd`>I wonder if between 1.18.1 and 1.18.3 they decided to do their XML parsing with libexpat and have it as an optional dependency?
<a_e>I think, too, that it is a gettext problem.
*jmd` downloads the gettext source from
<a_e>Inside pspp-0.8.1/src/ui/gui, I just tried
<a_e>xgettext oneway.ui --language=glade
<a_e>with the gettext of debian.
<a_e>It works without error message.
<jmd`>And using guixes built xgettext ?
<a_e>If I try the one in guix, then I get the error message on expat.
<jmd`>That seems to confirm that it's a problem with the guix xgettext
<a_e>Okay, I will try to add --with-libexpat-prefix to gettext.
<jmd`>I thought you said it was already there?
<a_e>No, I just added expat as an input, but without giving a configure flag. It does not seem to search for expat itself.
<jmd`>Neither the gettext release notes nor the changelog mention that expat is needed for glade interpretation.
<jmd`>Ahh but in the file called DEPENDENCIES:
<jmd`>* expat 1.95 or newer
<jmd`> + Recommended.
<jmd`> Needed for 'xgettext', so that it can parse Glade XML files.
<jmd`> + Homepage:
<jmd`> + Download:
<jmd`> + If it is installed in a nonstandard directory, pass the option
<jmd`> --with-libexpat-prefix to 'configure'.
<a_e>Okay. Hopefully that is enough.
<jmd`>Does guix have it in a non-standard directory?
<a_e>When I said it is not searched for, I may have been wrong. There are several configure in subdirectories.
<a_e>All in guix is in a non-standard directory - /nix/store/...-expat... instead of /usr
<jmd`>That would be the reason then, I suppose.
<jmd`>a_e: Are you planning to build pspp's gui as well?
<a_e>Yes, that would be the next step. Are there any particular difficulties?
<jmd`>It depends on gtksourceview
<jmd`>Other than that, I can't think of any.
<a_e>We do not yet have that package, unless it is just a part of gtk+.
<jmd`>No. It is separate. At least in Gtk+2 it is.
<civodul>i think it's separate
<a_e>Does pspp compile with both gtk 2 and 3?
<a_e>Will be away for a while.
<jmd`>There is a branch which we have ported to Gtk+3 but it's not recommended for normal use.
<a_e>I still get the same error message with the expat-enhanced xgettext. Somehow, it has not been taken into account.
<a_e>Part of the solution: gettext is dynamically loaded via dlopen.
<jmd`>Maybe you have to set LD_LIBRARY_PATH then.
<a_e>Probably link explicitly with libexpat, so that the rpath is set correctly.
<a_e>civodul told me so in another case, but I have never done it so far.
<a_e>LD_LIBRARY_PATH does work, at least.
<a_e>Alternatively, we could patch to disable dynamic loading.
<civodul>what's the problem with libexpat?
*civodul missed the beginning of the discussion
<a_e>It should all be logged by the gnunet bot.
<a_e>The problem is with "xgettext --language=glade", which gives the error message:
<a_e>Language "glade" is not supported. xgettext relies on expat.
<a_e> This version was built without expat.
<a_e>I tried to add expat to gettext, without success.
<civodul>ah, ok
<a_e>I added the configure flag --with-libexpat-prefix=... to gettext, without success.
<civodul>a_e: do you have a build log around?
<a_e>Finally, the in gettext-tools shows that on linux, they use dlopen.
<civodul>did configure fail to find libexpat?
<a_e>Configure does not even look for expat because of the dlopen approch.
<civodul>i see
<civodul>so what could be done is to pass LDFLAGS=-Wl,-rpath=/.../expat/lib
<a_e>The configure process sets the following variables in gettext-tools/Makefile:
<civodul>or patch the LDFLAGS of just xgettext/gettext-tools
<a_e>LIBEXPAT = -ldl
<a_e>LTLIBEXPAT = -ldl
<civodul>ah good
<a_e>I patched this to read, instead of "-ldl", "-ldl -lexpat", but "ldd xgettext" still shows no trace of expat.
<civodul>but --with-libexpat-prefix= is ignored?
<a_e>I think so.
<civodul>hmm, ok
<a_e>Here is the part of speaking of expat:
<a_e>dnl Check for the expat XML parser.
<a_e>dnl On operating systems where binary distribution vendors are likely to
<a_e>dnl ship both gettext and expat, we use dynamic loading to avoid a hard
<a_e>dnl dependency from gettext to expat.
<a_e>case "$host_os" in
<a_e> linux*)
<a_e> [Define to 1 if libexpat shall be dynamically loaded via dlopen().])
<a_e> LIBEXPAT="-ldl"
<a_e> LTLIBEXPAT="-ldl"
<a_e> ;;
<a_e> *)
<a_e>One could modify; would this be taken up by guix? Would we need the autotools as additional input?
<civodul>yes, that's not really an option
<a_e>Is it normal that the "-lexpat" flag has no effect?
<civodul>patching the makefile like you suggested sounds better to me
<a_e>Well, looking at the build log, it seems that -lexpat has not been used after all. Strange.
<a_e>Maybe I should do some experimenting "by hand", as inside guix, one gettext compilation translates into compilations of coreutils, attr, acl, expat, and gettext twice.
<a_e>Could this be a reason? This double compilation?
<civodul>you need a variant of gettext just for pspp
<civodul>because gettext is a prerequisite of too many things
<a_e>But that our current gettext does not handle "--language=glade" is a bug, no?
<civodul>well yeah
<civodul>we can have the default gettext use expat in core-updates
<civodul>just not in master
<a_e>pspp needs xgettext only since we patched it; once a new release comes out, the patch and the need for xgettext will disappear.
<a_e>Maybe it would be easier to simply "touch" the file that is being recreated with xgettext.
<a_e>But anyway, it would be good to improve our gettext.
<jmd`> That should work. But the next package that needs gettext --language=glade might not have the same release process as pspp
<a_e>jmd`: Do you have an idea of when the next pspp release will happen?
<jmd`>I think Ben is trying to do them a lot more frequently now.
<jmd`>You could always use one of the snapshots. They are typically built every day.
<a_e>Ah, I patched only one of the Makefiles. I should add find-files into the substitute*.
<a_e>Is it recursive? I would need all finds in the directory gettext-tools or its subdirectory that are called Makefile.
<jmd`>I just wonder how guix is going to work with java/ant type build systems.
<a_e>Hm, more easily, in my case I should patch "configure" instead of the different Makefiles.
<a_e>jmd`: It will not be fun, I suppose...
<mark_weaver>civodul: a few minor points about the "installing guix from guix" section of the README:
<mark_weaver>when I install the suggested guix packages, it doesn't recommend that I set ACLOCAL, only ACLOCAL_PATH. and it doesn't recommend that I set PATH.
<civodul>mark_weaver: "it" == "guix package"?
<civodul>or "README"?
<mark_weaver>guix package
<civodul>yeah i wonder about PATH
<civodul>do you think it should say it too?
<mark_weaver>the README tells me to set ACLOCAL and PATH as recommended by guix package, but guix package doesn't tell me anything about those.
<mark_weaver>should I be setting ACLOCAL?
<civodul>ah ok
<civodul>ok, i'm fixing README
<mark_weaver>civodul: btw, it seems that I've never quite understood how I should be configuring my environment variables to build software the old-fashioned way (outside of guix), but using the guix toolchain, tools and libs. this "installing guix from guix" section of the readme now gives me some hints, but it would be good if this was better documented in general.
<mark_weaver>for example, for a long time I didn't know about ld-wrapper and whether I should be using it, and also I never knew about GUIX_LD_WRAPPER_ALLOW_IMPURITIES, and am still unclear on what it does exactly.
<civodul>mark_weaver: agreed, i think we need at least a section in the manual
<civodul>a_e had troubles setting it up too
<mark_weaver>btw, when I have both ld-wrapper and binutils installed, it tells me that it's "arbitrarily" choosing the 'ld' from ld-wrapper. Is this a dice roll, or is it somehow rigged to make sure I get the right one? it seems brittle.
<mark_weaver>(admittedly, I've never seen it choose the 'ld' from binutils, which is good :)
<mark_weaver>(sorry for all the negative feedback in a short time; just rememebering a few things that should be noted before I forget to mention them :)
<mark_weaver>but on the bright side, GCC 4.8 by default in core-updates, yeah! :)
<civodul>mark_weaver: dice roll! :-)
<civodul>actually no: the latest wins
<civodul>so you have to install binutils and ld-wrapper in the right order
<civodul>guix package --install={binutils,ld-wrapper}
<mark_weaver>ah, okay.
<civodul>yes, that sucks :-/
<mark_weaver>it's okay, at least it can be controlled. there's plenty to do, but we'll get to it in time.
*civodul goes afk for a while
<mark_weaver>civodul: I'm bootstrapping the new core-updates (with GCC 4.8) on the 3A machine now. It seems to be going alright, although "make check" failed two tests (package-source-derivation, snippet; and union-build)
<mark_weaver>civodul: the snippet one resulted in a guile backtrace.
<mark_weaver>hi zacts.
<civodul>mark_weaver: can you post test-suite.log and {packages,union}.log?
<mark_weaver>sure, I'll do it now.
<mark_weaver>I have to go afk for a bit..
<civodul>it's trivially fixed BTW :-)
<mark_weaver>ah, good!
<civodul>i just changed libc in core-updates
<civodul>(unrelated to the libgcc_s issue)
<mark_weaver>ah, thanks. I'll restart my MIPS bootstrap
<mark_weaver>wow, gcc-cross-boot0-4.8.2 built in 42 minutes on the Loongson 3A. nice!
<mark_weaver>civodul: with all these changes to the core packages, do you think it makes sense to rebuild the bootstrap tarballs again? or is it unimportant?
<mark_weaver>also, I wonder if it makes sense to upgrade the linux headers to a newer version.
<mark_weaver>there's also a new version of gettext ( upstream.
<mark_weaver>well, just some random thoughts... going afk for a bit...
<civodul>mark_weaver: it's not necessary to rebuild the bootstrap tarballs
<civodul>we kept the previous ones for 10 months
<civodul>updating gettext is a good idea though, and a_e wanted to add expat support
<civodul>anyway, g'night/day!