I am trying to install GNU m4 package on Bash on Ubuntu on Windows 10, but always fail at configuration stage.
I wrote these:
wget ftp://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz
tar xvzf m4-1.4.17.tar.gz
cd m4-1.4.17
./configure --prefix=/usr/local/m4
However, the configuration process stopped at this stage:
checking whether rename honors trailing slash on source...
I had waited for more than 8 hours with no progress. I tried to restart my PC and repeated similar steps, but the trouble remains.
I found a similar question here, but I want to explain a bit more details about my own trouble.
I would appreciate any suggestion. Thanks.
This is caused by a bug in Bash on Windows. As a workaround, try building m4 from a Linux directory instead of a Windows one (i.e., build it in /home/$USER/ instead of a subdirectory of /mnt/c).
Related
I'm using cygwin installed on Windows 10 and trying to access awscli from it.
I used pip install awscli to install awscli. This installed awscli. I then tried to run only aws to see if it is installed and I get the following error:
-bash: /cygdrive/c/Program Files/Anaconda2/Scripts/aws: C:\Program: bad interpreter: No such file or directory
I'm not sure why this is happening. Any help in this regard would be highly apreciated.
This is still an issue even with the latest version of AWS cli. So after some trial and error I found a pretty good workaround that will not make you switch your favorite shell.
First, make sure python is on your PATH. That is from anywhere in the system you can just run python and it work.
Find the aws script and open it for editing (for me it was located in c:\Program Files\Python36\Scripts\aws) and change the hashbang (that would be the first line in the script) to #!python.exe. For me it was set to #!c:\Program Files\Python36\python.exe. That space in the middle of Program Files caused the issue when that path got converted to Linux like path. Changing it to #!python.exe sidesteps the issue.
When you update AWS cli, repeat the workaround.
PS. You could also avoid this issue by installing python somewhere in a folder without spaces in path. That requires to reconfigure your system, so I did not do that myself.
I would install the standard python and ensure it is coming up first in your path with which python and which pip. Path issues like this are due to mixing and matching executables targeting different platforms in my experience. Certain commands do not implement functionality to convert paths from Windows to Linux and back (it appears your specific commands are failing on spaces).
Since you say you are on Windows 10, if you have the anniversary edition, I would recommend Windows Subsystem for Linux over cygwin. You will likely see less Windows issues on WSL since it uses the exact same ubuntu packages you would use on Linux instead of the cygwin port and maps them low level to the NT Kernel.
The Problem comes from "Program Files" having a space. This is something that is related to cygwin (I encountered the same error with git bash on windows). In a script I had something like this:
#!/c/Program Files/some_program/executable.exe
Escaping the space with a backslash or using quotes didn't work.
The solution is to use the DOS' short filename:
Progra~1 for "Program Files"
Progra~2 for "Program Files (x86)"
So my line would turn into:
#!/c/Progra~1/some_program/executable.exe
In Windows:
cd .. to go to home directory which shows pwd as /.
Now, cd to /cygdrive/c/Program\ Files/Anaconda2/Scripts
Now, run: python aws configure
Example:
user#user /cygdrive/c/Program Files/Anaconda2/Scripts
$python aws configure
I am attempting to install SWI-Prolog on a server running rhel 7.
I have followed the instructions to build SWI-Prolog here: http://www.swi-prolog.org/build/Redhat.html. The build completes without error; however, I see no trace of the application.
In addition, the application does not seem accessible because I am unable to invoke swipl to begin executing Prolog commands.
I'm on Fedora 24, so probably close to your RHEL 7 situation. I never build the RPM, I simply build from sources:
git clone https://github.com/SWI-Prolog/swipl-devel
cd swipl-devel
cp build.tmpl build
<EDITOR> build <TO CUSTOMIZE>
./build
In the customization step you can set a specific directory on your system. That way you're 100% sure where it ends up.
I followed SWIPL build instructions on my CentOS 7.6.1810.
I faced two issues when configuring using cmake as per instructions
cmake ..
First, I had to install cmake3
yum install cmake3
and had to invoke it thus:
cmake3 ..
Secondly, cmake had trouble setting X11_Xpm_LIB. So I manually set the line in CMakeCache.txt
X11_Xpm_LIB:FILEPATH=/usr/lib64/libXpm.so.4
After this the config process completed successfully.
But my build is failing :(
I am trying to setup some old version of Cygwin on my Windows 7 x64 OS. So far so good. Now I am stuck at srdout/stderr distinction problem:
$ vmake
1 [main] make 7060 dtable::stdio_init: couldn't make stderr distinct from stdout
$ ls /
1 [main] ls 8180 dtable::stdio_init: couldn't make stderr distinct from stdout
Cygwin.bat Cygwin.ico bin cygdrive etc lib proc setup.log setup.log.full tmp usr var
I am running:
$ uname -srv
1 [main] uname 5876 dtable::stdio_init: couldn't make stderr distinct from stdout
CYGWIN_NT-6.1-WOW64 1.5.25(0.156/4/2) 2008-06-12 19:34
The Cygwin installation had DOS line-endings option selected (for some legacy code compatibility).
To fix another issues with line endings (bash had troubles processing /cygdrive/c/cygwin-legacy/bin/vmake script, like issue described here: http://chess.eecs.berkeley.edu/softdevel/faq/5.html ) I've added these to ~/.bash_profile:
export SHELLOPTS
set -o igncr
After reading http://lists-archives.com/cygwin/50369-run-requires-cygwin-tty.html I also set:
$ CYGWIN=tty
This changed nothing. I am still getting
1 [main] make 7060 dtable::stdio_init: couldn't make stderr distinct from stdout
with different 4-digit number each time.
I have had the same problem here.
Then I remembered, that we replaced the "make" command
by an MSYS-Version (since the 'make' of the new
cygwin package did not handle any pathes with colons (":")
-> this lead to "multiple target" errors.
The replacement of the 'make' command solved this problem,
but caused "stdio_init: couldn't make stderr distinct from stdout"
when I was trying to compile other projects.
Therefore:
Do you have MSYS/MinGW installed on your machine, too ?
Try this:
make --version
it should look like:
GNU Make 3.82.90
Built for i686-pc-cygwin
if you get something like:
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
You need to use the cygwin 'make' instead.
Perhaps this error occurs if you mix up the components of different cygwin versions...
A little note for people having this issue with other binaries like ssh. I had this error since cygwin was trying to run windows ssh client instead of the version in cygwin
Check that the executable is a cygwin version
I got this error when trying to launch a Msys executable from within cygwin. Msys is another 'linux on windows' environment and is incompatible with cygwin.
Specifically, I was trying to launch Git for Windows via a symlink in my /bin path. I apparently had installed it ages ago and created the symlink then, and didn't notice any problems until I tried to use git gui which then threw the couldn't make stderr distinct from stdout error. Interestingly, many of the git commands to work, or fail silently so it wasn't immediately noticable.
When cygwin tries to launch a program intended for the Msys environment, it throws the error.
To fix it, download the cygwin version of the problem app, and remove any symlinks you have in place that are pointing to the Windows version.
For the Git case :
I deleted /bin/git symlink
re-ran cygwin setup and installed git (cygwin version)
This helped me:
Try a Cygwin 1.7 beta test release instead:
http://cygwin.com/#beta-test
Cygwin 1.5.25 is not really supported on Windows 7. Only Cygwin 1.7
gets tested on it.
Removing C:\DevKit\bin from my path made the problem go away for me.
As part of a long, sordid story whose end goal is simply to get GMP installed for use with code::blocks in Windows, I am trying to configure gmp. I do this with the following command:
./configure --prefix=${gmp_install}
Everything starts out well enough. After a few minutes and a bit of progress, everything grinds to a halt and I get this message:
configure: error: No usable M4 in $PATH or /usr5bin
I don't even know what M4 is, but I discover that it is some sort of macro processor. So I download it, and add the folder to my Path variable. Then I start the configure again, but same result.
Is there something that I need to do to M4 to get it working? I'm truly at a loss. Thanks for your help.
If you're using debian based OS, do sudo apt-get install m4. If internet isn't there or you have just the package of m4, copy it in /opt, configure it and later on change the $PATH value to the one you have now.
If you are using cygwin, the setup installer has a working package of m4. Then there's no need to download m4 or change $PATH.
I came up with your same problem, I solved it by running the Mingw package installer, and search for msys-m4 in the list, select all and then Apply Changes, it should let you ./configure just fine :)
Assuming you are on MSYS2 (You seem to have a sh), you can install m4 via pacman -S m4.
Be careful that if you run configure through a shell, that you don't pick WSL's bash accidentally (which is in %System32%/bash.exe). Which is what happened in our build system...
Hi i downloaded souce for unix version 6, i want to study it and test it. I am running Snow Leopard on a macbook pro.
1)Is there a way to compile it in mac. If i comile using make or gmake i am getting the following error.
*** Error: Couldn't find an i386-*-elf version of GCC/binutils.
*** Is the directory with i386-jos-elf-gcc in your PATH?
*** If your i386-*-elf toolchain is installed with a command
*** prefix other than 'i386-jos-elf-', set your GCCPREFIX
*** environment variable to that prefix and run 'make' again.
*** To turn off this error, run 'gmake GCCPREFIX= ...'.
2)I also want to run it in a virtual machine,I have VMWare installed on my machine. I don't know how to do that.
Download tarballs for gcc and binutils, expand them, then:
$ cd binutils-2.15
$ ./configure --target=i386-jos-elf
$ make
$ make install
$ cd ../gcc-3.4.1
$ ./configure --target=i386-jos-elf
$ make
$ make install
You will of course need to update the paths. (I got these instructions from MIT's OpenCourseWare.)
You'll have to go through the process of creating a new virtual machine and formatting and installing the OS onto its disk. I've used VirtualBox with some success, but I have no experience with VMWare; you're on your own there.
You might look into macports.org. It has several packages that look useful, notably "i386-elf-binutils". It installs into /opt/local/*, so you may need to make sure /opt/local/bin/ is in your path. (Although I believe it takes care of that by default.)
EDIT: Or maybe not. After a little more research, I wonder if these instructions and downloads are what you're looking for.
EDIT again: Corrected the download link. Sorry about that!
The build system you are using seems to require an ELF tool chain (used by Linux).
You could try to figure out if that can be changed, but since you have VMWare, try to compile it under a virtualized Linux (minimal Debian is quite light-weight).
As an alternative you may compile bournesh on Mac OS X.
http://freshmeat.net/projects/bournesh/