I am trying to build a project that requires two include paths.
My command is:
./autogen.sh --prefix /usr/ --libdir /usr/lib/x86_64-linux-gnu/ CXXFLAGS="-I${TensorflowPath} -I${TensorflowPath}/tensorflow/lite/tools/make/downloads/flatbuffers/include" --enable-tflite
and I have set TensorflowPath to the correct path for my tensorflow source directory.
but the error I get is:
configure: error: unrecognized option: `-I/home/aaron/src/tensorflow/tensorflow/lite/tools/make/downloads/flatbuffers/include'
This is really maddening! The second or third option is always erroring out. Please advise !!
This autogen.sh script appears to be broken both conceptually by unifying two very distinct steps (generating configure with its related files and running configure) into one without good reason, and by the actual implementation of that broken concept using a broken way of passing command line arguments to the child configure process.
If you can replace the call to autogen.sh with a call to autoreconf -vis ., just do that and ignore the broken autogen.sh:
autoreconf -vis .
./configure CXXFLAGS="-Ifoo -Ibar" --prefix=/what/ever --and-so-on
make
make install
If you absolutely need to use that autogen.sh script and cannot just replace it with a call to autoreconf -vis ., call autogen.sh with the single parameter --help to prevent it from running configure with any consequences.
The single --help argument contains no spaces and thus even an autogen.sh script with shell quoting bugs should pass it on correctly to configure. Now autogen.sh should do its buildsystem setup first, and then run configure --help which does nothing but print a bunch of messages to the console.
Then you can run your actual configure command with the correct parameters afterwards:
./autogen.sh --help
./configure CXXFLAGS="-Ifoo -Ibar" --prefix=/what/ever --and-so-on
make
make install
Related
Been pulling out my hairs on this one, it must be so simple but for some reason I can't get it to work..
I'm using go1.15, on Ubuntu 18.04, trying to build lnd from source off of github.
I run sudo make install after all the preliminaries but keep getting error
GO111MODULE=on go install -v -tags="" -ldflags " -s -w -X github.com/lightningnetwork/lnd/build.Commit=v0.11.0-beta-199-g98da919bf1c421dd4a976506761e626e39384a8d -X github.com/lightningnetwork/lnd/build.CommitHash=98da919bf1c421dd4a976506761e626e39384a8d -X github.com/lightningnetwork/lnd/build.GoVersion= -X github.com/lightningnetwork/lnd/build.RawTags=" github.com/lightningnetwork/lnd/cmd/lnd
/bin/sh: 1: go: not found
Makefile:139: recipe for target 'install' failed
make: *** [install] Error 127
i have GOPATH=/usr/local/go and have added /usr/local/go/bin to my PATH variable
can't understand what i am doing wrong
go version returns normally
I'm an intermediate programmer, but been using Linux for many years and do not understand what is going on.
Just in case somebody finds this the answer is that the golang installation instructions say to update your PATH variable in ~/.profile but this only applies to interactive shells, not scripts. So if you want to properly update this for scripts you'll have to find another way. My quick fix was just inserting a PATH update into the script itself.
Link for solution is:
Bash script can't execute Go command
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
I want to create a run command in notepad++, that cleans/deletes the compiled files whenever I press Ctrl + M. So far I created this line of code :
cmd /k c:\WinAVR-20100110\utils\bin\make.exe make clean $(FULL_CURRENT_PATH)
It does not work and gives this warning :
No Rule To make target clean
Which technically means the parameter is wrong, however I did not find a way to correct it.
Any Suggestions
You don't want to pass make as an argument to make because then it will look for a target named make which is not defined.
Also, you would need to make sure make is running in the right directory. One way to do that is use the -C option. For example:
make -C path/to/my/dir clean
Some unsolicited tips: WinAVR is really old, see how you are using the version from 2010-01-10? I'd recommend using MSYS2 for your Bash shell environment and then installing the latest AVR 8-bit toolchain from Atmel.
I have a makefile that works on a Windows system when sh.exe is not on path. But when sh.exe is on Windows path, it stops with an error. Apparently, sh.exe can not handle paths with mixed / and \ such as this one:
cc $CFLAGS) C:\a\b/c/d/myfile.c
it generates the following error
Fatal error: could not open source file "c:ab/c/d/myfile.c"
As I am not able to change the makefile (it is auto generated by some application), how can I force gmake not to use sh.exe or force sh.exe to accept such files?
Try gmake SHELL="cmd". See the GNU make docs for more information. In particular, note this tidbit:
Note that this extended search for the shell is limited to the cases
where SHELL is set from the Makefile; if it is set in the environment
or command line, you are expected to set it to the full pathname of
the shell, exactly as things are on Unix.
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.