undefined reference to `operator delete(void*, unsigned long)@Qt_5'

16729
23
01-24-2020 12:26 AM
NorbertThoden
Occasional Contributor III

Hi!

I tried to update from 100.6 to 100.7

While linking the executables i got an undefined reference:

lib64/libEsriCommonQt.so: undefined reference to `operator delete(void*, unsigned long)@Qt_5'

I´m using

  • openSUSE Leap 15.1
  • 5.13.1
  • gcc (SUSE Linux) 7.4.1

I tried to compile with a) -std=gnu++11 and b) -std=gnu++14, but no difference.

Which Qt did you use on Suse? The one of the operating system (suse) or did you compile Qt on your own?

Can you provide more information?

Thanks in advance!!!

Norbert

0 Kudos
23 Replies
JamesBallard1
Esri Regular Contributor

Hi Norbert Thoden‌,

    We did not build and test with our own version of Qt. We have tested on SuSE Enterprise Linux 15, but we use the version of Qt from the Qt Company to test and certify with. Our software is built against Qt 5.12.6, but 5.13.1 should work as well.

We have occasionally seen this type of problem before, and usually the symptom is there is a second installation of Qt in the system path somewhere that's getting picked up that's a different version than the one we're trying to build and run against.

Can you see if that's the case? If you set your LD_LIBRARY_PATH and then run "ldd" on libEsriCommonQt.so, does it pick up Qt libraries from a different location than you expect?

Please let us know and we can help troubleshoot the problem.

0 Kudos
NorbertThoden
Occasional Contributor III

Hi James!

Thx for the quick response!

1)

We did not build and test with our own version of Qt. We have tested on SuSE Enterprise Linux 15, but we use the version of Qt from the Qt Company to test and certify with.

For me it´s not really clear:

You are using the Qt from the Company (and not the one shipped with SUSE distribution) but did not build it?

Can you please explain in detail what you did?

2)

On my system the LD_LIBRARY_PATH is not defined, and there is just one qt installation. So 'ldd' shows that the '/usr/lib64/libQt5Core.so.5' ist used.

2a) /usr/lib64/libEsriRuntimeQt.a
Using nm -gC /usr/lib64/libEsriRuntimeQt.a | grep delete i get:

@V00.6.0:

...

0000000000000110 T Esri::ArcGISRuntime::FeatureTable::deleteFeaturesCompleted(QUuid, bool)
U operator delete(void*)
U operator delete(void*)
U operator delete(void*)
U operator delete(void*)
U operator delete(void*)
U operator delete(void*)
0000000000000200 T Esri::ArcGISRuntime::PortalUser::deleteFolderCompleted(bool)

...

@V00.7.0:

...

0000000000000110 T Esri::ArcGISRuntime::FeatureTable::deleteFeaturesCompleted(QUuid, bool)
U operator delete(void*, unsigned long)
U operator delete(void*, unsigned long)
U operator delete(void*, unsigned long)
U operator delete(void*, unsigned long)
U operator delete(void*, unsigned long)
0000000000000200 T Esri::ArcGISRuntime::PortalUser::deleteFolderCompleted(bool)

...

So, the undefined symbol for delete(void, unsigned long) is introduced with V100.7.0. - already known 🙂

2b) /usr/lib64/libQt5Core.so.5

ctc@CTCAP15:~/TDS/TDS-build> objdump -TC /usr/lib64/libQt5Core.so.5 | grep delete
0000000000000000 DF *UND* 0000000000000000 CXXABI_1.3.9 operator delete[](void*, unsigned long)
0000000000000000 DF *UND* 0000000000000000 CXXABI_1.3.9 operator delete(void*, unsigned long)
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 operator delete[](void*)
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 pthread_key_delete
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 operator delete(void*)
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 operator delete(void*, std::nothrow_t const&)
00000000002c9f90 g DF .text 0000000000000182 Qt_5.13.1_PRIVATE_API QObjectPrivate::deleteChildren()
00000000002ca120 g DF .text 0000000000000049 Qt_5 QObject::deleteLater()

2c) /usr/lib64/libstdc++.so.

objdump -TC /usr/lib64/libstdc++.so.6 | grep delete

0000000000000000 w D *UND* 0000000000000000 transaction clone for operator delete(void*)
0000000000000000 w D *UND* 0000000000000000 pthread_key_delete
000000000009b1e0 g DF .text 000000000000000c CXXABI_1.3 __cxa_vec_delete
0000000000098760 g DF .text 0000000000000005 GLIBCXX_3.4 operator delete(void*)
000000000009a6c0 g DF .text 0000000000000008 CXXABI_1.3.11 operator delete[](void*, unsigned long, std::align_val_t)
0000000000098770 g DF .text 0000000000000005 CXXABI_1.3.9 operator delete(void*, unsigned long)
0000000000098790 g DF .text 0000000000000005 GLIBCXX_3.4 operator delete[](void*)
000000000009ab50 g DF .text 0000000000000021 CXXABI_1.3.6 __cxa_deleted_virtual
000000000009a670 g DF .text 0000000000000005 CXXABI_1.3.11 operator delete(void*, std::align_val_t)
000000000009a6a0 g DF .text 0000000000000005 CXXABI_1.3.11 operator delete[](void*, std::align_val_t)
00000000000987a0 g DF .text 0000000000000005 CXXABI_1.3.9 operator delete[](void*, unsigned long)
000000000009a680 g DF .text 0000000000000005 CXXABI_1.3.11 operator delete(void*, std::align_val_t, std::nothrow_t const&)
000000000009a6b0 g DF .text 0000000000000005 CXXABI_1.3.11 operator delete[](void*, std::align_val_t, std::nothrow_t const&)
000000000009a690 g DF .text 0000000000000008 CXXABI_1.3.11 operator delete(void*, unsigned long, std::align_val_t)
000000000009b190 g DF .text 0000000000000046 CXXABI_1.3 __cxa_vec_delete2
000000000009b1f0 g DF .text 0000000000000066 CXXABI_1.3 __cxa_vec_delete3
00000000000c3600 g DF .text 0000000000000029 GLIBCXX_3.4.22 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)())
00000000000987b0 g DF .text 0000000000000005 GLIBCXX_3.4 operator delete[](void*, std::nothrow_t const&)
0000000000098780 g DF .text 0000000000000005 GLIBCXX_3.4 operator delete(void*, std::nothrow_t const&)

