0

We've been struggling with this issue for some time and, well, it sounds weird. This isn't a general undefined reference question, because for some compilers this definitely works, for the one I'm asking here it doesn't.

Let's say, we have some constants, an ìnt, a char const* const and a std::string. They are all declared extern in a header file and instantiated in a source file. And finally used in a main.

my_file.hpp:

#include <string>

extern int my_int;
extern char const* const my_c_str;
extern std::string const my_string;

my_file.cpp

#include "my_file.hpp"
int my_int = 42;
char const* const my_c_str = "foo-bar";
std::string const my_string = "bar...foo";

main.cpp

#include "my_file.hpp"
#include <iostream>
int main()
{
  std::cout << my_int << std::endl;
  std::cout << my_c_str << std::endl;
  std::cout << my_string << std::endl;
  return 0;
}

And yes, both object files are used for linking the final executable using a CMake file like this:

cmake_minimum_required(VERSION 3.20 FATAL_ERROR)
project(test)

add_executable(my_extern_test
  my_file.cpp
  main.cpp
)

With gcc/clang/MinGW, there is no issue with that, I've used it over and over again. On MSVC however we get the error "unresolved external symbol" for my_string - not for the other variables.

To make it more precise:

  • For basic C types it works
  • For C++ stl-types it doesn't work

If I remove the use of the stl-type object in the main-function, it compiles as well.

The offending compiler is MSVC 14.31-17.2.

We use a workaround, so it is not a critical issue for us, but out of interest, I'd like to ask: Is there a bug in this very compiler-version?

Edit: made question more explicit, added remark about CMake.

PS: Wouldn't be the first, couldn't yet make pimpl work with std::unique_ptr, as they do for MinGW/gcc or clang.

tooEarlyToGetUp
  • 113
  • 7
  • 1
    The [code compiles with both `GCC` and `MSVC`](https://godbolt.org/z/P7KhMzME5) – The Dreams Wind Sep 01 '22 at 09:15
  • 2
    *"And yes, both object files are used for linking the final executable."* -- I do not believe this unsubstantiated claim. Do you have supporting evidence? Perhaps the command that is used to link? That would be more convincing than just your assessment. – JaMiT Sep 01 '22 at 09:18
  • "Is there a bug in the compiler?" - Most likely not. That's very rarely the case. But for some reason, beginners often think that - in almost every case it's the programmer not knowing how to use the tools correctly or write the code correctly. – Jesper Juhl Sep 01 '22 at 10:05
  • It is really nice to be put down like that, seriously! The compiler was MSVC 14.31-17.2. The code you see above was part of a bigger CMake project, which was built with MSVC and MinGW. With MinGW it compiled and linked, with the mentioned MSVC version it didn't. If we comment the last ```std::cout``` line in main, it builds with both. That's what we observed. I just had the humble question whether someone else observed that as well. Thanks for nothing! – tooEarlyToGetUp Sep 01 '22 at 14:05
  • *"This **isn't** a general undefined reference question, because for some compilers this definitely works, for the one I'm asking here it doesn't."* -- This reason is insufficient to justify the conclusion. The success of some compilers provides a strong indication that the problem *likely* does not lie in the code, but it implies nothing about whether or not not a different compiler was invoked correctly. *(Note that I am not claiming that your conclusion is definitely wrong, only that your justification is inadequate.)* – JaMiT Sep 03 '22 at 12:16
  • *"We use a workaround,"* -- Workarounds can be useful debugging tools, but only if the details are known. There seems to be a pattern here where you are only willing to share conclusions instead of the observations that led to the conclusions. That's acceptable only if your conclusions are trustworthy. The test for your conclusions being trustworthy is whether or not they lead to an answer. Have your conclusions led you to an answer? If so, please post it. If not, your conclusions are inherently suspect. *Rule X of debugging: distrust everything!* – JaMiT Sep 03 '22 at 12:30

0 Answers0