0

(the warning that shows up) On Ubuntu 18.04, I compiled a c++ sample which only included stdio.h and an empty main function using g++ test.cpp -o test .

No errors popped up and I had no issues running it from the terminal.

However, once I go on nautilus and try to run it by clicking on test, a warning pops up, asking me to pick a program to open the shared library.

How do I make sure the program is compiled as an executable/ is seen as an executable by the file manager?

Edit: stat output on the executable (recompiled and changed the name to asdff):

File: asdff
  Size: 10600       Blocks: 24         IO Block: 4096   regular file
Device: 808h/2056d  Inode: 4200517     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  miguel)   Gid: ( 1000/  miguel)
Access: 2018-05-18 15:22:58.009993285 +0100
Modify: 2018-05-18 15:22:58.009993285 +0100
Change: 2018-05-18 15:22:58.009993285 +0100
Birth: -

df output on the same executable:


Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda8      128206036 102694048  18956444  85% /

desktop entry:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=asdff
Exec=./home/miguel/Desktop/asdff
Icon=/home/miguel/Desktop/index.png
Mynlok
  • 11
  • 1
  • 2

3 Answers3

3

I notice that you were trying to use a desktop file. That is good.

Because Nautilus is patched to remove the ability to execute programs. It's a security problem.

Put your desktop file in the right location for the application launcher and open it that way instead of by using Nautilus. This location is $HOME/.local/share/applications, I believe.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
1

This answer assumes your test program lies on your home folder and that /home has its own partition, with the noexec option (this is the default on Ubuntu).

man mount says:

noexec Do not permit direct execution of any binaries on the mounted filesystem.

This means your system prevents you from running your test program on your home folder.

If this is true, you can either move your program outside of /home or change the way your home partition is mounted by editing your /etc/fstab file. See man fstab, but basically you want to add the exec option.


Other hypothesis:

  1. For whatever reason, your test program does not have an execute premission. Check that with $stat test.
  2. For whatever reason, the name you gave to your test program infer with the system's shell builtin command test. Rename your program.
YSC
  • 38,212
  • 9
  • 96
  • 149
  • I moved the code to Documents, compiled it there twice, returning an executable called asdf and another called bop. I used chmod +r for both but the shared library warning still pops up – Mynlok May 18 '18 at 14:03
  • oh yeah, it is, dumb me. I mentioned a warning popped up telling me to pick a program to open "shared library" – Mynlok May 18 '18 at 14:08
  • Ho ok, I though you meant a warning at compilation time ^^ – YSC May 18 '18 at 14:09
  • Leaving the executable outside of home just so I can run it by clicking on it is more work than just running it from the console. Do you have any idea how I could get it to work on home? – Mynlok May 18 '18 at 14:21
0

Run your program in a terminal emulator on the command line, using your interactive shell. Be aware of the PATH variable (you might change it by configuring your interactive shell, e.g. in ~/.bashrc). Your shell will use execve(2) (after globbing) to run your executable binary (so it should stay on some executable partition, as answered by YSC and be executable - see stat(2)). You want to see the stdout and stderr outputs of your program. See also this answer.

Use g++ with all warnings and debug info, so g++ -Wall -Wextra -g. Avoid naming test your program (that name conflicts with test(1)). If your executable uses other libraries, you might need to explicit some rpath at link time.

Only when your program is a GUI program (e.g. coded for a widget toolkit like Qt) should you care to (eventually) be able to run it in your desktop with a click (details could be specific to your desktop environment). You'll bother about that much later (and you probably even should not, and leave that burden to your user, or to the packager of your program).

I make sure the program [....] is seen as an executable by the file manager?

That is a sysadmin question and could depend upon your desktop environment or window manager. I won't bother at first, but later you might have some desktop entry specification (some file ending with .desktop) describing your program. So use an editor to create that asdff.desktop textual file (it probably should go into your $HOME/Desktop/ directory and should mention absolute file paths).

Exec=./home/miguel/Desktop/asdff

The . is a typo, should be Exec=/home/miguel/Desktop/asdff without any dot.

Every program on Linux is started by execve(2) (done by a shell, your desktop environment, or some other program). You should use a shell in a terminal emulator to start most of your programs, especially when developing them. And you certainly should expect your users to run your program with their shell (I hate starting programs with my mouse), perhaps in some shell script combining your program with other ones. Read also about the Unix philosophy.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I compiled it with the command `g++ -Wall -Wextra -g test.cpp -o asdff`. No warnings popped up during compilation but the issue remains on the asdff executable. I can run it from the command line but it still mentions the shared library if I double click it – Mynlok May 18 '18 at 14:07
  • **Don't use double clicks to start your program**, at least not till they are completely debugged, with a GUI interface, and stable enough. ***Take the habit of using the terminal*** – Basile Starynkevitch May 18 '18 at 14:08
  • I do have the habit of using the terminal, it's just that I actually got this issue from trying to run a program with a gtk3 gui. I wouldn't say I debugged it as far as I could but I intended to actually put the program to use for myself, so, if it has any bugs, I'll be the only person getting hurt by them. I just made this sample for it to be easier to explain, since the issue didn't appear to be related to gtk3 – Mynlok May 18 '18 at 14:14
  • That should go into your question; such a context is very important, and your question did not mention it, and it is unclear. Please **edit your question** to improve it and give all error messages there. – Basile Starynkevitch May 18 '18 at 14:15
  • I just chose to leave it out because it acted as weird if I used a simpler program and it'd make explaining easier. Plus, if it gets solved for the sample, there are good odds it also gets solved for the original program – Mynlok May 18 '18 at 14:19
  • You could code some [MCVE] using GTK and show it in your question, and its output in a terminal. You also should give the `.desktop` file for it; and of course you need to `chmod u+rx` your executable (but a successful `gcc` does that) – Basile Starynkevitch May 18 '18 at 14:19