So, requested symbol is defined in /usr/lib64/libstdc++.so.6, but with CXXABI_1.3.9 and not GLIBCXX_3.4..

My /usr/lib64/libstdc++.so.6 is owned by libstdc++6-8.2.1+r264010-lp151.1.33.x86_64, which is currently the newest for my system:

rpm -qi libstdc++6-8.2.1+r264010-lp151.1.33.x86_64
Name : libstdc++6
Version : 8.2.1+r264010
Release : lp151.1.33
Architecture: x86_64
Install Date: Mo 27 Mai 2019 17:33:41 CEST
Group : System/Libraries
Size : 1602680
License : GPL-3.0-with-GCC-exception
Signature : RSA/SHA256, Sa 04 Mai 2019 08:45:27 CEST, Key ID b88b2fd43dbdc284
Source RPM : gcc8-8.2.1+r264010-lp151.1.33.src.rpm
Build Date : Sa 04 Mai 2019 08:26:15 CEST
Build Host : build81
Relocations : (not relocatable)
Packager : https://bugs.opensuse.org
Vendor : openSUSE
URL : http://gcc.gnu.org/
Summary : The standard C++ shared library
Description :
The standard C++ library, needed for dynamically linked C++ programs.
Distribution: openSUSE Leap 15.1

But the undefined symbol is at qt: `operator delete(void*, unsigned long)@Qt_5'

May i please you to post which gcc you are using?
And maybe run the upper commands to know where the symbol is defined on your system?

Thx

0 Kudos
JamesBallard1
Esri Regular Contributor

Norbert Thoden‌,

>For me it´s not really clear:

>You are using the Qt from the Company (and not the one shipped with SUSE distribution) but did not build it?

>Can you please explain in detail what you did?

 

Sorry, I will clarify. We download the commercial version of Qt and use that with our builds. We do not build the Qt Company's SDK for our builds precisely to avoid these types of version and compiler incompatibility.

We build our SDK libraries with the same build configuration as the Qt Company for 5.12:

Supported Platforms | Qt 5.12 

Red Hat Enterprise Linux 7.4 and using GCC 5.3.1 via the devtoolset-4.

I did some more digging and it looks like that symbol is actually defined by the QtCore library, which I find very odd.

nm /applications/Qt5.12.6/5.12.6/gcc_64/lib/libQt5Core.so.5.12.6 | c++filt | grep "operator delete" | grep "unsigned long"
0000000000396fa0 T operator delete[](void*, unsigned long)
0000000000396fb0 T operator delete(void*, unsigned long)

And I can see that these are getting resolved at runtime to the Qt library as well. I cannot explain why this Qt library would define operator delete, but it does and we are resolving it from that library. 

LD_DEBUG=bindings ./testApp
...
binding file /applications/Qt5.12.6/5.12.6/gcc_64/plugins/platforms/../../lib/libQt5DBus.so.5 [0] to /applications/Qt5.12.6/5.12.6/gcc_64/lib/libQt5Core.so.5 [0]: normal symbol `operator delete(void*, unsigned long)' [Qt_5]‍

As you found, libQt5Core.so.5 provided with the SuSE version of Qt that you are using does not provide that symbol, so it is getting resolved elsewhere.

My recommendation is to check with SuSE to see if they are building Qt differently than the standard configuration. Another option is to download Qt directly from the Qt Company. As a quick test, I downloaded Qt 5.13.1 directly from https://account.qt.io/downloads  and verified that the operator delete in question is defined in their version, so it should be compatible.

Let me know if this helps.

0 Kudos
ChristianEhrlicher
New Contributor II

I think we now found a solution on how to get around this. We created a small library which defines 'operator delete(void*, size_t)' and use a version script to annotate it with the Qt5 'namespace'. Then we only have to make sure it's loaded before libEsriCommonQt.so and all is fine.

But the question persists - why does libQtCore5.so provided by TQtC (compiled with c++14 according to Coin logs) export this symbol whereas the one from openSuSE does not (openSuSE even compiles with c++17, according to build.opensuse.org logs)

0 Kudos
JamesBallard1
Esri Regular Contributor

Thanks Christian Ehrlicher‌. I am also unclear on why libQtCore5.so exports and defines this symbol. If you do figure out why this is, I would be interested in knowing as well.

0 Kudos
FatmaAkdemir
Occasional Contributor II

I am having the same problem on Ubuntu 20.0.4 and because of this error I cannot use any Arcgis library whose version is greater than 100.0.6. Is there any concise solution yet? 

0 Kudos
NorbertThoden
Occasional Contributor III

Hi!
We still use the solution my colleaguge Christian Erhlicher mentioned.
Until now we didn´t recognize any drawbacks yet. So i can recommend that 🙂

I can provide that if helpful

FatmaAkdemir
Occasional Contributor II

Hi Norbert Thoden‌ , that would be great if you could share the details of this solution. I am looking forward to hear from you.

0 Kudos
LucasDanzinger
Esri Frequent Contributor

Just curious - how did you obtain the Qt framework? Did you download directly from qt.io?

0 Kudos