What can linking to a CMake target impact?

-1

I ran into an interesting problem today. I am trying to compile and link a test executable to the Boost unit test framework and I tried it in two different ways.

The classic approach of linking directly to the "boost_unit_test_framework" library using -lboost_unit_test_framework

The modern CMake approach of linking to the Boost::unit_test_framework CMake target.

Interestingly when I link to the library directly my code compiles and links fine; however when I link to the CMake target my code fails to compile before it even gets to the linking stage!

The errors I get are related to a header file that it suddenly can't seem to find anymore. This suggests that linking to the Boost::unit_test_framework somehow messed with my include path.

I know linking to a CMake target is supposed to be the more modern and preferred approach, but if it can have such unexpected and unexplainable side effects, it seems worse than just linking straight to the library...

Why would linking the CMake target cause header files to not be found anymore? Also what other kinds of things can linking to a CMake target instead of linking directly to a library impact?

In both scenarios I am using target_link_libraries to link to the boost library. For example

target_link_libraries(mytest_exe

    testlib

    -lboost_unit_test_framework

)

target_link_libraries(mytest_exe

    testlib

    Boost::unit_test_framework

)

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

2

"my code fails to compile before it even gets to the linking stage" - Please post your exact compiler errors. As well as information on what compiler (and version) you are using. A Minimal, Complete, and Verifiable example would be best.

– Jesper Juhl
Jan 18 at 19:44

your code can only fail to compile before linking, linking comes after compilation ;)

– user463035818
Jan 18 at 19:46

I cannot post the exact compiler errors for security reasons. I can, however state that it is missing things that are defined in one of the header files it uses. That should be all the info needed to answer the actual question of "What can linking to a CMake target impact?". I'm not asking why my specific example fails to compile. I'm asking what impact linking to a CMake target can have.

– tjwrona1992
Jan 18 at 19:51

@user463035818 The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well. My question is why would target_link_libraries effect the compilation? It doesn't seem intuitive.

– tjwrona1992
Jan 18 at 19:55

if you cannot post the exact messages of the original code you should prepare a Minimal, Complete, and Verifiable example, something that is not confidential and reprocudes the problem

– user463035818
Jan 18 at 19:57

|
show 5 more comments

-1

I ran into an interesting problem today. I am trying to compile and link a test executable to the Boost unit test framework and I tried it in two different ways.

The classic approach of linking directly to the "boost_unit_test_framework" library using -lboost_unit_test_framework

The modern CMake approach of linking to the Boost::unit_test_framework CMake target.

Interestingly when I link to the library directly my code compiles and links fine; however when I link to the CMake target my code fails to compile before it even gets to the linking stage!

The errors I get are related to a header file that it suddenly can't seem to find anymore. This suggests that linking to the Boost::unit_test_framework somehow messed with my include path.

Why would linking the CMake target cause header files to not be found anymore? Also what other kinds of things can linking to a CMake target instead of linking directly to a library impact?

In both scenarios I am using target_link_libraries to link to the boost library. For example

target_link_libraries(mytest_exe

    testlib

    -lboost_unit_test_framework

)

target_link_libraries(mytest_exe

    testlib

    Boost::unit_test_framework

)

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

2

"my code fails to compile before it even gets to the linking stage" - Please post your exact compiler errors. As well as information on what compiler (and version) you are using. A Minimal, Complete, and Verifiable example would be best.

– Jesper Juhl
Jan 18 at 19:44

your code can only fail to compile before linking, linking comes after compilation ;)

– user463035818
Jan 18 at 19:46

I cannot post the exact compiler errors for security reasons. I can, however state that it is missing things that are defined in one of the header files it uses. That should be all the info needed to answer the actual question of "What can linking to a CMake target impact?". I'm not asking why my specific example fails to compile. I'm asking what impact linking to a CMake target can have.

– tjwrona1992
Jan 18 at 19:51

@user463035818 The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well. My question is why would target_link_libraries effect the compilation? It doesn't seem intuitive.

– tjwrona1992
Jan 18 at 19:55

