How to get a bin-file working as standalone program with GUI?

[Panama]

Version          : svn-r12286
OS: Linux Mint

Build my project as GUI application. Bin file is under ../my_project/bin/Release/
It works fine inside CB IDE. It is executable right from the console. It is NOT startable by double click on it.

Any hints?

[Commaster]

Try opening a terminal first, navigate to ../my_project/bin/Release/ and run you app as ./appname

Maybe it starts and finishes really quick or it complains about something...

[Suryavarman]

CB call your application with a working directory, a library path etc.

If you want to run your application without any parameters, in the application folder you have to copy past the dependencies and not the system dependencies. If you want to have an application without .so, you have to link your project with the static libraries. The code will be put directly in your application.

[oBFusCATed]

Static linking or lib copying is not required.
To replicate what C::B does one must specify the correct value for the LD_LIBRARY_PATH environment variable.
Or change the linking to use @ORIGIN rpaths.

[stahta01]

Or change the linking to use @ORIGIN rpaths.

For those like me who never heard of "@ORIGIN".
https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/

Tim S.

[Panama]

@Commaster: from terminal (console) it starts fine (as I wrote in my mail...).

I will try to understand the @ORIGIN rpaths explanations.

@oBFusCATed: where is the LD_LIBRARY_PATH to set? I mean, that is a sytem-wide variable. Because I can start the programm out of CB, why is CB not able to build a 'fully' working binary?
I cannot believe, that I am the first coder with this problem. I tried to find out in the CB wiki and the only hint I found was:"Link  with Build option GUO-application".
Sorry I'm a bit confused now...

Axel

[Panama]

[/quote]

For those like me who never heard of "@ORIGIN".
https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/

Tim S.
[/quote]

I did a readout with readelf -d and I found no RPATH, like described in your link. Here's what I get:

Dynamic section at offset 0x5bb0 contains 33 entries:
  Tag       Typ                          Name/Wert
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libgtk-3.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libgdk-3.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libpango-1.0.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libgdk_pixbuf-2.0.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libgobject-2.0.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libglib-2.0.so.0]
0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libc.so.6]
0x000000000000000c (INIT)               0x2838
0x000000000000000d (FINI)               0x4254
0x0000000000000019 (INIT_ARRAY)         0x205ba0
0x000000000000001b (INIT_ARRAYSZ)       8 (Bytes)
0x000000000000001a (FINI_ARRAY)         0x205ba8
0x000000000000001c (FINI_ARRAYSZ)       8 (Bytes)
0x000000006ffffef5 (GNU_HASH)           0x298
0x0000000000000005 (STRTAB)             0x16c0
0x0000000000000006 (SYMTAB)             0x670
0x000000000000000a (STRSZ)              2517 (Bytes)
0x000000000000000b (SYMENT)             24 (Bytes)
0x0000000000000015 (DEBUG)              0x0
0x0000000000000003 (PLTGOT)             0x205e00
0x0000000000000002 (PLTRELSZ)           1344 (Bytes)
0x0000000000000014 (PLTREL)             RELA
0x0000000000000017 (JMPREL)             0x22f8
0x0000000000000007 (RELA)               0x2238
0x0000000000000008 (RELASZ)             192 (Bytes)
0x0000000000000009 (RELAENT)            24 (Bytes)
0x000000000000001e (FLAGS)              BIND_NOW
0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
0x000000006ffffffe (VERNEED)            0x21f8
0x000000006fffffff (VERNEEDNUM)         1
0x000000006ffffff0 (VERSYM)             0x2096
0x000000006ffffff9 (RELACOUNT)          3
0x0000000000000000 (NULL)               0x0

Maybe somebode y of you can see what lacks.

Cheers, Axel

[oBFusCATed]

Panama:
LD_LIBRARY_PATH is not a global variable, whatever that means.
You can override it in the console just before you start your application.
This is what C::B does. You can see the value used by C::B in the build log or the debugger log.

It is clear that C::B works correctly, because the application starts correctly when you hit the Run/Debug buttons.
But the thing that it makes it kinda "just works" catches you by surprise, when you don't have C::B to help you setup things.

p.s. You're not the first one which complains about this.
p.p.s. If you'll spend lots of time developing/maintaining this application I advise you to learn how shared libraries work on linux. It will minimize the confusion even if the topic is not easy to grasp.

[Panama]

@oBFusCATed:
Thanks meanwhile! I have a raw idea, what the shared libraries are for and how that concept works.

I feel, that my application lacks of the information, where the necessary libs are to find. So I will fiddling around the next weeks to get it work.
An appropriate tutorial or a short hint "put a path like this in the build options like that" would probably have been enough for me.

Thanks again,
Cheers, Axel

[Panama]

I found a difference compared to other programs: programs are of type "application/executeable". My program was of type "application/x-sharedlib.
This was suspicious to me. The important suggestion I found here:

https://stackoverflow.com/questions/41398444/gcc-creates-mime-type-application-x-sharedlib-instead-of-application-x-applicati

I rebuild my program with linker flag -no-pie and, voila, the program is treated as "application/executeable".

Cheers,
Axel

[sodev]

Another important information from that post is that the misdetection of the application as library should not be viewed as a bug and if you disable pie you should really know what you are doing because this can defeat additional security features.