I recently updated to the most recent version of Cygwin (1.7.23), and what used to be a functional 'arm-elf-gcc' compiler seems to now be broken. In particular, no matter what input I supply the command, it complains that there are no input files:
$ arm-elf-gcc foo.c
arm-elf-gcc: no input files
$ arm-elf-gcc --help
arm-elf-gcc: no input files
$ arm-elf-gcc -v
arm-elf-gcc: no input files
Any ideas or suggestions as to why this could be happening? A Google search for 'arm-elf-gcc no input files' reveals little as to the cause. Thanks!
As TurboJ mentioned in the comments to the original question, there were two conflicting versions of the cygwin1.dll. The folder that contained the arm-elf-gcc executable also contained a cygwin1.dll, which clashed with the one from the 'bin' subdirectory of Cygwin. I merely replaced the former with the latter.
As Jon Kother says, If you Installed Gnu arm and checked install cygwin.dll and cygwin 32 version,this problem will happen
so just go to your X:/gunarm/bin/ and rename cygwin.dll to cynwin.dll.bak,And everything will to alright
Related
I am trying to run one of the example from Beej's Guide to Network Programming (https://beej.us/guide/bgnet/), specifically showip.c (The link to the program is here: https://beej.us/guide/bgnet/examples/showip.c). Using gcc, I've typed in
gcc -o showip showip.c
Then ran the program
showip www.example.net
and I get an error showip: command not found on the same directory where the code and the program is compiled at. I'm not sure why this is the case. I've even cloned the code from his GitHub and used makefile to compile the program and yet I'm getting the same error. What exactly am I doing it wrong here?
This is actually problem with how you're running the program.
On Linux systems (unlike Windows systems) an executable in the current directory is not by default searched by the shell for programs to run. If the given program does not contain a path element (i.e. there are no / characters in the name) then only the directories listed in the PATH environment variable are searched.
Since the current directory is not part of your PATH, prefix the command with the directory:
./showip www.example.net
Is the working directory on your path? Likely not.
Try ./showip
Since the program showip is not in your $PATH you have to tell
your shell that it's in the current directory:
./showip
Or add the current directory to your $PATH but it's a less secure
option:
PATH=:$PATH
or
PATH=.:$PATH
and run it as you're trying now:
showip
I have a couple of libraries built by the NDK for which I am trying to view the exported symbols, the available function names to be precise. One is a .so file and the other a .a file. I was helped in this question (How to obtain readelf and objdump binaries for OS X?) to find the utilities that I think I need. They are specific to the NDK installation. I am on OS X fyi.
In my NDK installation I found nm and objdump in prebuilt/darwin-x86_64/arm-linux-androideabi/bin. Their file type is "Alias". When I ran nm -g libMylib.so nothing happened -- at all. When I ran objdump -TC libMylib.so I got: "objdump: command not found". Then I found the arm-linux-androideabi-nm and arm-linux-androideabi-objdump files (file type listed as "Unix Executable File" in Finder) in the prebuilt/darwin-x86_64/bin dir. The attempt to use both of them resulted in "command not found". In all these attempts I placed libMylib.so right in the very folder with the utility I'm trying to run.
I think this is basically a general issue about how to call binaries in unix; even if you are in the same directory when you run nm -g libMylib.so, since . normally isn't part of your $PATH. To run the right one, do ./nm -g libMylib.so, or without using cd to enter this directory first, just do path/to/your/NDK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -g libMylib.so, or add this directory to your path first:
export PATH=path/to/your/NDK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin:$PATH
arm-linux-androideabi-nm -g libMylib.so
(It's preferrable to add this directory to the path instead of the arm-linux-androideabi directory, since it is clear which tool you want to invoke when you call when you do arm-linux-androideabi-nm, while if you add the other directory and call nm, it is up to the order of the directories in $PATH.)
See e.g. Why do you need ./ (dot-slash) before script name to run it in bash? for more explanations about $PATH.
I'm a bit of a noob at working with compilers. I want to add an arbitrary directory on my win 8 C:\ drive to the Cygwin gcc default search path.
Here is what I have tried so far. Using gcc --help I found the commands -print-search-dirs and -B <directory> ("add directory to the compiler's search path").
Using the former command output this:
install: /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/
programs: =/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/:/usr/lib/gcc/x86_64-pc-cygwin/4.
9.2/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/:/usr/li
b/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-p
c-cygwin/bin/x86_64-pc-cygwin/4.9.2/:/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../.
./../x86_64-pc-cygwin/bin/
libraries: =/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/:/usr/lib/gcc/x86_64-pc-cygwin/4
.9.2/../../../../x86_64-pc-cygwin/lib/x86_64-pc-cygwin/4.9.2/:/usr/lib/gcc/x86_6
4-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/lib/../lib/:/usr/lib/gcc/x86_64-p
c-cygwin/4.9.2/../../../x86_64-pc-cygwin/4.9.2/:/usr/lib/gcc/x86_64-pc-cygwin/4.
9.2/../../../../lib/:/lib/x86_64-pc-cygwin/4.9.2/:/lib/../lib/:/usr/lib/x86_64-p
c-cygwin/4.9.2/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../..
/x86_64-pc-cygwin/lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../:/lib/:/usr/
lib/
The full path to /usr is C:\cygwin64\usr. The directory I want to add is c:\directory So I tried gcc -B /../directory and other variations, but I get error
gcc: fatal error: no input files
compilation terminated
Seems like it thinks I'm trying to compile something. I want to permanently add a directory to the list of default search paths.
There are two issues at play here.
The first problem has to do with the fact that Cygwin views the top of its directory tree / to be within the Windows directory C:\cygwin64. As a result, you are unable to move above that point in the filesystem. The solution is to go through Cygwin's directory /cygdrive, which is the access point where all Windows disk drives are mounted. You can access the top-level Windows directory C:\ from Cygwin as /cygdrive/c. So for the problem above, instead of using gcc -B /../directory, try using gcc -B /cygdrive/c/directory.
The second issue is that of adding directories to the search path, versus telling it to compile a specific source file. Given the date of this question, I assume you've solved that part of the problem at this point?
Download source files from official OpenSSL site. I follow the INSTALL.M32 file in OpenSSL folder. I open msys.bat, go to the OpenSSL folder, then type
$ ./config
It says "Configured for MinGW", than I type
$ make
and after few minutes receive error:
md2test.c:1:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
I simply opened the files that were causing the error (/test/"md5test.c; rc5test.c; jpaketest.c") and replaced the line
dummytest.c
to
#include "dummytest.c"
It's the same solution as stated above, except it's a bit faster...
The problem is that md2test.c is actually a symbolic link, or symlink to dummytest.c.
If you extracted openssl-1.0.1c.tar.gz with anything other than
tar xf openssl-1.0.1c.tar.gz
then these symlinks were not preserved. On Cygwin it works after that; not sure about MinGW.
In my case the problem was that few test files (3 as far as I remember) had instead of C++-code the name of file (something like dummitest.c). I copy-paste the right code to that files from files from other folder, but with the same name, and everything went fine.
What program did you use to decompress 'openssl-1.0.0x.tar.gz'? 7-zip is a great program, but it seems there's a bug.
Use tar or other decompressor such as BreadZip.
tar zvxf openssl-1.0.0x.tar.gz
It's the same solution as stated above, except it's a bit faster... :)
The problem is a symbolic link in the archive that MinGW/MSYS does not seem to understand.
You can work around it by using the --derefence (-h) option when extracting.
For example tar -xzvfh archive.tar.gz
from http://www.gnu.org/software/tar/manual/html_node/dereference.html:
When reading from an archive, the --dereference' (-h') option causes tar to follow an already-existing symbolic link when tar writes or reads a file named in the archive.
I am having the same problem.
As the problem is while building the tests, I just did not make them:
make Makefile openssl.pc libssl.pc libcrypto.pc build_libs build_apps build_tools
Is a horrible solution but it seems to work. You get the libraries and the tools, but not the test suite.
I hope someone gives a better answer and/or fixes the problem with the code if there is any.
Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)