this question has answer here:
i have c++ project divided multiple library targets , 1 executable target. i've been dynamically linking libraries , trying switch static linking running "undefined reference" errors.
one of errors involved class named effect, in library named shading. library typography has class named type_effect, derived effect. when processing typography linker cannot find symbols effect class.
i verified libraries being included so:
.../shading/libshading.a .../typography/libtypography.a ... i ran linker -verbose command , part of output shading was:
attempt open .../shading/libshading.a succeeded (.../shading/libshading.a)shader_manager.cpp.obj (.../shading/libshading.a)shader.cpp.obj (.../shading/libshading.a)program.cpp.obj effect.cpp.obj missing. checked shading.a file , did include effect.cpp , of related effect symbols. next, added dummy code creating effect object main executable cpp file, , sure enough linker output included:
([...]/shading/libshading.a)effect.cpp.obj alternatively, preceeding linklibs.rsp --whole-archive forced linker load effect.cpp.obj, loading introduces other problems beyond scope of question.
the evidence points breakdown in linker determining object files include. shading library not directly used in main executable target, presence of shader objects being loaded indicates @ least of dependency tracing working.
in ld flag documentation --whole-archive, mentions how flag
include[s] every object file in archive in link, rather searching archive required object files.
what of logic behind searching? factors make or break it?
the logic missing when static linking, ld loads object file archive when object file contains definitions unresolved symbols ld knows loaded object files.
why order in libraries linked cause errors in gcc?
thus, ld input needs ordered dependents dependencies. typography library needed listed before shading library. had backwards.
Comments
Post a Comment