Link error at random points

[frbitten]

Hi
I'm experiencing some link errors similar to the error below:

> NeaEngineClient.obj : error LNK2019: unresolved external symbol, "public: __cdecl Auxiliary::Encoder_Decoder::Data::ParameterValuesData::ParameterValuesData(class nlohmann::basic_json<class std::map,class std::vector,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,bool,__int64,unsigned __int64,double,class std::allocator,struct nlohmann::adl_serializer,class std::vector<unsigned char,class std::allocator<unsigned char> > >)" (??0ParameterValuesData@Data@Encoder_Decoder@Auxiliary@@QEAA@V?$basic_json@Vmap@std@@Vvector@2@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@_N_J_KNVallocator@2@Uadl_serializer@nlohmann@@V?$vector@EV?$allocator@E@std@@@2@@nlohmann@@@Z), referenced in the function "void __cdecl std::_Construct_in_place<class Auxiliary::Encoder_Decoder::Data::ParameterValuesData,class nlohmann::detail::iteration_proxy_value<class nlohmann::detail::iter_impl<class nlohmann::basic_json<class std::map,class std::vector,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,bool,__int64,unsigned __int64,double,class std::allocator,struct nlohmann::adl_serializer,class std::vector<unsigned char,class std::allocator<unsigned char> > > > > &>(class Auxiliary::Encoder_Decoder::Data::ParameterValuesData &,class nlohmann::detail::iteration_proxy_value<class nlohmann::detail::iter_impl<class nlohmann::basic_json<class std::map,class std::vector,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,bool,__int64,unsigned __int64,double,class std::allocator,struct nlohmann::adl_serializer,class std::vector<unsigned char,class std::allocator<unsigned char> > > > > &)" (??$_Construct_in_place@VParameterValuesData@Data@Encoder_Decoder@Auxiliary@@AEAV?$iteration_proxy_value@V?$iter_impl@V?$basic_json@Vmap@std@@Vvector@2@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@_N_J_KNVallocator@2@Uadl_serializer@nlohmann@@V?$vector@EV?$allocator@E@std@@@2@@nlohmann@@@detail@nlohmann@@@detail@nlohmann@@@std@@YAXAEAVParameterValuesData@Data@Encoder_Decoder@Auxiliary@@AEAV?$iteration_proxy_value@V?$iter_impl@V?$basic_json@Vmap@std@@Vvector@2@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@_N_J_KNVallocator@2@Uadl_serializer@nlohmann@@V?$vector@EV?$allocator@E@std@@@2@@nlohmann@@@detail@nlohmann@@@detail@nlohmann@@@Z)

The error occurs in the constructor of this class:

class ParameterValuesData
            {
            public:
                ParameterValuesData(std::shared_ptr<Variables::IVariable> variable);
                ParameterValuesData(nlohmann::json json);
                ~ParameterValuesData();

                std::string getDataType();
                std::string getName();
                std::string getType();
                std::string getExpression();
                std::vector<int> getIndexMatrix();

                std::string getIO();
                int getOrder();
                std::string getValueSimple();
                std::string getValueVariableName();
                std::vector<std::shared_ptr<ParameterValuesData>> getValues();

                bool isSimple();
                bool isCollection();
                bool isExpression();
                bool isVariable();
                bool isInput();
                bool isOutput();

                std::shared_ptr<Variables::IVariable> generateIVariable(std::shared_ptr<Managers::VariablesManager> wfVarMan);

            private:
                std::string dataType;
                std::string name;
                std::string type;
                std::string io;
                std::string value;
                std::vector<std::shared_ptr<ParameterValuesData>> values;
            };

This class is used in several objects in the project and they all compile normally. However, in one specific object (NeaEngineClient.obj), this link error appears.

I've seen this problem occur in several points of the project, always in methods that return JSON or methods that receive JSON as a parameter. I couldn't identify the reason.

I would like to know if anyone has experienced this and has any suggestions as to what it could be.

If you remove "nlohmann::json json" from the constructor and replace it with "std::string", everything compiles normally.

Thanks

[skhaz]

You declared this constructor in the class:

ParameterValuesData(nlohmann::json json);

But if you do not provide a definition (i.e. an actual implementation of this constructor) somewhere in your .cpp file, or forget to compile that file into the project, the linker will fail. This is true even if other constructors are defined and used elsewhere.

Furthermore, this issue only happens in translation units that reference that specific constructor, which explains why most of your project compiles normally and only fails on NeaEngineClient.obj.

[frbitten]

You declared this constructor in the class:

ParameterValuesData(nlohmann::json json);

But if you do not provide a definition (i.e. an actual implementation of this constructor) somewhere in your .cpp file, or forget to compile that file into the project, the linker will fail. This is true even if other constructors are defined and used elsewhere.

Furthermore, this issue only happens in translation units that reference that specific constructor, which explains why most of your project compiles normally and only fails on NeaEngineClient.obj.

Yes, the constructor has an implementation in the cpp and is being compiled. This class is used in many places with the same constructor. But only in this obj does it give a link error.

My first suspicion was the order of the link, but I've already changed it and it didn't work. And as always happens with nlohmann/json, I imagine it's some feature of this library that I'm not familiar with.

I have the impression that the nlohmann::json type is a typedef for a more complex type and in some cases the compiler mounts this more complex type differently and this makes it think that the method doesn't exist.

[nlohmann]

The <nlohmann/json_fwd.hpp> can be used to forward-declare types from the library. It's smaller than <nlohmann/json.hpp> and suited for headers.

[gregmarr]

