CodeBlocks unable to find header file - Not the usual ... path problem - Solved

[AlanX]

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

[oBFusCATed]

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...

[oBFusCATed]

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...

[AlanX]

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

[BlueHazzard]

"... 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...