I compiled the GNU sed with MinGW+MSYS:
./configure
make && make install
and it worked.
But what has come to trouble me is that the sed.exe can not run without libintl-8.dll libiconv-2.dll.
How to solve this problem?
./configure LDFLAGS=-static
make
ref
Related
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 have gentoo ~amd64 installed
and I'm trying to create a crossdev environment for armv7a-hardfloat-linux-gnueabi.
my CFLAGS are `CCFLAGS="-O2 -pipe -fomit-frame-pointer".
when I try to compile the base system, it tries to compile libgpg-error and fails with:
gawk: fatal: cannot use gawk builtin `namespace' as variable
how do I resolve this to continue and build my crossdev environment ?
I tried downgrading gawk from 5 to 4 but the results are the same.
thanks
Same problem on my side:
"namespace" name is not acceptable by gawk-5.0
try:
sed -i \
-e "s/namespace/varerrno/g" \
src/{Makefile.am,mkstrtable.awk}
Before doing ./autogen.sh or/and ./configure
Hoping that help.
Could it be a typo?
Change "libpgp-error" to "libgpg-error".
Even one of the blue buttons has label "libgpg-error"
I have GnuWin32 Make and GnuWin32 Coreutils, installed and on my PATH. This works:
coq_makefile -f _CoqProject -o Makefile.coq
make -f Makefile.coq Frap.vo
But if I open Frap.v in CoqIDE, and do Compile > Make, the only output I see is this:
Compilation output:
Is this expected? How can I get Coq to build this?
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.
I just installed cygwin 1.7, and wrote a simple Hello world in test.c
but when I complie, nothing happens, even no error messages
gcc-4 -o test.exe test.c
And there's nothing generated under my folder.
I have included C:\cygwin;C:\cygwin\bin in my PATH
Did I miss something?
EDIT:
for more information, I installed Qt4, tortoiseHg, and mingw before.
Now I had removed mingw. but still got Qt4 and tortoiseHg, is this a problem?
Try doing this from the Cygwin Terminal, not cmd.exe:
$ cd `cygpath -u "$USERPROFILE"`/Desktop/UT
$ gcc -o foo foo.c
$ ls -l foo
-rwxr-xr-x+ 1 yourlogin None 19618 May 10 05:15 foo*
If that works, there's some bogus remnant lying around.
You'll find that the Cygwin experience is generally better running under Bash, in a MinTTY terminal anyway. cmd.exe doesn't understand Cygwinisms, and is a DOS throwback besides.
Note that you don't need to say gcc-4 to get GCC 4.x. gcc is GCC 4.x on Cygwin, and has been for quite some time now.
Also note that you don't need to include .exe in the GCC -o flag, because Cygwin GCC knows to add that already.