Page 1 of 1

Link Problems in Linux

Posted: Sat Mar 28, 2020 8:45 am
by mike19331
i want to build my programs in linux independent, means in static library mode. Works well, but i need to add plugins too. While compiling the plugins, i always get error message "cant be used in dynlib". Anyone with a hint about? Base is, to prevent ABI problems on other computers.

Re: Link Problems in Linux

Posted: Sat Mar 28, 2020 9:47 am
by DavidHart
Hi,
to prevent ABI problems on other computers
But what you are trying to do will fail to prevent ABI problems. That is because you are static-linking wx libs, but not their dependencies.

The standard answer is to link dynamically to (and depend on) the official wxGTK package of that distro/version, and the standard way to do that is by creating a separate deb/rpm/whatever for each distro/version that you support.

Alternatively you could create one of the more recent cross-distro solutions e.g. an AppImage, that contain all of your program's dependencies in a single package.

Regards,

David

Re: Link Problems in Linux

Posted: Sat Mar 28, 2020 5:11 pm
by mike19331
Thanks for ur answer. Your right, appimage is a possible solution. The only problem about: i use in my cura program, and its sooo slow.

Better would be the basic way, compiling with static libraries. Means, you dont see any way to link static libraries in dynlib?

Re: Link Problems in Linux

Posted: Sat Mar 28, 2020 7:40 pm
by DavidHart
i use in my cura program, and its sooo slow.
I've tested 3 programs with/without AppImage, and there was no obvious speed difference.
you dont see any way to link static libraries in dynlib?
You haven't explained enough about what is going wrong. There should be no reason why a static-linked wxWidgets build will fail to link to your program (though the resulting binary will still depend on lots of other things specific to that distro/version).
i always get error message "cant be used in dynlib".
Which libraries/programs is the linker reporting with that error message? Your program? Your system's wxWidgets package? A self-built wxWidgets? Or something else?

If it's a self-built wxWidgets, how did you configure it?

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 4:36 am
by mike19331
i am sorry, your right. its some more infos needed:
i use selfcompiled version of 3.1 with following config:
../configure --enable-abi-incompatible-features --disable-shared --disable-debug
for the libraries.

Works fine for the executables, but if i want to build a shared library with that, i get following error:

Code: Select all

-------------- Build: Release in myDLL (compiler: GNU GCC Compiler)---------------

g++ -Wall -fexceptions -fPIC -I/usr/local/lib64/wx/include/gtk2-unicode-static-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -D__WXGTK__ -pthread -I/usr/local/lib64/wx/include/gtk2-unicode-static-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -D__WXGTK__ -pthread -DWXUSINGDLL  -c /share/windows/wx/myDLL/main.cpp -o obj/Release/main.o
g++ -shared  obj/Release/main.o  -o bin/Release/libmyDLL.so -I/usr/local/lib64/wx/include/gtk2-unicode-static-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -D__WXGTK__ -pthread -I/usr/local/lib64/wx/include/gtk2-unicode-static-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -D__WXGTK__ -pthread -L/usr/local/lib64 -pthread   /usr/local/lib64/libwx_gtk2u_xrc-3.1.a /usr/local/lib64/libwx_gtk2u_qa-3.1.a /usr/local/lib64/libwx_baseu_net-3.1.a /usr/local/lib64/libwx_gtk2u_html-3.1.a /usr/local/lib64/libwx_gtk2u_adv-3.1.a /usr/local/lib64/libwx_gtk2u_core-3.1.a /usr/local/lib64/libwx_baseu_xml-3.1.a /usr/local/lib64/libwx_baseu-3.1.a -lgthread-2.0 -pthread -lX11 -lXxf86vm -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lpng -ltiff -lexpat -lwxregexu-3.1 -lwxjpeg-3.1 -lz -ldl -lm   
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libwx_gtk2u_core-3.1.a(corelib_event.o): relocation R_X86_64_32 against `_ZN14wxCommandEvent12ms_classInfoE' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib64/libwx_gtk2u_core-3.1.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
The message recompile with -fPIC is confusing, cos its inserted at beginning. Its simple main to test with only a messagebox. Maybe you have any idea about the problem?

Greets mike19331

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 4:59 am
by stahta01
My wild guess is you need to build the static wxWidgets library with "-fPIC".

Tim S.

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 6:35 am
by mike19331
good idea. i just tried so.
./configure --enable-abi-incompatible-features --disable-shared --disable-debug CXXFLAGS="-fPIC"

:( same result

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 6:56 am
by DavidHart
It would be the 'make' line that needs -fPIC, not the 'configure' line.

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 8:46 am
by mike19331
lots of thanks. its solved in that way. but anyway as alternative i will try appimage too.

have a great sunday :)

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 2:29 pm
by ONEEYEMAN
Hi,
My understanding is that it is not a good idea to build static wxWidgets for DLL.

What is the purpose of doing it?

Thank you.

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 3:49 pm
by mike19331
Honestly, i get doubts too. my testprogram with testlib is about 12 mb. a testprogram whats only a window, and the lib, whats only a messagebox.

the plan had been, to be independant from the system libraries in several envirements like in windoofs. better had been, now i have to use appimage instead, i guess

Re: Link Problems in Linux

Posted: Sun Mar 29, 2020 5:07 pm
by ONEEYEMAN
Hi,
There is a reason why static linking is frown upon in *nix world.

The thing is you can install multiple version of the same software and then use special script to select which version is active at any given time. And so if one wants to create a software that for example links to GTK (which uses X or Wayland libraries) it should automatically pick up all active versions of the installed software on the machine and start working.

In case of static linking the program might conflict with the installed system libraries and it might create all kind of problems.

This scenario needs to be tested very carefully against any and all permutations, which is probably impossible. -)

Thank you.

Re: Link Problems in Linux

Posted: Mon Mar 30, 2020 2:32 am
by mike19331
yes and no in same time.

i have some pc with different suse systems on it. in dynlib version i cant change program between the pcs. i am forced to compile on every single computer. (sample abi) . and additional i remember a change of odbc library: i compiled version 2, and the other pc got version 1. thats in my mind a problem in linux. so i always have to follow the system changes, if i want or not. thats not always possible on different pc.

greets

Re: Link Problems in Linux

Posted: Mon Mar 30, 2020 3:11 am
by ONEEYEMAN
Hi,
This is not a "problem in linux".
The situation about *nix OSes is that in order to make a so-called "stable" system or make a package to be "stable" it has to be compiled against every possible permutations in the distribution we are talking about.

Meaning that if we are talking Ubuntu, all packages that will become available from that release package manager will have to be compiled and tested thoroughly against all different packages that this specific release is done.

So it is guaranteed that when the Ubuntu release happens every possible package in that specific release did undergo a proper testing and it is considered stable in this specific release.

Therefore compiling statically in *nox is not really necessary. It is guaranteed that the wxWidgets version that is provided by the distro in their package manager which will be compiled against the specific GTK+ version provided by the package manager will absolutely be working correctly.

And if something will not be working correctly - it is because there is a bug in that very specific version of GTK+ which almost guaranteed is present in every possible distribution and it might even be fixed already in the later version. Which means that you can install the later GTK+ and test it. And when the time comes to release the software you are writing, you can create a distribution package (either a deb rules file or some other software management file) where you specify the requirements for the GTK version, wx version and all other software version your application depends on.

Because, unfortunately, the license for GTK+ prevents you to link GTK+ statically, therefore you should always rely on the system provided version or make an appropriate distribution file rule.

I hope it is a little clearer now.

And that's why linking statically is not such a good idea in *nix.

Thank you.