NFS locking problems

We often encounter NFS locking problem when building packages on mandriva build cluster: autom4te-2.5x: cannot lock autom4te.cache/requests with mode 2 (perhaps you are running make -j on a lame NFS client?): No locks available From http://lists.gnu.org/archive/html/autoconf/2003-09/msg00095.ht

libraries transitives dependencies

I often run into problem, when testing libraries presence, with unresolved symbols. Unless misconprehension of mine, gcc don't force you to solve all symbols at linking time when creating a shared libraries. As a result, you have to add additional librairies in the linking command, which is the pur

linker default library search path

I recently get surprised by different behaviour of AC_CHECK_LIB on x86_64 and i586 mandriva machines. It seems than on the first one, /usr/local/lib is also part of the default search path. I read ld documentation, but I couldn't find any way to explicitely check my assumption. So, is there any way

Re: Using config binaries to find libraries and include dirs

Paulo J. Matos wrote: > Hi all, > > Some libraries include a xxx-config which accepts --libs or --includes > and report the flags and the include dirs the compiler should use. How > can one use this information in the context of autotools? Usually something as: AC_PATH_PROG(FOO_CONFIG, foo-config)

Re: linker default library search path

Bob Proulx wrote: > Guillaume Rousse wrote: >> I recently get surprised by different behaviour of AC_CHECK_LIB on >> x86_64 and i586 mandriva machines. It seems than on the first one, >> /usr/local/lib is also part of the default search path. I read ld >> documentation,

what is the best place for language specific macros ?

I'd like to start working on unifying various ocaml-related macros. However, I wonder what is the best place for submitting them: in ocaml tree directly, or in autoconf ? Is there any recommended practice for this ? -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt

checking version of a specific language interpreter/compiler

oconf manual discourage such checks: "Avoid running test programs if possible, because this prevents people from configuring your package for cross-compiling." So, is there a reason for prefering target code here ? -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.

troubles with autoreconf

I'm just using autoconf, with an aclocal.m4 file with my own macros. autoconf works perfectly, but not autoreconf: [EMAIL PROTECTED]:~/test/yquem/camlimages$ autoreconf autoheader: warning: missing template: GIFLIB_BUG_FIXED autoheader: Use AC_DEFINE([GIFLIB_BUG_FIXED], [], [Description]) autohead

Re: troubles with autoreconf

Stepan Kasal wrote: > Hello, > > On Wed, Sep 13, 2006 at 05:07:32PM +0200, Guillaume Rousse wrote: >> autoconf works perfectly, but not autoreconf: > > please not that these two tools are very different: > - autoconf builds configure from configure.ac > - autoreconf

autoreconf not passing -I option to aclocal

L If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf-2.5x: /usr/bin/autoconf failed with exit status: 1 AC_PROG_OCAML is defined in ../autoconf/ocaml.m4 file. -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Ro

Re: autoreconf not passing -I option to aclocal

Eric Blake wrote: > According to Guillaume Rousse on 9/28/2006 2:31 AM: >>> I got troubles using autoreconf with custom macros. It appears than >>> autoreconf doesn't pass -I option to aclocal for importing them, only to >>> autoconf, but it does not seems to

Re: autoreconf not passing -I option to aclocal

Eric Blake wrote: > According to Guillaume Rousse on 9/28/2006 7:09 AM: >>>>>> autoreconf-2.5x: running: aclocal >>>> Sounds like you forgot to do >>>> ACLOCAL_AMFLAGS = -I ../autoconf >>>> >>>> in your Makefile.am. >>&

Re: autoreconf not passing -I option to aclocal

Stepan Kasal wrote: > Hello Guillaume, > > On Thu, Sep 28, 2006 at 03:44:30PM +0200, Guillaume Rousse wrote: >> [...] aclocal is useful even when you don't use automake, for >> importing your own macros as in my case, [...] > > I agree with you, ... > >>

Re: autoreconf not passing -I option to aclocal

at you are not using automake because configure.ac does > not call AM_INIT_AUTOMAKE. But autoreconf greps Makefile.am for that > assignment, even in that case. > > I understand it looks ugly, and it might confuse people, though. Moreover, it requires me to specify a path to a file ex

autoreconf improvement suggestion

, you have to do it manually. -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

managing ocaml dependencies

I'm trying to use autoconf for ocaml project, and I have troubles with managing dependencies. They are generated through a specific program, ocamldep, that basically output makefile rules, so as to be used this way: .depend: $(OCAMLDEP) *.ml *.mli > .depend include .depend They are two d

Re: managing ocaml dependencies

Ralf Wildenhues wrote: > Hello Guillaume, > > Do you use Automake? If yes, or if you want to add support for ocaml to > Automake, then probably its list would be more appropriate. If not, all > of the following has relevance without Automake, it's just colored that > way

Re: managing ocaml dependencies

Guillaume Rousse wrote: > For 1), the attached patch seems to be enough. It seems to have been forgotten somewhere, here it is again. --- /usr/share/automake-1.9/depcomp 2006-09-27 03:44:18.0 +0200 +++ depcomp 2006-11-21 13:57:48.0 +0100 @@ -508,6 +508,10 @@ rm