if you cannot post the exact messages of the original code you should prepare a Minimal, Complete, and Verifiable example, something that is not confidential and reprocudes the problem

– user463035818
Jan 18 at 19:57

|
show 5 more comments

-1

I ran into an interesting problem today. I am trying to compile and link a test executable to the Boost unit test framework and I tried it in two different ways.

The classic approach of linking directly to the "boost_unit_test_framework" library using -lboost_unit_test_framework

The modern CMake approach of linking to the Boost::unit_test_framework CMake target.

Interestingly when I link to the library directly my code compiles and links fine; however when I link to the CMake target my code fails to compile before it even gets to the linking stage!

The errors I get are related to a header file that it suddenly can't seem to find anymore. This suggests that linking to the Boost::unit_test_framework somehow messed with my include path.

Why would linking the CMake target cause header files to not be found anymore? Also what other kinds of things can linking to a CMake target instead of linking directly to a library impact?

In both scenarios I am using target_link_libraries to link to the boost library. For example

target_link_libraries(mytest_exe

    testlib

    -lboost_unit_test_framework

)

target_link_libraries(mytest_exe

    testlib

    Boost::unit_test_framework

)

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

I ran into an interesting problem today. I am trying to compile and link a test executable to the Boost unit test framework and I tried it in two different ways.

The classic approach of linking directly to the "boost_unit_test_framework" library using -lboost_unit_test_framework

The modern CMake approach of linking to the Boost::unit_test_framework CMake target.

Interestingly when I link to the library directly my code compiles and links fine; however when I link to the CMake target my code fails to compile before it even gets to the linking stage!

The errors I get are related to a header file that it suddenly can't seem to find anymore. This suggests that linking to the Boost::unit_test_framework somehow messed with my include path.

Why would linking the CMake target cause header files to not be found anymore? Also what other kinds of things can linking to a CMake target instead of linking directly to a library impact?

In both scenarios I am using target_link_libraries to link to the boost library. For example

target_link_libraries(mytest_exe

    testlib

    -lboost_unit_test_framework

)

target_link_libraries(mytest_exe

    testlib

    Boost::unit_test_framework

)

c++ boost cmake linker include-path

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

edited Jan 18 at 20:05

asked Jan 18 at 19:41

tjwrona1992

3,92421647

asked Jan 18 at 19:41

tjwrona1992

3,92421647

asked Jan 18 at 19:41

tjwrona1992

3,92421647

2

"my code fails to compile before it even gets to the linking stage" - Please post your exact compiler errors. As well as information on what compiler (and version) you are using. A Minimal, Complete, and Verifiable example would be best.

– Jesper Juhl
Jan 18 at 19:44

your code can only fail to compile before linking, linking comes after compilation ;)

– user463035818
Jan 18 at 19:46

I cannot post the exact compiler errors for security reasons. I can, however state that it is missing things that are defined in one of the header files it uses. That should be all the info needed to answer the actual question of "What can linking to a CMake target impact?". I'm not asking why my specific example fails to compile. I'm asking what impact linking to a CMake target can have.

– tjwrona1992
Jan 18 at 19:51

@user463035818 The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well. My question is why would target_link_libraries effect the compilation? It doesn't seem intuitive.

– tjwrona1992
Jan 18 at 19:55

if you cannot post the exact messages of the original code you should prepare a Minimal, Complete, and Verifiable example, something that is not confidential and reprocudes the problem

– user463035818
Jan 18 at 19:57

|
show 5 more comments

2

"my code fails to compile before it even gets to the linking stage" - Please post your exact compiler errors. As well as information on what compiler (and version) you are using. A Minimal, Complete, and Verifiable example would be best.

– Jesper Juhl
Jan 18 at 19:44

your code can only fail to compile before linking, linking comes after compilation ;)

– user463035818
Jan 18 at 19:46

I cannot post the exact compiler errors for security reasons. I can, however state that it is missing things that are defined in one of the header files it uses. That should be all the info needed to answer the actual question of "What can linking to a CMake target impact?". I'm not asking why my specific example fails to compile. I'm asking what impact linking to a CMake target can have.

