GNU m4 install failed after make command - cygwin

Here are the steps I took on cygwin:
- wget http://mirrors.kernel.org/gnu/m4/m4-1.4.18.tar.gz
- tar -xzvf m4-1.4.18.tar.gz
- cd m4-1.4.18
- ./configure --prefix=/usr/local/
- make
The terminal(cygwin) shows these:
C:/Program Files (x86)/GnuWin32/bin/make all-recursive process_begin: CreateProcess(NULL, /usr/bin/sed -n
s/^(sc_[a-zA-Z0-9_-]):./\1/p ./maint.mk ./cfg.mk, ...) failed.
/usr/bin/sh: -c: line 0: syntax error near unexpected token `('
/usr/bin/sh: -c: line 0: `C:/Program Files (x86)/GnuWin32/bin/make all-recursive' make: *** [all] Error 1
Besides, the configure file(please take a look here) contains lots of errors.
I want to install sphinxbase, but it requires autoconf and automake, which require GNU m4. If you have any method to install autoconf and automake without using the GNU m4, please tell me. Thank you.
Update: in the readme, it says that
By default, the `syscmd' and `esyscmd' macros try to use the first
instance of `sh' found by `command -p getconf PATH' at configure time,
with a default of `/bin/sh'. If that default is inappropriate, you
can use `./configure --with-syscmd-shell=location' to specify the
shell to use.
but I don't know what param to set to.
If I run "command -p getconf PATH" in cygwin, it gives me "/bin:/usr/bin".

Related

How to understand this SWI-Prolog makefile - how Linux executable is created?

