topic Re: undefined reference to `operator delete(void*, unsigned long)@Qt_5' in Qt Maps SDK Questions

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

NorbertThoden — Fri, 24 Jan 2020 08:26:51 GMT

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

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

JamesBallard1 — Fri, 24 Jan 2020 16:37:45 GMT

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.

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

NorbertThoden — Mon, 27 Jan 2020 09:33:27 GMT

Hi James!

Thx for the quick response!

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?

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

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

JamesBallard1 — Sat, 11 Dec 2021 12:00:43 GMT

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.

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

ChristianEhrlicher — Tue, 28 Jan 2020 13:54:27 GMT

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)

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

JamesBallard1 — Tue, 28 Jan 2020 18:56:30 GMT

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.

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

FatmaAkdemir — Wed, 04 Nov 2020 07:37:23 GMT

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?

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

NorbertThoden — Thu, 05 Nov 2020 07:47:13 GMT

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

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

FatmaAkdemir — Mon, 09 Nov 2020 08:13:24 GMT

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

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

NorbertThoden — Sun, 12 Dec 2021 16:13:45 GMT

Hi!
I have attached a zip file containg our complete directory.

It contains:

arcgisqt5hack.cpp with the implementation of delete
arcgisqt5hack.version with the "namespace"
CMakeLists.txt with our commands

To overcome missing information of our CMakeLists.txt, i provide the sonsole output. I hope you´ll be able to transfer that into your build environment. The main part is marked bold:

cd /shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack && /usr/bin/g++ -DArcGISQt5Hack_EXPORTS  -DMAKE_ARCGISQT5HACK_LIB  -D_LINUX -I/shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack -I/shd/CTC/TOOLS/TDS/TDS-source/Lts/Viewer/SituationMap/ArcGISQt5Hack -I/shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack/ArcGISQt5Hack_autogen/include -Wall -Wextra -Wmissing-include-dirs -Wno-overloaded-virtual -Wno-strict-aliasing -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++14 -o CMakeFiles/ArcGISQt5Hack.dir/arcgisqt5hack.cpp.o -c /shd/CTC/TOOLS/TDS/TDS-source/Lts/Viewer/SituationMap/ArcGISQt5Hack/arcgisqt5hack.cpp
/shd/CTC/TOOLS/TDS/TDS-source/Lts/Viewer/SituationMap/ArcGISQt5Hack/arcgisqt5hack.cpp:15:45: warning: the program should also define ‘void operator delete(void*)’ [-Wsized-deallocation]
 __attribute__((visibility("default"))) void operator delete(void* ptr, std::size_t) noexcept
 ^~~~~~~~
[ 0%] Building CXX object Lts/Viewer/SituationMap/ArcGISQt5Hack/CMakeFiles/ArcGISQt5Hack.dir/ArcGISQt5Hack_autogen/mocs_compilation.cpp.o
cd /shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack && /usr/bin/g++ -DArcGISQt5Hack_EXPORTS  -DMAKE_ARCGISQT5HACK_LIB   -D_LINUX -I/shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack -I/shd/CTC/TOOLS/TDS/TDS-source/Lts/Viewer/SituationMap/ArcGISQt5Hack -I/shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack/ArcGISQt5Hack_autogen/include -Wall -Wextra -Wmissing-include-dirs -Wno-overloaded-virtual -Wno-strict-aliasing -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++14 -o CMakeFiles/ArcGISQt5Hack.dir/ArcGISQt5Hack_autogen/mocs_compilation.cpp.o -c /shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack/ArcGISQt5Hack_autogen/mocs_compilation.cpp
[100%] Linking CXX shared library ../../../../lib/libArcGISQt5Hack.so
cd /shd/CTC/TOOLS/TDS/TDS-build/Lts/Viewer/SituationMap/ArcGISQt5Hack && /usr/bin/cmake -E cmake_link_script CMakeFiles/ArcGISQt5Hack.dir/link.txt --verbose=true
/usr/bin/g++ -fPIC -Wall -Wextra -Wmissing-include-dirs -Wno-overloaded-virtual -Wno-strict-aliasing -g -Wl,--no-undefined -shared -Wl,-soname,libArcGISQt5Hack.so -o ../../../../lib/libArcGISQt5Hack.so CMakeFiles/ArcGISQt5Hack.dir/arcgisqt5hack.cpp.o CMakeFiles/ArcGISQt5Hack.dir/ArcGISQt5Hack_autogen/mocs_compilation.cpp.o -Wl,--version-script,/shd/CTC/TOOLS/TDS/TDS-source/Lts/Viewer/SituationMap/ArcGISQt5Hack/arcgisqt5hack.version 
make[2]: Verzeichnis „/shd/CTC/TOOLS/TDS/TDS-build“ wird verlassen
[100%] Built target ArcGISQt5Hack

Maybe you can share your result!?

Thx

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

FatmaAkdemir — Mon, 09 Nov 2020 11:30:19 GMT

When I try to generate Makefile from CMakeList.txt I am having the error :

CMake Error at CMakeLists.txt:8 (NGL_ADD_LIBRARY):
Unknown CMake command "NGL_ADD_LIBRARY".

Am I missing something?

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

NorbertThoden — Wed, 12 May 2021 06:37:37 GMT

That´s what i had in mind when i wrote "our" CMakeList.txt. Of course you have to adapt that into your build environment. maybe you are using CMake, pro file (Qt), os something else.

Therefore i was also providing the resulting command line.

Okay?

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

FatmaAkdemir — Mon, 09 Nov 2020 14:08:52 GMT

I am still getting the same error. How can I make sure that this library is loaded before libEsriCommon.so? I have created the library and included this library in my .pro file.

# nm -gC libArcGISQt5Hack.so
w __cxa_finalize
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U operator delete(void*)@@GLIBCXX_3.4
0000000000001119 T operator delete(void*, unsigned long)

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

NorbertThoden — Mon, 09 Nov 2020 14:25:03 GMT

Indeed, if forgot to mention the fact that this new lib has to be loaded very early (in the list of libs)

We did this by adding that lib to the executable - before we add the other libs.

Okay?

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

FatmaAkdemir — Tue, 10 Nov 2020 12:26:06 GMT

Hi Norbert Thoden, I wanted to thank you because my problem is solved by using your workaround.

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

LucasDanzinger — Tue, 10 Nov 2020 15:53:14 GMT

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

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

EkkaratPrasongsap — Wed, 12 May 2021 03:35:00 GMT

Hi @NorbertThoden,

I'm come from this thread https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/arcgis-runtime-sdk-for-qt-100-10-still-build-error/m-p/1053106#M4083. I was still facing with this issue but I'm less experienced in C++, I just use the basic C programming and never create the libraries by myself.

Can you explain the ArcGISHack build step and provide very sample project implementation this lib for me, Please.

Best Regards,

Aek

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

NorbertThoden — Wed, 12 May 2021 07:33:12 GMT

Hi!

The problem:

The ESRI-library require a symbol (operator delete...), that is unfortunately not available by the Qt-libs provided/shipped with some linux distributions.

Workaround:

We create a very small lib that implemts that missing symbol and use that to fill the gap.

But you ask for a sample: That depends on the build system you are using. The zip file i attached earlier contains all information.And i provided also the resulting output of the compiler.

Our hack contains just a very few lines. But you have to adapt it to your build system. (CMake, Qts pro files or what ever you are using)

Actually we just have a CMake-based hack. Maybe @FatmaAkdemir can provide a pro file?

Your are using Linux Mint 20.1, QT 5.15.2, gcc 9.3.0. That should be more then sufficient. So i recommend that you create and use a library to get experience. Afterwards you could try to create your ArcGisHack matching your system/compiler/Qt-Version.

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

EkkaratPrasongsap — Wed, 12 May 2021 09:30:03 GMT

Hi!,

Thanks you for your suggestion. I'm wonder because I use QT 5.15.2 from my own build from qt git source but the method still missing. I will find more the way to create a small lib in my sample project.

@FatmaAkdemir Can you provide some sample pro file or sample implementation project for me, Please?

Regards,

Aek

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

FatmaAkdemir — Wed, 12 May 2021 09:30:27 GMT

Hi @NorbertThoden , I have used the cmake version did not create a pro file. I might have made some changes in cmake file.