$LinkLib: Linker not finding Symbol (Fedora 29)
lazarus / 32-Linux

----------------------------------------------------------------------
Skotty · 2019-08-27 20:36

Greetings,

I am in the process to get a purely Windows made project run under
Linux. Most code is already compatible, but linking some required
libraries causes issues.

All dynamic libraries I use are natively available in Fedora 29 and
those link fine. However, one is custom made and I try to link it
statically. The library is written in C++ and compiled with gcc 8.3.

So far, linking it with $linklib works fine. But some dependencies the
.a file needs are not linking properly.
Code: [Select]{$LinkLib m}
{$LinkLib stdc++}
{$LinkLib dCustomJoints}are both required.

So far so good. However, I get the following error despite this:
QuoteWarning: linker: /usr/bin/ld:
./libdCustomJoints.a(dCustomJoint.cpp.o): undefined reference to
symbol '_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3'

Warning: linker: /usr/bin/ld: /lib64//libstdc++.so.6: error adding
symbols: DSO missing from command line
I checked, and the libstdc++.so.6 exists, and also contains
_ZTVN10__cxxabiv117__class_type_infoE, looked via grep.
My libstdc++ is of version 8.3.1-2.fc29. Same for the libstdc++-devel
version.
I am currently clueless how to resolve this linking error.

----------------------------------------------------------------------
sash · 2019-08-28 16:57

Quote from: Skotty on August 27, 2019, 10:36:46 pmThe library is
written in C++
Code: [Select]{$LinkLib m}
{$LinkLib stdc++}
{$LinkLib dCustomJoints}
Are you linking pure C++? Normally, you should wrap it as C with
Code: C++  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i extern "C"
{ /*...*/ }
And I'd rather moved all C++ dependencies (except those actually
needed in Pascal) in C++ part of your project.

Also, sometimes order of listed libs matters.

----------------------------------------------------------------------
Skotty · 2019-08-28 18:27

Thanks for the answer.
It is a normal C interface, but it uses c++ internally anyway.
Also the order of $linklib did not change anything.

----------------------------------------------------------------------
sash · 2019-08-29 10:42

Quote from: Skotty on August 28, 2019, 08:27:33 pmit uses c++
internally anyway.
If it uses (libstdc++) internally, why do you need C++ library in
Pascal?
Why don't you move this dependency to C++ part?

Another suspicious moment is that you have static library .a listed
along with dynamic one .so (but probably this ambiguity is a
consequence of above questions).

----------------------------------------------------------------------
Skotty · 2019-08-29 19:44

Hello,
it is a c++ library with a c interface. The .a files come from the
cmake script of my external library.
The libstdc++.so is there by default from the system and dynamically
linked.
The static linked library should have no problem being dependent on a
dynamically linked library.
Also the $LinkLib works with libm flawless.

----------------------------------------------------------------------
sash · 2019-08-29 22:52

Quote from: Skotty on August 29, 2019, 09:44:33 pmThe libstdc++.so is
there by default from the system and dynamically linked.

Not sure I understood this. To me, {$LinkLib stdc++}  is redundant.

----------------------------------------------------------------------
Skotty · 2019-09-02 22:08

Unfortunately I could not figure out the issue. I finally decided to
use normal dynamic linking for the time being. Maybe one day I do have
more time to look into this again.

----------------------------------------------------------------------
sash · 2019-09-18 10:00

Surprisingly, I've just been involved in solving similar task
(C-wrapped C++ code used in FPC) and I can confirm it is indeed an
"issue".

At last, I ended with shared library: thus I don't have to list all
static dependencies in FPC project, plus it's more convenient to debug
whole system (no need to rebuild FPC app when changed minor C++'s
internals).

In case you still must use static linking, my case (for static) was
solved like this

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i {$linklib
stdc++}{$linklib gcc_s}//...{$linklib myCWrapperForCPP}