ParameterValuesData(class nlohmann::basic_json<class std::map,class std::vector,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,bool,__int64,unsigned __int64,double,class std::allocator,struct nlohmann::adl_serializer,class std::vector<unsigned char,class std::allocator<unsigned char> > >

Looks like you are not using the latest headers, and/or you have multiple versions of the headers installed.
The actual type for the latest version is something of the form nlohmann::json_abi_v3_12_0::basic_json<...>

If you are using an old version of the header (pre v3.11.0) in NeaEngineClient.cpp and a newer version of the header (v3.11.0 or later) in the file where ParameterValuesData(nlohmann::json) is implemented, you would get this exact error, precisely to avoid the ODR violations that this causes.

[frbitten]

ParameterValuesData(class nlohmann::basic_json<class std::map,class std::vector,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,bool,__int64,unsigned __int64,double,class std::allocator,struct nlohmann::adl_serializer,class std::vector<unsigned char,class std::allocator<unsigned char> > >

Looks like you are not using the latest headers, and/or you have multiple versions of the headers installed. The actual type for the latest version is something of the form nlohmann::json_abi_v3_12_0::basic_json<...>

If you are using an old version of the header (pre v3.11.0) in NeaEngineClient.cpp and a newer version of the header (v3.11.0 or later) in the file where ParameterValuesData(nlohmann::json) is implemented, you would get this exact error, precisely to avoid the ODR violations that this causes.

I only have one version added as a dependency. In this case, I updated to 3.12 this week to see if it would solve the problem. But it didn't.

I use dozens of other dependencies and I don't know if any of them use an older version.
All uses are indicated as nlohmann::json. Is there any way to force the choice of the latest version?

[gregmarr]

You would probably have to hardcode the desired version in your header file, something like this (with a good error message):

static_assert(NLOHMANN_JSON_VERSION_MAJOR == 3)
static_assert(NLOHMANN_JSON_VERSION_MINOR == 12)
static_assert(NLOHMANN_JSON_VERSION_PATCH == 0)

[frbitten]

@gregmarr @nlohmann
I think I found the problem. The libhv library that I use in the project uses version 3.9.1
It includes in the library's include folder the json.hpp of version 3.9.1

Is there a way to indicate that in my code I want to use 3.12.0?

[gregmarr]

Is it including the json.hpp in an nlohmann folder? If it not, and it's just directly under the libhv folder, or directly in the include folder, you can be sure to include your desired version as nlohmann/json.hpp. Otherwise, just the static assert from above is I think the only way to keep a pre-3.11.0 version from being used alongside a 3.11.0 or later version.

[frbitten]

Is it including the json.hpp in an nlohmann folder? If it not, and it's just directly under the libhv folder, or directly in the include folder, you can be sure to include your desired version as nlohmann/json.hpp. Otherwise, just the static assert from above is I think the only way to keep a pre-3.11.0 version from being used alongside a 3.11.0 or later version.

The json.hpp is inside the libhv include folder that is added to my project's include dir list. When including libhv includes, it internally includes json.hpp from version 3.9.1 and with that I end up having two json.hpp included at the same time.

I always use nlohmann/json.hpp in the includes but libhv is using json.hpp directly.

I didn't understand how to use static_assert, because it gives an error that the constants NLOHMANN_JSON_VERSION_MAJOR , NLOHMANN_JSON_VERSION_MINOR and NLOHMANN_JSON_VERSION_PATCH do not exist.

[gregmarr]

You should be able to put that after you include the library. If they don't exist, then I think that means that you got the old header.

Update: nope, they exist in that version too.

Having 3.9.1 and 3.12.0 included at the same time is not necessarily a bad thing, as long as those sections don't interact with the same objects. If you have two different versions before 3.11.0 then it's a problem even if they don't interact because they define the same types in the same namespace.

The problem in your case happens if you have a file that includes 3.9.1, then the definition of ParameterValuesData, and then uses the ParameterValuesData constructor that takes nlohmann::json. Because the file that contains the definition of the constructor uses 3.12.0, the constructor won't be found with the 3.9.1 type name, only the 3.12.0 type name.

[gregmarr]

Basically, 3.9.1 defines nlohmann::basic_json<>, and 3.12.0 defines nlohmann::json_abi_v3_12_0::basic_json<> but json_abi_v3_12_0 is an inline namespace, meaning that anything inside it is automatically brought into the upper namespace for name lookup. That means that you can still reference nlohmann::basic_json<> in your code, but the actual type system reference is to nlohmann::json_abi_v3_12_0::basic_json<>. That prevents ODR violations in the library itself from having two different version headers included. It also prevents the ParameterValuesData constructor from attempting to work on an object of a different basic_json<> format.

[frbitten]

Well, I tried several definition options. Using the 3.12.0 namespace define or using nlohmann::json_abi_v3_12_0::basic_json directly. But both gave compilation errors.

After several tests, I discovered what causes the problem. If I include a libhv header before nlohmann/json.hpp, json.hpp (3.9.1) is used, which is inside libhv, and therefore nlohmann/json.hpp is ignored because INCLUDE_NLOHMANN_JSON_HPP_ is already defined.

I solved it by ensuring that nlohmann/json.hpp is always included before any libhv include to force the most recent version to be used. It's a bit annoying, because any carelessness in the order of the includes can cause the problem, and identifying where the incorrect order is is not trivial in a large project like mine.

I also understand that this is a flaw in libhv, which adds json.hpp as an internal header and not as an external library. In addition to the fact that it does not update the library over time.
I also noticed that Intel Real Sense also uses nlohmann/json.hpp, but does so correctly as an external header that is used only internally, without including it in the library headers.

Thank you for everyone's help and availability.