– tjwrona1992
Jan 18 at 19:51

@user463035818 The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well. My question is why would target_link_libraries effect the compilation? It doesn't seem intuitive.

– tjwrona1992
Jan 18 at 19:55

if you cannot post the exact messages of the original code you should prepare a Minimal, Complete, and Verifiable example, something that is not confidential and reprocudes the problem

– user463035818
Jan 18 at 19:57

"my code fails to compile before it even gets to the linking stage" - Please post your exact compiler errors. As well as information on what compiler (and version) you are using. A Minimal, Complete, and Verifiable example would be best.

– Jesper Juhl
Jan 18 at 19:44

your code can only fail to compile before linking, linking comes after compilation ;)

– user463035818
Jan 18 at 19:46

I cannot post the exact compiler errors for security reasons. I can, however state that it is missing things that are defined in one of the header files it uses. That should be all the info needed to answer the actual question of "What can linking to a CMake target impact?". I'm not asking why my specific example fails to compile. I'm asking what impact linking to a CMake target can have.

– tjwrona1992
Jan 18 at 19:51

@user463035818 The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well. My question is why would target_link_libraries effect the compilation? It doesn't seem intuitive.

– tjwrona1992
Jan 18 at 19:55

if you cannot post the exact messages of the original code you should prepare a Minimal, Complete, and Verifiable example, something that is not confidential and reprocudes the problem

– user463035818
Jan 18 at 19:57

|
show 5 more comments

1 Answer
1

active

oldest

votes

The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well.

Yes, it is true that new include directories are added when you link with a library target instead of the library file. This is why the approach is called "modern" - a single target_link_libraries call does all things which are needed to use the library (Boost in your case).

Reason of failing with "modern" approach could be that "true" Boost headers conflict with other headers you use. You may detect that via inspecting chain of include files in the error message.

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54260457%2fwhat-can-linking-to-a-cmake-target-impact%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well.

Reason of failing with "modern" approach could be that "true" Boost headers conflict with other headers you use. You may detect that via inspecting chain of include files in the error message.

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

add a comment |

The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well.

Reason of failing with "modern" approach could be that "true" Boost headers conflict with other headers you use. You may detect that via inspecting chain of include files in the error message.

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

add a comment |

The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well.

Reason of failing with "modern" approach could be that "true" Boost headers conflict with other headers you use. You may detect that via inspecting chain of include files in the error message.

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

The fact that it is failing before linking means that the target_link_libraries command in CMake actually effects more than just linking. It is effecting the compilation as well.

Reason of failing with "modern" approach could be that "true" Boost headers conflict with other headers you use. You may detect that via inspecting chain of include files in the error message.

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

edited yesterday

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

answered Jan 18 at 20:00

Tsyvarev

26.2k42661

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

add a comment |

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

Thanks @Tsyvarev, oddly none of the errors mention any boost header files, and even printing the list of include paths before and after the call to target_link_libraries produces the same list of paths. At this point I'm still not sure what it modified, but I will keep looking in this direction.

– tjwrona1992
Jan 18 at 20:03

Hm, I am not sure, but unit_test_framework could add not only include directories, but also compile definitions. (Linking with a target may modify almost any compiler option). Actually, you may compare compiler command lines in both cases to see a difference.

– Tsyvarev
Jan 18 at 20:10

good idea! I'll run make VERBOSE=1 in both cases and diff the outputs to see what flags and compiler options might differ

– tjwrona1992
Jan 18 at 20:15

Solved it! Sure enough it was modifying the include paths, it moved one of them to later in the list of include paths. That should not have been a problem, but some knucklehead decided it would be a good idea to put include_directories(".") in our main CMake script that all our code uses. This caused my current directory to be treated as a "system" directory. This meant that #include <someheader.h> looked in my own project for someheader.h and pulled that in when it should have only looked in the system header files for it...

– tjwrona1992
Jan 18 at 20:27

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Brtdku