[Top][All Lists]

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

Re: non standard name of a dependency

From: Eric Blake
Subject: Re: non standard name of a dependency
Date: Fri, 21 Sep 2018 15:09:10 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 9/21/18 2:44 PM, Catonano wrote:
I don't know if this is the right place to ask. If it's not, I apologize

I'd like to build guile-commonmark ( ) on Fedora 28

I'd like to build it against guile 2.2.2

On Fedora 28 x86_64 there are 2 versions  of Guile

Guile 2.0.14


Guile 2.2.2

Guile 2.0.14 is in /usr/bin/guile

Guile 2.2.2 is in /usr/bin/guile2.2

this is what happens

configure: checking for guile 2.2
configure: found guile 2.2

What does config.log say it actually found?

checking for guile... /usr/bin/guile

Wait? Why is configure checking twice? You'll need to investigate what the for guile-commonmark is using, and why it is repeating two different checks for guile (one that found the right version, another that found the wrong one). If that code in uses a cache variable (${prefix}_cv_$...) and/or an environment variable (probably $GUILE) to encode the result of the guile binary, then the immediate workaround is to set that cache or environment variable as an argument to configure, so that when it gets to that particular check, it already has the answer you told it to use instead of the one it guesses from your environment. If their used AC_CHECK_PROGS([guile]), then both of these should work:

./configure GUILE=/usr/bin/guile2.2
./configure ac_cv_prog_guile=/usr/bin/guile2.2

You'll also want to file a bug report to the guile-commonmark package maintainers to have them improve their if it isn't already easily overridable.

configure: error: found development files for Guile 2.2, but /usr/bin/guile
has effective version 2.0

I'm afraid of removing guile 2.0.14 because it seems that an awful lot of
stuff depends on it

No, you shouldn't need to remove it.

How can I build guile-commonmark against guile 2.2.2 ?

Is this a task for the package author ?

Autoconf recommends using cache variables (for overriding decisions that are otherwise guessed incorrectly from probing the system) and envrionment variables (for pointing to a specific version of a tool that you want to use), so this list is the appropriate place to ask about how those things work in general. However, whether those things were actually used correctly for the package in question is something for the package author to answer, according to their, which autoconf does not maintain (although the package maintainer should feel free to continue this thread if they need help improving their to match recommended best practices).

Or can I instruct the build system somehow about which guile to use ?

Yes, that should be possible if the package followed the autoconf recommendations for allowing overrides.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization: |

reply via email to

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