Can't use "/usr/bin/env" in C execve() call on macOS - c

I couldn't really find any relevant results after looking for a while, so I'm asking this myself. I have the following C code, which tries to execute nasm through execve() via /usr/bin/env so I don't have to hardcode the path to the executable.
#include <unistd.h>
int main(int argc, char**argv) {
char *cmds[10] = {"/usr/bin/env", "nasm", "--version", NULL};
execve(cmds[0], cmds, NULL);
}
On linux (Ubuntu 18/20), it works fine:
linux $ gcc test.c && ./a.out
NASM version 2.13.02
linux $
However, on macOS (Catalina, at least), I get the following:
macos $ gcc test.c && ./a.out
env: nasm: No such file or directory
macos $
I'm not exactly sure what the difference is. I do have NASM installed, I can run nasm --version on my terminal just fine. It also works fine if I hardcode the path /usr/local/bin/nasm to the execve() call. If I try to run the following manually on my terminal, it also seems to work:
macos $ /usr/bin/env nasm --version
NASM version 2.15.05 compiled on Aug 29 2020
macos $
The reason I want to use /usr/bin/env is that the default install location for nasm is different for different OSs, and I don't want to just hardcode the paths.

The problem is that you use execve.
The e suffix means you pass an environment to the exec system call, but the environment you pass is NULL. Which means no environment at all.
Use execv instead to use the same environment as the calling program.

Related

How to compile C program

I am learning C and I have a simple hello world program that I am trying to run on Windows 10. Here is the code:
#include <stdio.h>
int main() {
printf("Hello, world!\n");
return 0;
}
I have installed GCC compiler and I tried the following in order to run it in the command prompt:
gcc hello.c
a
I also tried:
gcc hello.c
./a.exe
and:
gcc hello.c
./a
and:
gcc hello.c -o hello
./hello
The program does not run displaying hello, world and it gives the following error:
bash: a.exe: command not found
What am I doing wrong and how can I run the program after the compilation?
It appears that your compilation succeeded successfully.
See if there is an a.out or a.exe file present, as you didn't indicate a non-default executable name.
Note that running a alone typically won't do anything, because it is highly unlikely that your executable is on the bash PATH. This means you need to run ./a.out or ./a (depending on base operating system).
Binary executables under windows typically must have .exe extension to be recognized as such.
I am not sure if gcc under windows adds the right extension automaticaly when outputting executables.
I would try:
gcc hello.c -o hello.exe
./hello.exe

MSYS make.exe command won't do anything ("Nothing to be done for...")

Ok, hello everyone.
I searched a lot to see if I could find an answer to my question, but I couldn't.
I installed the latest versions of MinGW and MSYS on Windows 10.
I created a very simple C file, based on Zed Shaw's guide (Learn C the hard way), which looks like this:
#include <stdio.h>
int main(int argc, char *argv[])
{
int distance = 666;
printf("You are %d miles away. \n", distance);
return 0;
}
Now, according to Shaw's guide, I should be able to compile the file just by using the following command:
make .\es1.c
And it should automatically recognise that I'm compiling a C source file and use some default options, like "-o es1", even without a makefile.
The problem is that when I try to compile it using MSYS's make, I get this:
make.exe": Nothing to be done for `.\es1.c'.
And I can't make it compile in any way.
If I call directly the gcc compiler, in this way:
gcc .\es1.c -o es1
It works.
What I am I doing wrong?
Thank you everybody.
You need to supply the target (what is to be built) to the make command, not the dependencies of the build. The make tool will always consider non-generated source file as up-to-date because, by definition, there is nothing from which they can be built.
In your case, try this:
make es1.exe
(I assume you are on Windows and your makefile is set up to create the target with an .exe extension.)
The problem maybe is with the schizophrenic interaction of Unix build tools and Windows program execution:
user#dogbert ~/foo
$ echo "int main() { return 0; }" > foo.c
user#dogbert ~/foo
$ cat foo.c
int main() { return 0; }
So far so good. Now make it - no makefile needed.
user#dogbert ~/foo
$ make foo
cc foo.c -o foo
Although the target was named foo, foo.exe was made.
user#dogbert ~/foo
$ ls
foo.c foo.exe
user#dogbert ~/foo
$ ./foo
user#dogbert ~/foo
$ ./foo.exe
It seems that foo and foo.exe are synonyms on cygwin.
user#dogbert ~/foo
$ make foo
make: foo is up to date
user#dogbert ~/foo
$

