I am building a fairly simple C++ program that depends upon the POCO library, statically linked, and my release build contains file path strings to all of the POCO headers and .cpp files that are used in the compilation. The executable is stripped, there are no debug symbols.
I am building with CMake, using Conan to manage dependencies. Inspecting the POCO object files in the Conan cache reveal that the strings are contained in those object files (no surprise there). None of the other Conan-manged deps used in my code have this problem, they all respect the Release profile.
Example:
/home/rob/.conan2/p/b/pocoe6011659302fc/p/include/Poco/Dynamic/VarHolder.h
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/NetSSL_OpenSSL/src/Context.cpp
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/Foundation/include/Poco/ScopedLock.h
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/Util/include/Poco/Util/Application.h
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/NetSSL_OpenSSL/src/SSLManager.cpp
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/NetSSL_OpenSSL/src/SecureSocketImpl.cpp
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/NetSSL_OpenSSL/src/SecureStreamSocketImpl.cpp
/home/rob/.conan2/p/b/pocoe6011659302fc/b/src/Foundation/include/Poco/String.h
I stripped and examined the debug executable for comparison, and found paths to other dependencies, which verified that Conan is recognizing the debug and release profiles appropriately, this is specific to POCO. In my research, I found the following:
Note that poco_assert, poco_check_ptr and poco_bugcheck are
enabled both in debug and in release builds.
This seems to be a likely cause of the problem, but if so, I’m not sure of I’m just out of luck, or if there is some special POCO way of dealing with this that I have not discovered yet.
I’m fairly new to C++, so I may be missing something obvious. Should I stop worrying and learn to love having my filesystem paths baked into an executable that I intend to distribute? It feels wrong.
Any insight would be appreciated.