[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can't configure guix, no guile-sqlite3

From: Thorsten Wilms
Subject: Re: Can't configure guix, no guile-sqlite3
Date: Thu, 2 Aug 2018 13:40:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 02.08.2018 09:12, Chris Marusich wrote:

configure: error: Package requirements (sqlite3 >= 3.6.19) were not met:
No package 'sqlite3' found

It sounds like you're saying this error occurs when you've run "guix
environment guix", and then you run "./configure --localstatedir=/var".
Is that right?


* Run "guix pull" at least twice - without using ./pre-inst-env.


* Start from a clean slate.

       make distclean
       git clean -dfx
       git reset --hard
* Make sure you're using a recent Guix:

       git pull


* Now try to build again:

       ./configure --localstatedir=/var

For the sake of completeness, without `guix environment guix`, this happens: error: possibly undefined macro: GUILE_MODULE_AVAILABLE

With `guix environment guix` it's again:
checking for sqlite3 >= 3.6.19... no
configure: error: Package requirements (sqlite3 >= 3.6.19) were not met:

No package 'sqlite3' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables SQLITE3_CFLAGS
and SQLITE3_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

FWIW, you might also consider trying to develop your packages by putting
the package definitions on your own GUIX_PACKAGE_PATH (see "Package
Modules" in the manual), rather than using ./pre-inst-env.
GUIX_PACKAGE_PATH is the recommended way for adding custom packages,
while ./pre-inst-env is technically an unsupported hack that is
primarily useful for developing Guix itself.

I have to wonder about "unsupported hack". If it is one, then
needs to be altered.

In this case (a rather obscure Emacs package), it would make sense to use GUIX_PACKAGE_PATH and perhaps not even bother sending a patch. However, for any chance of later, more involved and worthwhile contributions, I figured I should get the process down as described. Especially since even my limited experience tells me any deviation between a test run and later use introduces a risk of some silly mistake to slip in.

Been there before, but checking again:
Within or outside of `guix environment guix`, same result:
   which guix
=> /home/thorwil/.config/guix/current/bin/guix
   ls -l /home/thorwil/.config/guix/current/bin/guix
=> lrwxrwxrwx 2 root root 56 Jan 1 1970 /home/thorwil/.config/guix/current/bin/guix -> /gnu/store/aldvc43h0gyqmpl08yzpfgmcz77539sk-guix-command
   stat /gnu/store/aldvc43h0gyqmpl08yzpfgmcz77539sk-guix-command
=> <snip> Change: 2018-08-02 12:05:49.134396623 +0200

Still, thanks for your detailed email, Chris!

Thorsten Wilms

thorwil's design for free software:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]