How can I run a C program on Mac OS X using Terminal?

I am new to C. Here is my "Hello, World!" program.
#include <stdio.h>
int main(void)
{
printf("Hello, World!\n");
return 0;
}
After I try to run it using Terminal it says:
/Users/macbook/Desktop/peng/Untitled1
-bash: /Users/macbook/Desktop/peng/Untitled1: Permission denied
Why?
First save your program as program.c.
Now you need the compiler, so you need to go to App Store and install Xcode which is Apple's compiler and development tools. How can you find App Store? Do a "Spotlight Search" by typing ⌘Space and start typing App Store and hit Enter when it guesses correctly.
App Store looks like this:
Xcode looks like this on App Store:
Then you need to install the command-line tools in Terminal. How can you start Terminal? You need to do another "Spotlight Search", which means you type ⌘Space and start typing Terminal and hit Enter when it guesses Terminal.
Now install the command-line tools like this:
xcode-select --install
Then you can compile your code with by simply running gcc as in the next line without having to fire up the big, ugly software development GUI called Xcode:
gcc -Wall -o program program.c
Note: On newer versions of OS X, you would use clang instead of gcc, like this:
clang program.c -o program
Then you can run it with:
./program
Hello, World!
If your program is C++, you'll probably want to use one of these commands:
clang++ -o program program.cpp
g++ -std=c++11 -o program program.cpp
g++-7 -std=c++11 -o program program.cpp
First make sure you correct your program:
#include <stdio.h>
int main(void) {
printf("Hello, World!\n"); //printf instead of pintf
return 0;
}
Save the file as HelloWorld.c and type in the terminal:
gcc -o HelloWorld HelloWorld.c
Afterwards, just run the executable like this:
./HelloWorld
You should be seeing Hello, World!
A "C-program" is not supposed to be run. It is meant to be compiled into an "executable" program which then can be run from your terminal. You need a compiler for that.
Oh, and the answer to your last question ("Why?") is that the file you are trying to execute doesn't have the executable rights set (which a compiler usually does automatically with the binary, which let's infer that you were trying to run the source code as a script, hence the hint at compiling.)
This is Working in 2019
By default, you can compile your name.c using the terminal:
cc name.c
And if you need to run, just write
./name.out
To do this:
Open the terminal
Type in the terminal: nano ; which is a text editor available for the terminal. When you do this, something like this would appear.
Here you can type in your C program
Type in Ctrl + X → which means to exit.
save the file by typing in Y to save the file
Type the file name; e.g., helloStack.c (don't forget to add .c)
When this appears, type in gcc helloStack.c
And then ./a.out: this should give you your result!
For compiling a C program on your latest macOS, just type the following in the terminal after saving the file with a .c extension and on reaching the path where the file is saved:
cc yourfilename.c
Once you have checked all the errors after compilation (if any), type the following for executing the code:
./a.out
These commands are tested on macOS v10.14 (Mojave) and are working perfectly fine.
To compile a C program in macOS, simply follow the below steps
Using the cd command in terminal, go to your C program location and then type the command present below:
make filename
then type
./filename
The answer is chmod 755 hello - it makes the file executable... I had same problem on macOS, which is now solved.
nano hello.c
make hello
chmod 755 hello
Then you run it by ./hello
clang --version
Output:
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Nothing was installed. nano make (clang) chmod - all inside macOS already.
On Mac, GCC (executable gcc) is installed by default in /usr/local/bin.
To run C:
gcc -o tutor tutor.c
First you need to install a GCC compiler for Mac (google it and install it from the Internet)
Remember the path where you are storing the C file
Go to Terminal and set the path
E.g., if you have saved in a new folder ProgramC in the Document folder.
Then type this in Terminal:
cd Document
cd ProgramC
Now you can see that you are in folder where you have saved your C program (let you saved your program as Hello.c)
Now compile your program
make Hello
./hello

The output of GCC

I have GCC running on my Ubuntu operating system. I wrote a small program in C and tried compiling it. Its output was an a.out file like it would do on Windows. How can I make it put out a Linux executable?
a.out is the executable (assuming you've done full compilation rather than just generation of object files but that's the most likely case). To run it, use (from a shell):
./a.out
If you want to give it a different name, simply rename it, or better:
gcc -o actualname myprog.c
to get an executable called actualname which is then run (of course) with:
./actualname
See the following transcript:
pax> cat testprog.c
#include <stdio.h>
int main (void) { printf("Hi.\n\n"); return 0; }
pax> gcc testprog.c ; ./a.out
Hi.
pax> gcc -o xyzzy testprog.c ; ./xyzzy
Hi.
Suppose your C file is f.c.
gcc f.c gives the a.out executable, and you can run it in a terminal as ./a.out.
gcc f.c -o myprog gives myprog as the executable, and you can run it in a terminal as ./myprog.
It is a Linux executable. a.out files (actual a.out format, not files named a.out by default) cannot be executed on Windows.
In both cases, most likely you get a standard executable usable in the local system, but named a.out. On Linux it's an ELF file.

How to solve "error while loading shared libraries" when trying to run an arm binary with qemu-arm?

I'm running Linux Mint 14 with qemu, qemu-user, and the gnueabi toolchain installed. I compiled test.c with arm-linux-gnueabi-gcc test.c -o test.
When I try and run qemu-arm /usr/arm-linux-gnueabi/lib/ld-linux.so.3 test
I get an error saying: test: error while loading shared libraries: test: cannot open shared object file: No such file or directory. Running qemu-arm test, as I've previously tried, gives /lib/ld-linux.so.3: No such file or directory
However, the file does exist and is reachable.
$ stat /usr/arm-linux-gnueabi/lib/ld-linux.so.3
File: `/usr/arm-linux-gnueabi/lib/ld-linux.so.3' -> `ld-2.15.so'
Size: 10 Blocks: 0 IO Block: 4096 symbolic link
Device: 801h/2049d Inode: 4083308 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-04-22 16:19:48.090613901 -0700
Modify: 2012-09-21 08:31:29.000000000 -0700
Change: 2013-04-22 15:58:41.042542851 -0700
Birth: -
Does anyone know how I can make qemu run an arm program without having to emulate an entire arm Linux kernel?
test.c is
#include <stdio.h>
int main() {
printf("this had better work\n");
}
and file test is
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0xf2e49db65394b77c77ee5b65b83c0cc9220cbfc0, not stripped
you can run the example by providing a path to the arm-linux-gnueabi shared libs using the -L flag.
qemu-arm -L /usr/arm-linux-gnueabi/
also make sure the LD_LIBRARY_PATH is not set.
unset LD_LIBRARY_PATH
$ export QEMU_LD_PREFIX=/usr/arm-linux-gnueabi
This works for me.
It's basically the same thing as:
$ qemu-arm -L /usr/arm-linux-gnueabi/
You can add it to the ~/.bashrc file so you don't have to type it everytime you open the terminal.
I also met this problem when running a C program with assembly code. My solution is to build the executable with the option "-static", for instance
arm-linux-gnueabi-gcc -static -g main.c square.s
Then
qemu-arm a.out
will not report the error saying "can not find the /lib/ld-linux.so.3".
The only drawback is that the executable could be with a large size. But it's helpful when you just want to test your code.
Of course, you can go with the method from Balau(see artless noise's answer). But if you don't want to feel frustrated by something like "UART serial ports" in this step, which is only to run a simple "test" function, go for a try of my fix.
I solved the problem by copying the following libraries into /lib but I believe there should be a way better solution rather than this nasty solution I invented!
sudo cp /usr/arm-linux-gnueabi/lib/ld-linux.so.3 /lib
sudo cp /usr/arm-linux-gnueabi/lib/libgcc_s.so.1 /lib
sudo cp /usr/arm-linux-gnueabi/lib/libc.so.6 /lib
Please let me know if there are other better solutions as I am interested to know.
If you want to run ARM without Linux, then you need a different compiler (at least). arm-linux-gnueabi-gcc is a compiler for Linux. The compiler and libc are intimately linked. You will need a newlib compiler with a portability layer for qemu.porting newlib
See: Balau and Google newlib+qemu. A newlib port is hosted at Github and seems to the same as the Balau blog.
Typically a non-Linux gcc is called arm-none-eabi-gcc. The prefix arm-none-eabi- is recognized by some configure scripts.
A variant, which worked for me, was to pass the loader library directly and to specify the required library paths using the loader parameter --library-path. For example:
$ TOOLCHAIN_ROOT=/usr/local/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/arm-linux-gnueabihf
$ qemu-arm $TOOLCHAIN_ROOT/libc/lib/ld-linux-armhf.so.3 --library-path $TOOLCHAIN_ROOT/libc/lib/arm-linux-gnueabihf:/$TOOLCHAIN_ROOT/lib ./my_executable
Or equivalently export LD_LIBRARY_PATH instead of using --library-path.

Resources