I am new to using make files. I have cygwin and MinGW. I'm still looking into their differences.
Anyway, I have a makefile that is used to create a project for an FPGA, which I have never done before. I have included C:\cygwin\bin and C:\MinGW\msys\1.0\bin in my PATH, but I always get this error.
make: pwd: Command not found
I typed pwd into the cmd prompt and get a correct response. Any pointers? Am I missing something? Not sure what else I can try. Most forums I have found pertaining to this error never have a resolution.
Let me know what information you'd like.
pwd is commonly both a shell built-in command and a standalone executable, provided by GNU coreutils (which Cygwin installs by default).
If you're invoking make from the Cygwin environment (say, typing make at a bash shell prompt), then C:\cygwin\bin is the wrong way to specify the directory. That's the path as seen from Windows. From within Cygwin, it's /bin -- and it should be in your default $PATH. The Cygwin equivalent of C:\MinGW\msys\1.0\bin would be /cygdrive/c/mingw/msys/1.0/bin
If you're doing this directly from Windows rather than in the Cygwin subsystem, then C:\cygwin\bin is the path to the Cygwin bin directory -- but running C:\cygwin\bin\pwd is going to give you a Cygwin-specific directory name that's not going to be meaningful to Windows.
I have encountered the same issue in my mingw environment. It turned out in my case to be a missing 'pwd'executable in the msys/bin directory. Once the copying was done properly, everything fell into place. Hope this helps
Related
I have installed gprbuild, xmlada, and gnatcoll. I am now attempting to install gnatcoll_postgres. Which I have downladed from here: https://github.com/AdaCore/gnatcoll-db/
Within the Postgres folder is a Makefile, which I execute like so...
[parallels#localhost postgres]$ ls
gnatcoll_postgres.gpr gnatcoll-sql-postgres-gnade.ads
gnatcoll-sql-postgres.adb gnatcoll-sql-ranges.adb
gnatcoll-sql-postgres.ads gnatcoll-sql-ranges.ads
gnatcoll-sql-postgres-builder.adb Makefile
gnatcoll-sql-postgres-builder.ads postgres_support.c
gnatcoll-sql-postgres-gnade.adb README.md
[parallels#localhost postgres]$ make Makefile
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
[parallels#localhost postgres]$
Would anybody please be able to tell me what this means...
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
Any help would be greatly appreciated.
Please see the xmlada and gnatcoll in my project below, does this look like it's installed correctly? I'm presuming this isn't correct...
Thanks,
Lloyd
It means that your GNAT installation binaries aren’t on your PATH.
The README.txt from the adacore.com site says, in part,
To start using the tools in command-line mode, you will need to add
{install_prefix}/bin
to your PATH environment variable. Alternatively, you can simply launch
{install_prefix}/bin/gps
and GPS will automatically add itself to the PATH - it will also find the
cross compiler, if you have installed everything in the default locations.
Note that GPS will add this at the end of the PATH, meaning that it will find first any other GNAT installations that you have in your PATH.
I strongly suspect that you’ve been doing the latter, so that GPS adds itself (actually, of course, its own location) to the PATH, so that when it launches the compiler it finds the correct one.
When you run make from the terminal, the compiler isn’t on the PATH, so neither are gnatls, gprconfig, gprbuild and the rest of the GNAT tools.
What you need to do is to take the first choice from the README, and add /home/parallel/opt/GNAT/2019/bin to (the front of) your default PATH. How you do that depends on your shell.
You will find xmlada, gnatcoll already installed.
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
I have a script file that I was given to run in windows using Cygwin. When I try to use this file I get the following error
-bash: /sigdet/filename: cannot execute binary file: Exec format error.
sigdet is the folder within the Cygwin directory that I have the script. Rawdata is the name of the directory with the raw data files that the script is supposed to analyze.
To try and solve this, I have changed the file permissions, I have checked to make sure that it is on a 64 bit machine and the script appears to have compiled on a 64-bit machine. After these steps, I don't know what else the problem could be. Here are the commands I've entered:
I first changed the directory like so:
$ cd /sigdet/
Then I ran the script that is suppsed to work:
$ /sigdet/filename -i rawdata
Does the script file need to have an extension in windows? I've tried changing it to a .sh extension with no luck. I'm told that it just works on other windows machines just how it is.
Thanks to anyone that can help with this.
Your file is not an executable. It most probably contains ELF executable which is designed for Linux operating system, or it's corrupt.
If your file was a shell script, or in fact anything that contained plain text, you'd get different errors (such as, "expected command name" or "unknown command: XYZ" etc.)
Scripts are not supposed to have file extensions, like any executables. On the other hand, they should have shebangs: small text located in the first line that tells the system the path to the interpreter. For example, a Python executable script might be named whatever and have #!/usr/bin/python3 or similar in the first line. When you run it through ./whatever in the shell, it'll look for python3 in /usr/bin and run your file like this: /usr/bin/python3 ./whatever. (In fact, thanks to this you can also specify additional parameters that get passed to the interpreter.)
There is also a chance that your script is valid, but it contains a shebang pointing to bad interpreter. If that is the case, then most likely the path is correct, otherwise you'd get /whatever/interpreter: bad interpreter: no such file or directory error or similar. But then, all the other points apply to the interpreter (which is just another executable...)
If the script and/or interpreter was meant to be executed on Windows or Cygwin at least, it should either contain aforementioned shebang (#!/path in the first name) or it should be Windows executable (in which case the file data should begin with MZ letters, you can inspect it in notepad.) If it isn't, it means the files you were given can't run on Cygwin.
Had this same problem. Added the following at the top of makefile:
export ARCH = CYGNUS
What happened during the make process is that Linux and Windows versions of the executables were created. You just have to use ./.exe versions.
In my case, I got the error when I used a wrong command to compile my C program. When I used the right command:
gcc myprog.c -o myprog.exe
the error was resolved.
recently, i try to compile a gnu wget from source code in cygwin environtment that pop-up error if perl is not found. otherwise, perl is installed both perl and perl5 on /bin/ but the wget is try search perl on /usr/bin. i think i have missed basic ./configure to setup path executable. so my question is basic.
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
*
Thank you
These options specify directories where a software package being compiled is going to be installed. As far as I remember it doesn't deal with checks performed by configure. Make sure that perl is in $PATH. If nothing helps, try to locate the exact place in the configure script (usually it's robot-generated and not intended for human eyes, but afterall it's a shell script, and anybody can read it) and see what checks exactly are performed to locate perl.
Update: I have checked, the tests corresponding to perl look like this in configure.ac (which essentially is a "source code" for configure):
AC_PATH_PROGS(PERL, [perl5 perl], no)
AC_PATH_PROG(POD2MAN, pod2man, no)
This means that PERL with executable named perl5 or perl (somewhere in $PATH) is checked, and then POD2MAN with executable pod2man. Carefully check the configure output and config.log file and see what tests have failed.
Update2: The third argument of the AC_PATH_PROG and AC_PATH_PROGS is value-if-no-found. Also you may specify the fourth argument, $PATH for this particular check. Make sure that configure gets rebuilt after you changed configure.ac (usually it happens automatically, but may be performed by autoconf explicitly)
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
The first (bindir), is where binaries will be installed. For wget, that's (on my system) /usr/bin.
The second (sbindir), is where static binaries will be installed. You might set that to /usr/sbin.
The third (libexecdir), is where your runtime libraries are to be installed. That's usually /usr/lib.
In fact, usually you let configure set all three by using --prefix.
./configure --prefix=/usr/local
I need to pass commands to cygwin, to do an rsync for a specific folder. How would I start rsync through cygwin? I'm aware of the .bat file method (as decribed here) but that's not really efficient for let's say multithreading and neither's it's neat.
If cygwin doesn't support this, are there any alternatives which do?
I just found out, in the cygwin directory (standard: C:\cygwin\bin\) there's a file rsync.exe (if installed through the cygwin installer). This can ran through the cmd with rsync's normal parameters.