similar to: Missing File Makefile.in

Displaying 20 results from an estimated 2000 matches similar to: "Missing File Makefile.in"

2006 Aug 23
0
compiz after today update
today i upgraded compiz and i get this error. compiz: GLX_EXT_texture_from_pixmap is missing compiz: Failed to manage screen: 0 compiz: No managable screens found on display :1.0 my compile command is > PKG_CONFIG_PATH=/opt/Xgl/lib/pkgconfig ACLOCAL='aclocal -I > /opt/Xgl/share/aclocal' ./autogen.sh --prefix=/opt/Xgl > --with-gl-libs="/opt/Xgl/_tmp_/mesa/lib/libGL.a
2010 May 18
1
problem compiling pigeonhole + my fix
hello, yesterday I tried to package dovecot-2.0beta5 + pigeonhole from Mercurial repository. I put pigeonhole as a subdir in the dovecot sourcetree. Following http://hg.rename-it.nl/dovecot-2.0-pigeonhole/raw-file/tip/INSTALL I called ./autogen.sh; ./configure --with-dovecot=..; make In the buildprocess I saw this output ( from autogen.sh ): Putting files in AC_CONFIG_AUX_DIR, `..'.
2017 Aug 01
0
configure.ac
If you check developer.r-project.org, you'll find links to the scripts that we use for building releases and pre-releases of R. These are usually run on a Mac, but shouldn't require much change for Linux. In particular, notice this lead-in in the prerelease script: rm -rf BUILD-dist mkdir BUILD-dist cd R aclocal -I m4 autoconf cd ../BUILD-dist ....etc.... -pd > On 1 Aug 2017, at
2006 Sep 29
1
undeclared identifier 'space' in function MetaButtonSpace
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DORBIT2=1 -pthread -I/opt/Xgl/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/libwnck-1.0 -I/opt/Xgl/include -I/usr/include/metacity-1 -I/usr/include/gtk-2.0
2019 Jan 13
0
[FTS Xapian] Beta release
I tried to combined it, the "autoreconf" errors are solved Now, when I type "make install", the lib is not pushed into dovecot folder, but somewhere in /usr/local/... How to adjust this to have it arriving in the proper folder ? On 2019-01-13 21:01, Tuomi, Aki wrote: > You copied your Makefile.am there. Stephan made you a working version, can you try that? > >
2019 Jan 14
0
[FTS Xapian] Beta release
Thank you Stephan. The version here shall be up and running : https://github.com/grosjo/fts-xapian On 2019-01-14 00:07, Stephan Bosch wrote: > Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot: > >> I tried to combined it, the "autoreconf" errors are solved >> >> Now, when I type "make install", the lib is not pushed into dovecot folder, but
2019 Jan 14
0
[FTS Xapian] Beta release
THank you Odhiambo. I updated accordingly On 2019-01-14 08:07, Odhiambo Washington wrote: > In your README.md, perhaps "This project intends to provide a straightforward and simple PROCEDURE to configure FTS plugin for Dovecot, leveraging the efforts by the Xapian.org team." is better?? > Also in the part after cloning from git: > > ./configure --prefix=/usr
2019 Jan 14
0
[FTS Xapian] Beta release
Can you send the log part that includes the "init" of the plugins (something similar as below) ? WHich version of Xapian are you on ? Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(admin at grosjo.net)<14725><apZfHexRPFy9QAAA0thIag:UL+TNOxRPFyFOQAA0thIag>: FTS Xapian: Partial=2, Full=20 DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes Jan 14 09:10:04 gjserver
2017 Aug 01
3
configure.ac
Hi, Just a quick mail to mention that I cannot generate a new configure script using autoconf or autoreconf. I had edited the configure.ac and thought ... "oh, that's my fault", but then I tried it on R-patched and R-3.4.1 without touching configure.ac and had the same problems. The "building R packages" documentation seems to suggest that "autoconf" should take
2019 Jan 14
0
[FTS Xapian] Beta release
Just to remind that now that there is a github repo for fts-xapian, you could maybe open these issues there instead? Aki On 14.1.2019 14.29, Odhiambo Washington wrote: > Testing a compile on FreeBSD. > > gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src' > /bin/sh ../libtool? --tag=CXX? ?--mode=compile c++ -DHAVE_CONFIG_H -I. > -I..?
2019 Jan 13
3
[FTS Xapian] Beta release
You copied your Makefile.am?there. Stephan made you a working version, can you try that? (sorry for dup) Aki -------- Original message --------From: Joan Moreau <jom at grosjo.net> Date: 13/01/2019 21:39 (GMT+02:00) To: Stephan Bosch <stephan at rename-it.nl> Cc: Aki Tuomi <aki.tuomi at open-xchange.com> Subject: Re: [FTS Xapian] Beta release I used the skeleton from Aki :
2019 Jan 14
2
[FTS Xapian] Beta release
In your README.md, perhaps "This project intends to provide a straightforward and simple *procedure *to configure FTS plugin for Dovecot, leveraging the efforts by the Xapian.org team." is better?? Also in the part after cloning from git: ./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This /path/to/dovecot is not obvious. Is it the dovecot binary or what??] On Mon, 14 Jan
2019 Jan 13
3
[FTS Xapian] Beta release
Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot: > > I tried to combined it, the "autoreconf" errors are solved > > Now, when I type "make install", the lib is not pushed into dovecot > folder, but somewhere in /usr/local/... > > How to adjust this to have it arriving in the proper folder ? > Depends on your system. It mostly a matter of setting
2019 Jan 14
2
[FTS Xapian] Beta release
Op 14-1-2019 om 13:40 schreef Aki Tuomi: > > Just to remind that now that there is a github repo for fts-xapian, > you could maybe open these issues there instead? > Although README.md currently says: "Please feel free to send your questions, together with the dovecot log file, to jom at grosjo.net <mailto:jom at grosjo.net> or to the dovecot ML dovecot at dovecot.org
2019 Jan 14
3
[FTS Xapian] Beta release
Testing a compile on FreeBSD. gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src' /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. -I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo fts-backend-xapian.cpp libtool:
2016 Oct 18
6
CyberPower SX650G no driver.
Got the: git clone git://github.com/networkupstools/nut.git To work. Had to all so do this: apt-get install autoconf apt-get install libtool Did put driver = usbhid-ups in the /etc/nut/ups.conf file like you said. Here is what I got for it all: root at odroid-u2:~/nut# ./autogen.sh Calling autoreconf... libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying
2019 Jan 14
3
[FTS Xapian] Beta release
Hi, I installed and tested your version, but the indexer process crashes reproducible with the following command after about 2000 messages were indexed: doveadm index -u paul at iwascoding.com -q \* Jan 14 09:26:15 mail dovecot: indexer-worker(paul at iwascoding.com)<16777><IKpfOqBHPFyJQQAADYqDFA>: Debug: Mailbox sent: UID 2038: Opened mail because: fts indexing Jan 14 09:26:15 mail
2018 Jul 28
2
Error building nbdkit on RHEL 7.5 - possibly undefined macro: PKG_CHECK_VAR
I'm trying to build upstream source on RHEL 7.5 and get this error: # autoreconf -i libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying
2018 Jul 28
0
Re: Error building nbdkit on RHEL 7.5 - possibly undefined macro: PKG_CHECK_VAR
On Sat, Jul 28, 2018 at 09:26:06PM +0300, Nir Soffer wrote: > I'm trying to build upstream source on RHEL 7.5 and get this error: > > # autoreconf -i > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize:
2009 Aug 12
1
[PATCH libguestfs] build: enable automake's color-tests option
Only marginally useful, but some like it... This makes tests print "PASS" in green, and "FAIL" in red, when possible: The autogen.sh snippet ensures that this automake-1.11 feature is disabled when building-from-clone on a system with too-old automake. This *does* modify a source file (and a version-controlled one at that), but only when building from source on e.g. RHEL*