I am trying to compile nano and hitting some problems.
Details are as follows -- versions I cannot change (compiling on s390 architecture and don't have access to other versions):
Nano source version 2.9.7
Using autoconf version 2.62
Using automake version 1.10
Changed configure script so it looks for tooling version 1.10 instead of 1.15 by altering configure line am__api_version='1.10'
I run configure, and then I run make. On running make I get the following error:
make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /u/user/source/nano-2.9.7/missing aclocal-1.10 -I m4
main::scan_file() called too early to check prototype at /workarea/tools/automake/bin/aclocal-1.10 line 604.
configure.ac:27: error: Autoconf version 2.69 or higher is required
configure.ac:27: the top level
autom4te: /usr/local/bin/m4 failed with exit status: 63
aclocal-1.10: autom4te failed with exit status: 63
WARNING: 'aclocal-1.10' is probably too old.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
FSUM8226 make: Error code 63
I note on the first line it says : CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /u/user/source/nano-2.9.7/missing aclocal-1.10 -I m4 I don't know how to read this error, given aclocal-1.10 is on my path and installed. When I run aclocal-1.10 from my bash shell I get :
aclocal-1.10
main::scan_file() called too early to check prototype at /workarea/tools/automake/bin/aclocal-1.10 line 604.
aclocal-1.10: `configure.ac' or `configure.in' is required
Update
I went to line 27 of configure.ac and changed the line
AC_PREREQ([2.69]) to AC_PREREQ([2.62]). Now when the make command is issued it fails with the following error:
source/nano-2.9.7: >make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /u/user/source/nano-2.9.7/missing aclocal-1.10 -I m4
main::scan_file() called too early to check prototype at /workarea/tools/automake/bin/aclocal-1.10 line 604.
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /u/user/source/nano-2.9.7/missing autoheader)
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
FSUM8226 make: Error code 1
make: './config.h.in' removed.
Please offer guidance and support around how to work around my system imposed limitations in order to compile my favourite command line editor!
Two easy solutions: Update your autoconf package.
Or fix your timestamps, so that autoconf isn't reinvoked, e.g. by touching all files in the distribution.
find . | xargs touch
Related
I'm running Cygwin on Windows 7 and trying to build a program I downloaded. I cd to where I have my file.tar.gz and type
tar -xvf file.tar.gz
and Cygwin successfully spits out a list of what's in there. (point of confusion: for some reason, -xvzf doesn't work, even though the file claims to be zipped. Also, I expected there to be an untarred folder put somewhere in my directory, but there's not.)
Then I type
make
and get
c++ -O -c gmm.c -o gmm.o
make: c++: No such file or directory
make: *** [makefile:19: gmm.o] Error 127
I expected this to create a gmm.exe (according to the documentation of this program). What's going on?
As #stark mentioned you are missing the C++ compiler.
To find in which package is, use cygcheck -p to ask the Cygwin Webserver
$ cygcheck -p bin/c++
Found 17 matches for bin/c++
...
binutils-2.35.2-1 - binutils: GNU assembler, linker, and similar utilities
...
gcc-g++-10.2.0-1 - gcc-g++: GNU Compiler Collection (C++)
gcc-g++-7.4.0-1 - gcc-g++: GNU Compiler Collection (C++)
...
After you install the gcc-g++ package, you will have the program c++
in the standard directory for programs
$ cygcheck -l "gcc-g++" |grep "usr/bin/c++"
/usr/bin/c++.exe
I'm trying to install a package called fminuit http://www.fis.unipr.it/~giuseppe.allodi/Fminuit/Fminuit_building.html
on ubuntu 18.04 machine using Octave. The installation step "make -f Makefile.f2c_lnx.Octave" gives me the following error
WrapIO_Matlab.c:4:10: fatal error: mex.h: No such file or directory
Any idea how to remedy this,
cheers, Damir
The build instructions provided by FMINUIT ask you to manually adapt the Makefile to your setup. I'm guessing you did one of those steps incorrectly. I'm running Octave 6.0.0 (current development sources) and worked fine:
$ wget http://www.fis.unipr.it/~giuseppe.allodi/Fminuit/fminuit-src.tar.gz
$ tar xzf fminuit-src.tar.gz
$ cd fminuit-2011.05.31/fminuit/
# modify Makefile.f2c_lnx.Octave
$ make -f Makefile.f2c_lnx.Octave
$ make -f Makefile.f2c_lnx.Octave install
The tricky part is knowing what to modify on the Makefile. For my case, these were the lines (you need to know the exact Octave version and where you installed it):
#Octave prefix directory (typically /usr or /usr/local): modify if needed
-PREFIX=/usr
+PREFIX=/usr/local
#major version number
-OCTAVE_MAJOR=2
+OCTAVE_MAJOR=6
#minor-release version number
-OCTAVE_MINOR=9.12
+OCTAVE_MINOR=0.0
OBJS= mnintr_wrkrnd.o intrac.o WrapIO_Matlab.o doflush.o
MINUIT=Minuit_.o
INSTDIR=../bin/linux_$(ARCH)/octave$(OCTAVE_MAJOR)
The fminuit Makefile will "install" inside the fminuit source directory. You may also want to adjust its INSTDIR value. You need to adjust your Octave path to use it:
>> addpath('/wherever/you/build/fmunuit/fminuit-2011.05.31/bin/linux_x86_64/octave6')
>> fminuit # you probably can figure out how to call this function
error: fminuit: Too few input arguments
background
I really would like to search for a term in a directory full of Word docs. So I stumbled across this lovely solution. However this solution requires that catdoc is installed on mac.
what I have tried
now homebrew obviously doens't have catdoc:
$ brew install catdoc
Updating Homebrew...
Error: No available formula with the name "catdoc"
==> Searching for a previously deleted formula...
Error: No previously deleted formula found.
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching taps...
Error: No formulae found in taps.
macports does, but I use homebrew and It's not a good idea to have both on my machine.
So I did what any self respecting semi-programmer would do: try to install it from source:
$ ./configure
see outpout
$ ./make
see output
the last part of ./make gives me this
1 warning generated.
gcc -o catppt catppt.o pptparse.o charsets.o substmap.o fileutil.o confutil.o numutils.o ole.o -lm
echo "#! /usr/bin/wish" >wordview
echo set charset_lib "\"/usr/local/share/catdoc\"">>wordview
cat wordview.tcl >>wordview
chmod 0755 wordview
touch build
make[1]: Nothing to be done for `all'.
then when i run make install i get this
make: `install' is up to date.
and obviously catdoc doesn't work:
$ which catdoc
>> nothing
Question
How can I install this?
You could just use the built-in textutil to convert MS-Word documents to text:
textutil -stdout -cat txt SomeFile.doc
or
textutil -stdout -cat txt *.doc
To build catdoc / catppt / xls2csv on Mac OS X (macos)
tested with catdoc-0.95 on Mac OS X 10.9.5
Configuration
First, unless your documents are likely to be written in a Cyrillic language, start with:
$ ./configure --with-input=cp1252 --with-output=mac-roman
(if you are more likely to encounter files from Windows)
... or ...
$ ./configure --with-input=mac-roman --with-output=mac-roman
(if you are more likely to encounter files from MacOS)
Building
$ make all (or just $ make)
Installation
make --directory=src install; make --directory=doc install; make --directory=charsets install
This should compensate for the error you received, abbood. It appears the primary Makefile isn't running the install portion of the three subdirectories, for some reason. If a permissions error is reported, precede the above command with "sudo".
I don't believe this should be necessary, but I'm not familiar enough with makefiles to provide a more proper (textbook) fix.
One can, of course, get the same effect by:
$ cd src
$ make install
$ cd ../doc
$ make install
$ cd ../charsets
$ make install
$ cd ..
Cleanup
To remove all files created by make, type:
$ make clean
To remove all files created by make as well as those created by ./configure, type
$ make distclean
I'm trying to install ncurses 5.9 on OS X 10.8 with GCC 4.9 installed. No errors or warnings show up when I run ./configure in the ncurses directory, but when I run make, I get gcc: error: unrecognized command line option ‘-no-cpp-precomp’. Upon googling the issue (and trying it out), I found that --no-cpp-precomp (with two dashes, i.e in long flag form) is a valid command.
I'm not sure what was prompting GCC to run the invalid command – whether it was make, or if it was a command specified in ncurses itself.
Is there any way to fix this? If so, how?
EDIT: I tried changing the reference in the ./configure file from -no-cpp-precomp to --no-cpp-precomp manually, using a text editor, and was met with this, despite GCC seemingly accepting the --no-cpp-precomp option. After that, I tried running autoreconf, and got this:
configure:6558: error: possibly undefined macro: AC_DIVERT_HELP
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /opt/local/bin/autoconf failed with exit status: 1
After running it with the m4_pattern_allow option:
autoreconf: 'configure.ac' or 'configure.in' is required
After running ./configure && make anyway:
cd man && make DESTDIR="" all
sh ./MKterminfo.sh ./terminfo.head ./../include/Caps ./terminfo.tail >terminfo.5
cd include && make DESTDIR="" all
cat curses.head >curses.h
AWK=gawk sh ./MKkey_defs.sh ./Caps >>curses.h
sh -c 'if test "chtype" = "cchar_t" ; then cat ./curses.wide >>curses.h ; fi'
cat ./curses.tail >>curses.h
gawk -f MKterm.h.awk ./Caps > term.h
sh ./edit_cfg.sh ../include/ncurses_cfg.h term.h
** edit: HAVE_TCGETATTR 1
** edit: HAVE_TERMIOS_H 1
** edit: HAVE_TERMIO_H 0
** edit: BROKEN_LINKER 0
cd ncurses && make DESTDIR="" all
gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I. -I./../include -I../include -DUSE_BUILD_CC -DHAVE_CONFIG_H -I../ncurses -I. -D_DARWIN_C_SOURCE -DNDEBUG -I. -I../include -I/usr/local/include/ncurses -O2 --param max-inline-insns-single=1200 --no-cpp-precomp ./tinfo/make_hash.c -Wl,-search_paths_first
gcc: error: unrecognized command line option ‘--no-cpp-precomp’
make[1]: *** [make_hash] Error 1
make: *** [all] Error 2
It looks like this has been fixed in the latest patches to ncurses 5.9
The 5.9 source can be found here: ftp://invisible-island.net/ncurses/ncurses-5.9.tar.gz
The latest patches are here: ftp://invisible-island.net/ncurses/5.9/ but the latest rollup patch appears to have the fix: ftp://invisible-island.net/ncurses/5.9/patch-5.9-20130504.sh.gz
To apply the patch, get the 2 files above then:
$ tar xvf ncurses-5.9.tar.gz
$ cd ncurses-5.9
$ gzip -dc ../patch-5.9-20130504.sh.gz | sh
--no-cpp-precomp is an obsolete Apple GCC option it should generate a warnning not an error but if -Werror flag is passed to the compiler it will fail on warnings, either way, you will have to remove it manually from the build scripts and then run autoreconf or you could just remove it from the configure script directly.
I realize this is very old now, but since I'm running into the same issue (need to build on Mac Yosemite 10.10 with GCC 4.9), maybe it'll help someone else too. It looks like the configure script is detecting that it's a Mac and assuming clang is used, even though the 'gcc' from the PATH is GNU. Seems they fixed the detection logic in newer versions. I've found the same issue in Boost 1.37 and it was fixed (somewhere before) Boost 1.55.
I have a binary that runs under my default shell.
The binary runs perfectly o.k. with:
./binary input.dat
However, if I put this inside a make file:
SHELL=/bin/bash
runos:
./binary input.dat
The code crashes and leaves me quite helpless.
Here is what I tested so far, everything inside my Make file and in the shell:
ulimit -a: identical.
Set the shell to bash as seen above.
diff of the environment variables in SHELL and Make with:
env | sort > vars.1
inside make
env | sort > vars.2
Then run the binary with the extra variables in Make with the following command:
env SHLVL=2 MAKELEVEL=1 MAKEFLAGS= ./binary input.dat
strace in the shell and inside make:
strace -o debug binary input.dat
The code keeps on crashing in Make, and runs in the shell. I am already thinking to dump Make for my test cases and just write shell scripts. But I am curious to know what is the difference.
The Fortran code (a mix of F77, F90 and F95) was compiled with gfortran-4.4 and the following options:
FFLAGS= -g -fbacktrace
So, the concrete question is, what can I do to make this binary run under make in Debian!?
update:
I just tested again in a CentOS machine (v5.8), The code inside Makefile does not crash (GNU Make version 3.81).
I also tested on my Debian Wheezy and openSUSE 11.4, both with GNU Make version 3.82 - It crashes!
I tested on Debian Squeeze with GNU Make version 3.81, and it does crash. So, I think it is not dependent on the GNU Make version.
error when crashing:
enter timeloop
------------------------------------------------------------------------
timestep: 1 time: 2.500E-02 days delt: 2.500E-02 days
-------------------------------------------
terminated in routine react_snia
maximum number of iterations exceeded
bye now ...
-------------------------------------------
failure in timeloop
no further time step reduction possible
try reducing min. time step, bye now ...
trying to work around 'GNU Make' using 'waf'
It has been a while since I wanted to test waf, so here is another interesting observation:
I wrote a wscript which contains a function:
import os
def run(ctx):
os.system('./binary input.dat')
And waf run runs!
If I changed the run method to:
import subprocess as sp
def run(ctx):
sp.call('./binary input.dat', shell=True)
The binary also works as expected.
So, now I am thinking GNU Make forks a new sub-shell in a way that causes may binary to fail (although, under RHEL 5.8 Make did work).
solution: compile make from sources ...
Read to find out more.
OK, so after being pretty much desperate, I did what I simply should have done before blame make for all my troubles.
I thought the problem is Debian specific. But I am guessing the version in CentOS-5.8 is a patched version, although it says it's v.3.81.
So, for those who wonder my solution was:
wget http://ftp.gnu.org/gnu/make/make-3.82.tar.gz
tar xvzf make-3.82.tar.gz
cd make-3.82
./configure
./build.sh
# copy make to the directory with the binary and input and run the local make version
./make
# everything works as expected !!!
I thought let's narrow it down -
wget http://ftp.gnu.org/gnu/make/make-3.80.tar.gz
tar xvzf make-3.80.tar.gz
cd make-3.80
./configure
./build.sh
# copy make to the directory with the binary and input and run the local make version
./make
# everything works as expected !!!
Is it the version 3.81 ?
wget http://ftp.gnu.org/gnu/make/make-3.81.tar.gz
tar xvzf make-3.81.tar.gz
cd make-3.81
./configure
./build.sh
# copy make to the directory with the binary and input and run the local make version
./make
# FAIL! Like with the make version in Debian.
Hence, I think I bumped into some very weird bug in GNU Make v.3.81.