Local symbol '_ZdlPv' is referenced by DSO whilst packaging

I’m working on a project that connects with OpenCV and Torch (which I’ve managed) on Ubuntu 16.04.
I’ve now got everything else linking correctly, and it runs fine in the editor. However, when I attempt to package it, it gives me this error:

local symbol '_ZdlPv' in <path to myproject.cpp.o> is referenced by DSO
final link failed: Bad value

For reference, _ZdlPv demangles to operator delete(void*),
the only time I’ve used void* was for shared library handles, where they are deallocated with FPlatformProcess::FreeDllHandle(handle);

Anyone have an idea about where to go to try and fix this bug?
thanks

edit
the issue seems to be in one of the plugins I wrote to do the loading, which are attached (and are where FPlatformProcess::FreeDllHandle is called - perhaps operator delete void * is being called by some default destructor?)

the plugin can be found here GitHub - thesilencelies/UELuaStuff: UnrealEngine plugin that preloads a set of opencv libs so that they are available at runtime to shared libraries the project connects to. (you’ll have to edit them with the correct values for your setup in the build.cs and main cpp files, as described in the readme)

Hey thesilencelies-

Are you able to package a project that is not using OpenCV / Torch? If that does package, can you provide the setup for how you’re connecting to these two? Please provide the full reproduction steps to help me test the issue locally or, if possible, provide a small sample project demonstrating the package fail error.

that would be an obvious thing to check wouldn’t it… I’ll get on that. I’m connecting to each using a plugin I’ve written that pre-loads the shared libraries based on GitHub - ue4plugins/VlcMedia: Media Framework plug-in using the Video LAN Codec (libvlc).. That should work fine right?

So it won’t package even a fresh project, giving the same error about “Module.UE4Game.cpp.o”. I’ll try a fresh install to see if I can isolate whether it’s to do with the changes I made to the engine,

edit: NONE OF THE BELOW CAUSED THE BUG

but in the meantime I can tell you what I’ve got so you might be able to reproduce it:

on Ubuntu 16.04, with clang 3.8 set as the default compiler and libc++ 3.9 installed from the debian repository;

Unreal engine 4.14.0-0 Release branch.
----fixes some error due to unescaped spaces that I can’t quite remember
rename Unreal Projects to UnrealProjects. In the engine folder call

grep -rlI "Unreal Project" | xargs sed -i 's/Unreal Project/UnrealProject/g'

----allows inclusion of OpenCV header files as it stops namespace collisions

grep -rlI int64 | xargs sed -i 's/int64/int64UR/g'

grep -rlI int64UR_t | xargs sed -i 's/int64UR_t/int64_t/g'

manually apply the changes from: UETorch/UnrealEngine.patch at master · facebookarchive/UETorch · GitHub
to the relevant files.

The plugins I wrote are (obviously) in the engine folder as well, but if I disable them at the project level they shouldn’t affect packaging right?

Ok. fresh build compiles fine until I add my plugins, at which point I get the same error. So none of the horrible hacks above caused the issue, but something about those two. Seeing if I can isolate it to just one of them, then I’ll post the culprit here.

OK, it was just the torch one (which is the necessarry one as well - the lua stuff didn’t work (compiled but then died when ran) until I did this.) see the edit on the question for the code.
on a separate note, why does it not let me deploy using files that are outside of the engine build tree? is there any way around this?

So _ZdlPv is defined in the libc++.a file that ships with UE4. However, I don’t think you can dynamically link to static library functions (hence the DSO error)? Is anyone able to reproduce this one (you should just have to install the above plugin, install torch and point it at torch)? It’s kinda difficult to proceed if I can’t produce optimised code to run…

I would like to learn more about reproducing this error, preferably with stock engine and the smallest change; this may lead us to solution for a long standing problem we have with some third party C++ libs. Also, could you please paste the commandline that results in the error message?

While I don’t have a solution for you, I’ll describe what you may want to try:

  1. Global operator new and delete are defined in each Unreal module (see ModuleBoilerplate.h). You may try to stop overriding them if you want to unblock yourself, but notice that you will be bypassing our malloc for most allocations and the engine memory footprint may change.

  2. All new/delete symbols are made local in a linker version script (see LinuxToolChain.cs). You may want to stop doing this.

  3. Finally, compilation with libc++ can be changed from static to dynamic linking (or to libstdc++). Again, you’d need to modify LinuxToolChain.cs

It is definitely puzzling that operator delete is being referenced from another DSO; I would expect every engine module or plugin to instead use its own version of new/delete from module boilerplate macros.

Those seem like sensible suggestions. The work I was doing that was using UE is currently on ice, so I don’t really have the time right now to do that, but I’ll get onto this as soon as it comes back into scope.