I have dual boot windows - ubuntu on my laptop. I wanted to have a shared partition for my documents so I created a fat partition with my files and mounted it on ubuntu.
The problem is the following:
I tried to create a simple "helloworld" program in C language (I named the file test.c). When the file is in ~/Documents I can compile and run it as expected. When I move test.c in shared directory, a.out file is created but it is not executable. If I chmod +x ./a.out, then the output is ./a.out: command not found.
Any idea?
The possible reason may be c language is not platform independent. So code written in one os won't be accessible from other os. As the folder is shared by two os this problem may have raised.
Related
I am using Neon.3 Release (4.6.3) Eclipse IDE for C/C++ Developers under Ubuntu 15.5. When I build an run my C-program the program
the program executes without any errors/warnings
delivers the expected output in the eclipse-console
and generates an .exe file in the the debug folder
For me it is very much surprising that an .exe file is generated using an Linux OS (I thought these files can only be created under Windows?). How can I configure Eclipse to generate a typical Linux-executable instead?
Many thanks!
Extensions don't matter much in Linux. You can name an executable something.exe and it won't change how it runs...
I've installed Linux mint on usb as my hard drive got really slow. Now I want to compile and run C code. I successfully compiled it but as linux is in usb and I've to store program in one of my hard drive NTFS/FAT partitions so I'm getting bash permission denied error what should I do to run the code? I cannot store the program in usb(Linux partition)
Probably your problem is that the NFS/VFAT systems are mounted with the noexec flag or maybe the showexec flag. It instruct the kernel not to run any executable from these partitions (a security measure).
If it is showexec, then it is simply a matter of naming your executable with an .exe, .com or .bat extension (yes, even if it is a Linux executable, the vfat driver uses the extension to infer the executable permission bit).
If it is noexec, read on...
On older kernels you could bypass this with the /ld-*.so trick, but as man mount comments:
noexec: [...] (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
If my guess is correct, you have several options:
A. Remove the flag from the partition, with this command as root:
mount -o remount,exec <mount-point>
B. Find out why your partitions have this flag, which program does it (gnome-disks or whatever) and change it.
C. Compile your program to another partition, if not in the USB partition, then for example in a tmpfs:
mkdir exe
sudo mount -t tmpfs exe exe
And then, when you compile your program:
gcc test.c -o exe/test
But beware! A tmpfs is volatile and will disappear when you umount it or shut down the machine. You can make a permanent partition-in-a-file:
truncate -s 512M exe.img
mkfs.ext4 exe.img
mkdir exe
Then, to mount the image each time you boot the machine:
sudo mount -o loop exe.img exe
Copy the file to /tmp, set the execute permission, and you should be good to go, until you reboot and then you'll have to repeat it.
cp /path/to/wherever/myprogram /tmp/myprogram
chmod +x /tmp/myprogram
/tmp/myprogram
I Had same program this is what worked, for a console HELLO WORLD test on Debian Linux.
Simply compiled with syntax:
gcc hello.c -o hello.exe
Compiled in an instant and ran program at command line
via:. ./hello.exe
I have been working on some C code on a windows machine and now I am in the process of transferring it to a Linux computer where I do not have full privileges. In my code I link to several static libraries.
Is it correct that these libraries need to be re-made for a Linux computer?
The library in question is GSL-1.13 scientific library
Side question, does anyone have a pre-compiled version of the above for Linux?
I have tried using automake to compile the source on the Linux machine, but no makefile seems to be created and no error is output.
Thanks
Yes, you do need to compile any library again when you switch from Windows to GNU/Linux.
As for how to do that, you don't need automake to build GSL. You should read the file INSTALL that comes inside the tarball (the file gsl-1.16.tar.gz) very carefully. In a nutshell, you run the commands
$ ./configure
$ make
inside the directory that you unpacked from the tarball.
I just recently made the move to Linux, and now looking to program on it as well.
However, for some reason I cannot get an executable to work.
Here's what I've done:
Downloaded Code::Blocks
Made a new Console Project in Workspace 1 with C source.
Added a getchar() before return(0);
Ran and Compiled - Which works perfectly INSIDE Code::Blocks
Went to the bin/release folder in which the file is saved, tried double clicking, right clicking and selecting: open, open with, tried using terminal to run the name of my program. I copied the folder URL, and then name of the file.. I just can't seem to get the created file to execute!
In windows it made a .exe, I know there is no ending (?) in linux. (Could be wrong).
I'm currently running Ubuntu 11.04.
Most Linux distributions don't include the current directory in the PATH variable that determines where to search for executables. Try opening a terminal, changing to the bin/release directory and explicitly qualifying your executable for the current directory:
./myprogram
This is in contrast to Windows, where you can simply type "myprogram.exe".
You might need to grant your program permission to run as an executable:
sudo chmod +x yourProgram
In the terminal emulator, go to (cd) the folder where the executable is created.
Type ./programname
Where programname is the name of the executable file
(./ tells the shell to look in the current directory for the program to run)
Consider this scenario in which an executable A.bin uses libY.so and libZ.so. A.c, Y.c and Z.c are all written in C.
Z.c and Y.c are compiled into respective .so files.
This is the directory structure of the files
$home/bin/A.bin
$home/lib/libY.so
$home/lib/libZ.so
When I run A.bin as normal user, A.bin runs normally as expected.
Note: $LD_LIBRARY_PATH contains $home/lib
I changed some code in A.c adding some functionality which needs admin privileges(like binding to a port less than 1000).
I set the setuid bit for A.bin, libY.so and libZ.so to rwsrwsrws, and change the ownership of the files to root. When I try to run A.bin, I get the following error
ld.so.1: A.bin: fatal: libY.so: open failed: No such file or directory
Killed
When I just remove the setuid permission from all those files, then the binary runs except for the functionality fails where it needs root privileges.
How to overcome this problem ?
Edit: The OS is Solaris 5.10
As AProgrammer said, while executing setuid programs, $LD_LIBRARY_PATH is ignored. Hence the path has to be hardcoded in the executable itself using this flag while linking
gcc -R $home/lib
The -R flag builds runtime search path list into executable.
In some Unix variants, suid executables have some security features like ignoring LD_LIBRARY_PATH, checking ownership and access rights on the executable and used shared libraries,... I don't remember the case of Solaris, but you should probably check that.