Build library along with its dependencies in CMake

[trail rock]

Suppose I have my library like this:

# Library
add_library(
 MK
 SHARED
 Core.cpp
 Graphics.cpp
)

# Linking Dependencies
target_link_libraries(MK PUBLIC ${GLEW_LIB})
target_link_libraries(MK PUBLIC ${GLFW_LIB})
if(BUILD_FOR_WINDOWS)
 target_link_libraries(MK PUBLIC gdi32 user32 kernel32 opengl32)
 target_link_libraries(MK PUBLIC -static -static-libgcc -static-libstdc++ -mwindows)
else()
 target_link_libraries(MK PUBLIC GL)
endif()

That created the libMK.so file in my build directory. When I try to use it with the includes like this:

g++ Main.cpp -L./libMK.so -I include

It results into a lot of undefined reference errors as seen in my included image. An idea what could be wrong here?

[hollow mica]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[vocal slate]

you didn't pass the needed .so files to g++

[dire grotto]

It's the transitive dep that is the issue

You can solve this by including the library as a subdirectory of your main project (easier) or making some kind of MKConfig.cmake in a directory cmake knows to look (harder, plus I've never done it)

Also those static flags should be in target_link_options since they aren't libraries

It looks like the main issue is you are trying to build directly with g++ when it should be defined as more cmake

Either that or you add the link options for the other libs you are using (namely GL) by hand

[dire grotto]

I was a bit misled by the title of your post, this would have worked just fine if your executable (main.cpp) was also using cmake. Don't use raw g++ and expect it to know anything about your cmake definitions

Since this is a shared library I have to ask if you used the appropriate public attribute for gcc in the header, symbols are private by default which means they won't be seen by a dependent program

[languid latch]

Drink the cmake kool-aid

[dire grotto]

Cmake: when you're here, you're stuck with it

Unfortunately that tagline got rejected for some reason

[trail rock]

Oh, I thought the dependencies would the part of libMK.so.

[trail rock]

Wait, so that means exporting it with CMake means that using it requires CMake?

[dire grotto]

Only if you want the indirect dependencies (GL) to be figured out for you

[vocal slate]

can't we just, do this the old fashined GNU make way, and manually pass the extra compile args and manually pass the extra linker directories and extra linker dynamic library file names?

[dire grotto]

Yes and I said that as an option earlier

[vocal slate]

in Cmake decrypting what shell variables are there is so tedious

[dire grotto]

Aka "do it yourself"

Cmake isn't shell

[vocal slate]

so, what exactly does the add_library function do, and where did the Cmake variable ${GLEW_LIB} come from?

[dire grotto]

Add_library declares a library, GLEW_LIB came from find_package. Both of those are well documented

[vocal slate]

^ last time I read Cmake docs I had a more miserable time than reading MSDN docs about WIndows API stuff

[dire grotto]

I have no issue with most of the individual function docs, high level docs kinda suck though

FetchContent docs are very incomplete and you just have to know to check the additional flags from ExternalProject

I'm not gonna say cmake is good or anything