I am trying to compile grammar parser https://github.com/RichardMoot/Grail into Linux program according to instructions https://github.com/RichardMoot/Grail/blob/master/README and http://www.labri.fr/perso/moot/tutorial/install.html. There is manual how to create Linux executable from SWI-Prolog code http://www.swi-prolog.org/FAQ/UnixExe.html. All that is fine. But I can not find in the Makefile https://github.com/RichardMoot/Grail/blob/master/Makefile any compilation command. SWI-Prolo uses swipl command for compilation but this Makefile swipl calls only once - for displaying the version of the swipl.
I experience some hardship in installation and compilation, that is fine, I can execute/debug Makefile line by line and arrive at the result. But there is problem in my case - I can not see the ultimate goal in my makefile: which lines are responsible for the production of object files (if necessary) and which lines are responsible for the creation of the final Linux executable.
This is windowed program. The source code and documentation contains warnings about incompatibility with the SWI-Prolog 7, but that is fine, I can resolvem them myself, but as I said - I can not see the Makefile lines for creation of exe.
The source code is created by eminent scientist and I certainly don't want to disturb him by so low-level technical question. I would be happy if he continues work on theory and doesn't waste time on low level programming questions. Hope, that there are SWI-Prolog experts.
I am using latest (7.x) SWI-Prolog on Ubuntu 16.x and I have already installed all the mentioned prerequisites.
If you look closely at the provided Makefile, you'll find that the rules all and install are defined as follows (comments added by me):
all:
-cd source ; $(edit) g3 > g3.tmp # Replaces placeholders for your
# ... GRAIL_ROOT install directory.
-cd source ; mv -f g3.tmp g3 # Overwrites `g3` with the filled file.
cd source ; chmod a+x g3 # Makes it executable.
install: # Essentially copies all files to
-mkdir $(datarootdir) # ... your install directory.
-mkdir $(datadir)
cp -f $(images) $(datadir)
-mkdir $(bindir)
cp -f source/insertdot $(bindir)
chmod a+x $(bindir)/insertdot
cp -f $(resources) $(datadir)
cp -f source/*.pl $(bindir)
cp -f source/g3 $(bindir)
If you then do the common make && make install you'll end up with two folders installed in your Grail directory: bin and share. Inside the binary directory you'll have the g3 file that, regardless of being a SWI-Prolog source, has this initial line:
#!/usr/bin/swipl -q -g start -f
% [... prolog code.]
This header should allow your console terminal to determine what interpreter to use for this script (in this case, swipl). In my case, executing Grail with ./g3 returned a SWI-Prolog message indicating that wrong options/command arguments were used.
According to the man, Unix systems have to use option -s at the end of the header (but this didn't work either in my case):
From the manual:
-s file
Load file as a script. This option may be used from the shell to
make Prolog load a file before entering the toplevel.
It is also used to turn a file into an executable Prolog script
on Unix systems using the following first line
#!/usr/bin/swipl option ... -s
If you want to run this program, simply call the same command from your terminal:
swipl -q -g start -s g3

No such file or directory error in linux

Recently I have installed a program called "paradigm". In the program path (/home/hora/Paradigm/) there is a directory "testdata" (/home/hora/Paradigm/testdata) which includes a shell script that runs an example test of the application.The first time I installed the program I was able to run the shell script(runtests.sh) but now that I try to run it I get the error of " No such file or directory", although the files which is mentioned by the error are there. I am sure the problem is due to lack of my knowledge to linux and your help will be appreciated. To show the situation:
hora#serv:~/Paradigm/testdata$ ./runtests.sh
Testing node splitting [1/2], should take seconds
diff: needs_split_1.out: No such file or directory
./runtests.sh: line 6: ../pathwaytab2daifg: No such file or directory
But if I list the content of directory the mentioned files are there:
hora#serv:~/Paradigm/testdata$ ls
complex_family_pathway.tab needs_split_1.cfg needs_split_2.out runtests.sh small_disconnected_pathway.tab
complex_family_pathway.tab.out needs_split_1.out needs_split_2.pathway.tab
And then:
hora#serv:~/Paradigm$ ls
common.h configuration.o
evidencesource.o helperScripts makefile
pathwaytab2daifg.cpp pathwaytab.h test1 configuration.cpp
evidencesource.cpp externVars.cpp main.cpp paradigm
pathwaytab2daifg.o pathwaytab.o testdata configuration.h
evidencesource.h externVars.o main.o pathwaytab2daifg
pathwaytab.cpp README.mediawiki
This is the script content(the problematic part):
#!/bin/bash
set -o pipefail
cd
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
I believe the authors of this script want you to set HOME to ~/Paradigm, or they expect you to install directly in your HOME directory (~) rather than in ~/Paradigm. Either way, this is an error on their part. A simple fix may be to move the installation to ~, or try:
env HOME=$(pwd) ./runtests.sh
(Note that the env is not necessary unless you are running a csh family shell such as csh or tcsh). Setting HOME changes the behavior of cd when called with no arguments and makes the value of HOME the target directory.
This line:
#!/bin/bash
set -o pipefail
cd #<----- here!
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
is changing the directory to ~/, which is the default argument of cd if you don't pass a path to it (see here).
You could fix the script to work from anywhere if you like, by giving cd an absolute path i.e. changing that cd line to cd /home/hora/Paradigm/testdata.
I know this is a VERY old question BUT I think my answer is relevant for others that did not find their answer.
I've been using Linux on a home server since about 2000. Recently, I've upgraded a home server to 64-bit architecture (DELL R510 w/ 2 # Xeon).
I've been using a program (text2pdf.c) since my 32-bit kernel 2.4.32 days. I had forgotten to clean and re-make the executable file before installing it on the 64-bit system. Hence, I received the same error BUT not for the reasons stated in all the answers I've found online. 'which' and 'type' gave no clues BUT using 'file' gave me the info on the libraries that were linked at compile time and they were 2.4.32 libraries. Obviously, OLD 32-bit libraries on a 4.x 64-bit kernel didn't fly. Make clean, make (and make install) cleared the problem.
Peace and blessings,
JQ

Cygwin path to /cygdrive/C/Program Files (x86)/GnuWin32 directory?

I am having trouble executing a program located in the "C:\Program Files (x86) directory in Windows from within Cygwin. Anyone know the trick to getting this to work?
jboss#QA024 /cygdrive/C/jboss/EAP-6.0.1/jboss-eap-6.0/bin
$ wgetexe="/cygdrive/C/Program Files (x86)/GnuWin32/wget.exe --help"
jboss#QA024 /cygdrive/C/jboss/EAP-6.0.1/jboss-eap-6.0/bin
$ bash $wgetexe
bash: /cygdrive/C/Program: No such file or directory
jboss#QA024 /cygdrive/C/jboss/EAP-6.0.1/jboss-eap-6.0/bin
$ bash "$wgetexe"
bash: /cygdrive/C/Program Files (x86)/GnuWin32/wget.exe --help: No such file or directory
Try this:
wgetexe="/cygdrive/C/Program Files (x86)/GnuWin32/wget.exe"
"$wgetexe" --help
Since it's an executable, you don't want to pass it as an argument to bash, which will try to execute it as a script. Since it has spaces in the path name, you need to quote the name so the shell doesn't try to execute cygdrive/C/Program with invalid arguments.
You should also be able to add the directory to your $PATH:
PATH="$PATH:/cygdrive/C/Program Files (x86)/GnuWin32"
Keep in mind that GnuWin32 programs are Windows executables, and any file paths they use will be interpreted using Windows syntax. Cywin executables (anything that uses cygwin1.dll) use Cygwin path syntax.
Better yet, install the Cygwin version of wget and just invoke it as wget --help.
For example, if you're using the GnuWin32 wget, you might use:
wget -O "C:\cygwin\home\yourname\output-file" "$url"
whereas with the Cygwin wget you might use:
wget -O "/home/yourname/output-file" "$url"
I've always found it easiest to use Cygwin executables from Cygwin whenever possible.
Try this, it always worked or me.
wgetexe="/cygdrive/C/Program\ Files\ \(x86)/GnuWin32/wget.exe"
"$wgetexe" --help

Compilation issue with Sed 4.2.1

When I try to launch the ./configure command of Sed I get:
gawk: ./conf1dkaC9/subs.awk:3: fatal error: internal error
./config.status: line 1409: 7676 Done eval sed \"\$ac_sed_extra\" "$ac_file_inputs"
7677 Aborted (core dumped) | $AWK -f "$tmp/subs.awk" > $tmp/out
config.status: error: could not create bootstrap.sh
I'm actually following the LFS 7.1 book. Last night I stopped my work at the chapter dealing with Sed compilation and thus, I have shut down my PC. When I turned it on this morning, every ./configure command of every package failed and returned the message above. The same packages had no problems with ./configure before I shut down my PC. Any suggestion? Thanks
I had a similar problem with tmp files due to many files created in tmp. You can try to clean your /tmp directory.
It seems your gawk binary is broken. Try to reinstall it.
It looks as if an executable in the temporary tool chain is broken. As the user lfs has /tools/bin in its PATH before /usr/bin and /bin it uses that executable allready. To recover, try removing the broken executable from /tools/bin and repeat the step where it is installed.
My guess which executable is broken is sed, but it might also be gawk (as the previous answer suggests).

Makefile and symbolic links

I'm experiencing a strange problem with a makefile. I simply want to set a symbolic link in the makefile but get an error message on one machine (Linux 2.6.18-238.12.1.el5)
make: execvp: ln: Too many levels of symbolic links
It works perfectly fine on my MacBook. It also works fine if I execute the same command in the shell. What could go wrong? Are there any environment variables important for ln?
The execvp in the error message is the key, I think. I believe it is saying there are too many levels of symbolic links while trying to locate the ln command itself.
Example:
all:
ln -nsf /tmp/foo /tmp/foo
/tmp/foo/ln x y
Running "make" with this Makefile errors out with:
make: execvp: /tmp/foo/ln: Too many levels of symbolic links
So, how is your Makefile invoking ln, exactly? What is in your PATH etc.?
[update]
I bet the Makefile is messing up your PATH. Here is a Makefile that reproduces your exact error message:
PATH=/tmp/foo
all:
/bin/ln -nsf /tmp/foo /tmp/foo
ln x y

Resources