Code::Blocks Forums
User forums => Help => Topic started by: AlanX on April 17, 2019, 03:27:24 pm
-
I have used CobeBlocks for C programming for a while now:
Running Mint 19.1
Previous install 16.01 okay (other than constant crashing)
Installed 17.12
Installed xterm (required for 17.12)
For my code:
The file ezxdisp.h was copied into /usr/include (as superuser)
The file libezx.a was copied into /usr/lib (as superuser)
I get this error:
-------------- Build: Release in Gear (compiler: LLVM Clang Compiler)---------------
clang -Wall -O2 -I. -c /home/alanx/Documents/AlanC_Ccode_Mint/Gear/Gear.c -o ./Gear.o
clang++ -L. -o ./Gear ./Gear.o -lezx -lX11 -lm -s -lezx -lX11 -lm
/home/alanx/Documents/AlanC_Ccode_Mint/Gear/Gear.c:10:10: fatal error: 'ezxdisp.h' file not found
#include <ezxdisp.h>
^~~~~~~~~~~
...
Same error with gcc.
If I set the compiler and liker paths to /usr/include and /usr/lib it still fails.
Why is it a CodeBlocks problem:
1) This project previously worked with 16.01 (this morning).
2) If I drop the lines (from the build-log) in a terminal it works fine:
clang -Wall -O2 -I. -c /home/alanx/Documents/AlanC_Ccode_Mint/Gear/Gear.c -o ./Gear.o
clang++ -L. -o ./Gear ./Gear.o -lezx -lX11 -lm -s -lezx -lX11 -lm
3) If I put the header and the library (libezx.a) in the working directory (and set the paths) it works fine.
I get the similar error with "sdl_bgi_2.2.4-1_amd64.deb" and likely not unique to these two libraries.
Please any suggestions.
Update: Please Read!
Ah! I think I know what it is. The version I installed was a "FlatPak" and now I know it is a self contained package (like AppleImage or what ever it is called) and does not actually use /usr/* etc. It is self contained so it has its own "/usr/lib" and /usr/include" directories. Which is why it could not find my libraries!
Update
Yes, FlatPak blacklists /usr, so I uninstalled and installed the latest binary from CodeBlocks.
Happy little programmer now.
AlanX
-
You have to report this problem to the provider of the FlatPak. We as a project don't provide flatpaks, so we don't know how have they setup.
But if the problem you're depicting is unsolvable this means that C::B cannot be shipped as a flatpak...
-
Here is a discussion about this on #flatpak on irc.freenode.net.
I'm leaving it here if there is a volunteer to do the work:
(2019-04-17 20:56:16) obfuscated: Hello, a user of codeblocks reported that building with a flatpak version of the application doesn't work, because stuff (headers and libraries) in /usr is not accessible to the compiler started by codeblocks. Is there any way to start sub processes which aren't sandboxed? Is there a way to disable the sandbox?
(2019-04-17 21:03:09) TingPing: obfuscated, no, ides have to be specifically designed to separate the runtime environment from a build environment
tierpod tilosp TingPing tintou
(2019-04-17 21:03:58) obfuscated: TingPing: what do you mean?
(2019-04-17 21:04:56) TingPing: obfuscated, the IDE needs to understand its in a sandbox and run build commands in a different context (be it a different sandbox, or in this case escaping the sandbox on the host)
tierpod tilosp TingPing tintou
TingPing tintou
(2019-04-17 21:06:01) TingPing: obfuscated, gnome-builder being a great example of this done in practice
TingPing tintou
(2019-04-17 21:08:56) obfuscated: TingPing: what/where exactly should I look in its source code?
(2019-04-17 21:10:31) TingPing: obfuscated, thats a pretty broad question, the entire codebase is designed around the build environment split
(2019-04-17 21:10:36) TingPing: but like https://gitlab.gnome.org/GNOME/gnome-builder/tree/master/src/plugins/flatpak
(2019-04-17 21:12:24) obfuscated: yes, but there should be a place where you start an external process and do some communication with it
(2019-04-17 21:13:20) TingPing: let me browse around a bit
(2019-04-17 21:13:36) TingPing: i think the high level api is: https://gitlab.gnome.org/GNOME/gnome-builder/blob/master/src/libide/foundry/ide-run-manager.h
(2019-04-17 21:13:57) nliadm: I was able to do this in vim: `set shell=flatpak-spawn\ --host\ sh`
(2019-04-17 21:14:08) nliadm: which... mostly works
(2019-04-17 21:14:14) TingPing: everything in here is honestly core to how building is handled: https://gitlab.gnome.org/GNOME/gnome-builder/tree/master/src/libide/foundry
(2019-04-17 21:14:52) TingPing: yes that command is the most basic of ways to do it, but my point is an IDE has to be designed around this or else it is just a lame hack
tierpod tilosp TingPing tintou
(2019-04-17 21:15:50) obfuscated: TingPing: thanks... I guess for know we just have to detect flatpak and just issue an error. :)
(2019-04-17 21:16:09) TingPing: error: this package is useless, good luck?
(2019-04-17 21:16:41) TingPing: obfuscated, ah and here is the flatpak impl of that runner: https://gitlab.gnome.org/GNOME/gnome-builder/blob/master/src/plugins/flatpak/gbp-flatpak-runner.c
(2019-04-17 21:16:45) obfuscated: sort of, it could be use to edit some text, if flatpak makes it possible to open files on the fs...
(2019-04-17 21:17:08) TingPing: obfuscated, i find it really disappointing people package tools and don't understand how any of this works
(2019-04-17 21:18:46) obfuscated: TingPing: I'm not responsible for the flatpak package...
-
I did not research the problem to any depth, but to overcome a "blacklisted directory" said it all to me. I am not meant to access this directory.
To use FlatPak you have to use a non-standard (non-blacklisted) directory for all your installed libraries. Yeah right!
Unless a tool is provided (and documented) to update the internal FlatPak "/usr" directories then I would say FlatPak is not an option for almost all programmers.
Your post of your discussion on FlatPak was interesting, "... the IDE needs to understand its in a sandbox and run build commands in a different context (be it a different sandbox, or in this case escaping the sandbox on the host)."
Yeah right!
Regards AlanX
-
"... the IDE needs to understand its in a sandbox and run build commands in a different context (be it a different sandbox, or in this case escaping the sandbox on the host)."
This bothered me hard... Isn't the purpose of a sandbox to not let the sandboxed application break the sandbox? If this would be possible, why use a sandbox? Strange...