How to integrate an instance of sqlite3 lib without duplicate symbols conflict?

Development Programming & Scripting C++
,
1

I’m integrating a third-party library, that uses static libsqlite3.lib.
I’m trying to integrate it into my plugin using:
PublicAdditionalLibraries.Add

And it works fine in the editor.
But when I’m trying to package a Shipping build, I’m getting a bunch of linker duplicate symbol errors for sqlite functions.

  • The conflicting module is SQLiteCore (it has it’s own integration of sqlite3).
  • SQLiteCore plugin can’t be disabled (I need it enabled).
  • After some attempts to make use of the embedded (into SQLiteCore) sqlite3, I gave up (the set of defines there appeared to be incompatible with what I need).

I tried to play with building the custom version of the SQLiteCore module with the needed options and copying it to the installed UE folder. But probably I’m doing something wrong, and hence getting a weird error.

[2025.01.21-20.34.17:650][530]UATHelper: Packaging (Windows): Module.SQLiteCore.cpp.obj : error LNK2011: precompiled object not linked in; image may not run
[2025.01.21-20.34.17:650][530]UATHelper: Packaging (Windows):   Hint on symbols that are defined and could potentially match:
[2025.01.21-20.34.17:650][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UkilqvxghUwzixbRvwvmRkilqvxgUhixUrmgvinvwrzgvUyfrowUdrmGEUcGEUvwvmxznkfhhrnUhsrkkrmtUvmtrmvUhszivwkxsOvmtrmvOvcxvkgrlmhOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:650][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UkilqvxghUwzixbRvwvmRkilqvxgUhixUrmgvinvwrzgvUyfrowUdrmGEUcGEUvwvmxznkfhhrnUhsrkkrmtUvmtrmvUhszivwkxsOvmtrmvOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UwveUtucUlfgkfgUwfnkGEUwDwvcgUrtucPvcgPoryOwriUivovzhvUhgwzucPoryOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUkoftrmhUifmgrnvUivhlmzmxvzfwrlUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUivhlmzmxvzfwrlUkxsOivhlmzmxvzfwrlOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUhozgvUhszivwkxsOhozgvOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUvmtrmvUhszivwkxsOvmtrmvOiggrOvcxvkgrlmhOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUvmtrmvUhszivwkxsOvmtrmvOvcxvkgrlmhOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUvmtrmvUhszivwkxsOvmtrmvOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUvmtrmvUkxsOvmtrmvOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivUhszivwkxsOxlivOiggrOvcxvkgrlmhOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivUhszivwkxsOxlivOvcxvkgrlmhOxkkBHOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivUhszivwkxsOxlivOvcxvkgrlmhOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivUhszivwkxsOxlivOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivUkxsOxlivOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivflyqvxgUhszivwkxsOxlivflyqvxgOxkkCAOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UyfrowUQQfvFUhbmxUvmtrmvUrmgvinvwrzgvUyfrowUdrmGEUcGEUfmivzotznvUhsrkkrmtUxlivflyqvxgUkxsOxlivflyqvxgOsOlyq@4B2008FD98C1DD4
[2025.01.21-20.34.17:651][530]UATHelper: Packaging (Windows):     __@@_PchSym_@00@UzUPdlipUBUhUrmgvinvwrzgvUexHoryhUhsrkUzgonuxUhixUzgoUzgohUzgohOmzgrevkilqUlyqiPiUznwGEUhgwzucOlyq@4B2008FD98C1DD4

The error seem to be related to the precompiled headers, but disabling the use of them in the SQLiteCore.Build.cs doesn’t seem to fix it.

So what’s the best way to integrate a separate version of the conflicting (with the engine embedded plugins) third-party static lib (in my case sqlite3)?

2

Just in case someone stumbles upon the same issue, until the sqlite3 is moved to the Thirdparty libs, I post my solution.

I didn’t want to modify the engine code, so the only way to resolve the linker conflict appeared to be: to make the sqlite3 a shared lib. It sounds ridiculously simple, but it wasn’t obvious to me at all.

The reason why it worked is in the way the symbols are named: the naming schemes are slightly different for the static and shared libs (thanks to the __declspec(dllimport) declarator used with the shared lib). As UE’s version is compiled to be linked statically, my shared lib symbols appeared to be different, which worked like a charm.

I wouldn’t have any troubles if UE had a more or less recent version of sqlite3 as a Thirdparty lib (and not embedded into the module).