Insights after hours of beating my head against the desk - so you don't have to.
Writing C++ Shared Libraries for Linux
Get link
Facebook
X
Pinterest
Email
Other Apps
-
I've recently been getting an old Windows-only module cross compiling for Linux. One of the challenges has been figuring out how to make the consuming project find & properly open the .so file. Most posts suggest that you must put your libraries in a specific folder, but a developer friend with stronger Linux kung-fu than mine confirmed that you can simply drop the .so files in the same directory as your application, & consume them using dlopen.
Here's a couple examples: first, a trivial hello world to show the basic consumption, and second, an example of what a reusable interface might look like. The latter shows how to use custom parameter & return types. I am new to designing C interfaces and deploying on Linux, so any comments are welcome.
Hello World from a Linux shared library:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
target_link_libraries(ConsumingProject "${CMAKE_DL_LIBS}") #Allows us to include dlfcn.h to link shared (dynamic) libraries
endif()
find_library(SHARED_LIB_LOCATION SharedLib PATHS ${CMAKE_BINARY_DIR}) #Assumes library's .so files have been copied into the same directory as this file
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
target_link_libraries(ConsumingProject "${CMAKE_DL_LIBS}") #Allows us to include dlfcn.h to link shared (dynamic) libraries
endif()
find_library(SHARED_LIB_LOCATION SharedLib PATHS ${CMAKE_BINARY_DIR}) #Assumes library's .so files have been copied into the same directory as this file
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I've been implementing Conan as our C++ package manager, and I had the following issue cause me a fair amount of grief over the last couple days: [MyPackageName] is locked by another concurrent conan process, wait... If not the case, quit, and do 'conan remove --locks' You would be forgiven for thinking conan remove --locks should do the trick, but alas, it does not. After finding hints on several Conan Github issues, I finally figured out that manually removing the package folders in one or both of the following places will alleviate the issue: Windows : C:\Users\username\.conan\data\packagename WSL/Linux : /home/username/.conan/data/packagename
Pointers are funny things. They are one of the make or break concepts for beginners, and even years later, they can cause grief to experienced developers. I am no exception. Here is one such story: I was faced with a class which I wanted to refactor. It can be simplified as follows: In the interest of breaking up the responsibilities, I added a couple of interfaces. The idea is that I can pass around smart pointers to these interfaces and begin to decouple portions of the code. For example, I can inject them into classes that need them: However, I made a mistake. I blame it on years of using boost::intrustive_ptr instead of std::shared_ptr, but enough excuses. Let's see if you can spot it. Do you see it? If so, give yourself 5 points. If not, maybe after seeing the output: 'second' going out of scope... Destructor 'first' going out of scope... 'root' going out of scope... All done... Both shared pointers ( first & second ) are ...
You start out your day with a nice cup of coffee, and think, "Ah, greenfield project day...smooth sailing". You fire up Visual Studio and create a new C# project. "First things first, I need library X." you say. "Wait, what the?" The full error: Package 'MyPackage 1.0.0.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project. "Ok" you think, "That library is a bit older. I'll go update the library project to .NET 6 to match my project. But, where is .NET 6? "Ok, what about my new project? Just as a test, does the warning go away if I set it to an older .NET Framework? Wait, where are the .NET Framework versions?...
Comments
Post a Comment