From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: libgcrypt Date: Thu, 7 Feb 2013 10:33:24 +0100 Message-ID: <201302071033.24745.andreas@enge.fr> References: <201302062335.21194.andreas@enge.fr> <87y5f1awvz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_kT3ERn3zlXSD7ed" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:55945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3NrI-0005iA-PZ for bug-guix@gnu.org; Thu, 07 Feb 2013 04:33:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3NrG-0007Q3-3o for bug-guix@gnu.org; Thu, 07 Feb 2013 04:33:32 -0500 In-Reply-To: <87y5f1awvz.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?utf-8?q?Court=C3=A8s?= Cc: bug-guix@gnu.org --Boundary-01=_kT3ERn3zlXSD7ed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch, 6. Februar 2013 schrieb Ludovic Court=C3=A8s: > Andreas Enge skribis: > > checking whether libgcrypt can be dynamically loaded... no > > configure: error: GNU libgcrypt does not appear to be usable; see > > `--with- libgcrypt-prefix' and `README'. > Just pass --with-libgcrypt-prefix=3D$HOME/.guix-profile/lib. Yes, that should work, but... > The code corresponding to the check above is simple-minded (it=E2=80=99s = in > m4/guix.m4). All it does is: > guile -c "(dynamic-func \"gcry_md_hash_buffer\" (dynamic-link > \"$LIBGCRYPT\"))" > and checks its return code. > Passing --with-libgcrypt-prefix allows it to work with non-standard > prefixes. =2E.. under guix, $HOME/.guix-profile/{lib,...} is the standard prefix ;-) So would it be possible to modify the test so that it takes LIBRARY_PATH=20 into account? (If it were C, the AC macros would do that automatically.) Or= =20 could one simply use AC_CHECK_LIB? If not, a possible work-around would be to check explicitly with the=20 $HOME/.guix-profile/lib prefix. Andreas --Boundary-01=_kT3ERn3zlXSD7ed Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Am Mittwoch= , 6. Februar 2013 schrieb Ludovic Court=C3=A8s:

> Andrea= s Enge <andreas@enge.fr> skribis:

> > c= hecking whether libgcrypt can be dynamically loaded... no

> > c= onfigure: error: GNU libgcrypt does not appear to be usable; see

> > `= =2D-with- libgcrypt-prefix' and `README'.

> Just p= ass --with-libgcrypt-prefix=3D$HOME/.guix-profile/lib.

&nb= sp;

Yes, that s= hould work, but...

&nb= sp;

> The co= de corresponding to the check above is simple-minded (it=E2=80=99s in

> m4/gui= x.m4). All it does is:

> guil= e -c "(dynamic-func \"gcry_md_hash_buffer\" (dynamic-link

> \"= ;$LIBGCRYPT\"))"

> and ch= ecks its return code.

> Passin= g --with-libgcrypt-prefix allows it to work with non-standard

> prefix= es.

&nb= sp;

... under g= uix, $HOME/.guix-profile/{lib,...} is the standard prefix ;-)

&nb= sp;

So would it= be possible to modify the test so that it takes LIBRARY_PATH into account?= (If it were C, the AC macros would do that automatically.) Or could one si= mply use AC_CHECK_LIB?

&nb= sp;

If not, a p= ossible work-around would be to check explicitly with the $HOME/.guix-profi= le/lib prefix.

&nb= sp;

Andreas

&nb= sp;

--Boundary-01=_kT3ERn3zlXSD7ed--