Link Problems in Linux

Do you have a question about makefiles, a compiler or IDE you are using and need to know how to set it up for wxWidgets or why it doesn't compile but other IDE's do ? Post your questions here.
Post Reply
mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Link Problems in Linux

Post by mike19331 » Sat Mar 28, 2020 8:45 am

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.

DavidHart
Site Admin
Site Admin
Posts: 3969
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Link Problems in Linux

Post by DavidHart » Sat Mar 28, 2020 9:47 am

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

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Sat Mar 28, 2020 5:11 pm

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?

DavidHart
Site Admin
Site Admin
Posts: 3969
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Link Problems in Linux

Post by DavidHart » Sat Mar 28, 2020 7:40 pm

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?

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Sun Mar 29, 2020 4:36 am

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
Last edited by DavidHart on Sun Mar 29, 2020 6:42 am, edited 1 time in total.
Reason: Added code-tags

stahta01
Super wx Problem Solver
Super wx Problem Solver
Posts: 355
Joined: Fri Nov 03, 2006 2:00 pm

Re: Link Problems in Linux

Post by stahta01 » Sun Mar 29, 2020 4:59 am

My wild guess is you need to build the static wxWidgets library with "-fPIC".

Tim S.

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Sun Mar 29, 2020 6:35 am

good idea. i just tried so.
./configure --enable-abi-incompatible-features --disable-shared --disable-debug CXXFLAGS="-fPIC"

:( same result

DavidHart
Site Admin
Site Admin
Posts: 3969
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Link Problems in Linux

Post by DavidHart » Sun Mar 29, 2020 6:56 am

It would be the 'make' line that needs -fPIC, not the 'configure' line.

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Sun Mar 29, 2020 8:46 am

lots of thanks. its solved in that way. but anyway as alternative i will try appimage too.

have a great sunday :)

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4058
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Link Problems in Linux

Post by ONEEYEMAN » Sun Mar 29, 2020 2:29 pm

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.

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Sun Mar 29, 2020 3:49 pm

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

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4058
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Link Problems in Linux

Post by ONEEYEMAN » Sun Mar 29, 2020 5:07 pm

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.

mike19331
In need of some credit
In need of some credit
Posts: 7
Joined: Sat Mar 28, 2020 8:38 am

Re: Link Problems in Linux

Post by mike19331 » Mon Mar 30, 2020 2:32 am

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

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4058
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Link Problems in Linux

Post by ONEEYEMAN » Mon Mar 30, 2020 3:11 am

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.

Post Reply