Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Required fixes to build libzt on Windows #263

Open
jbatnozic opened this issue Nov 16, 2023 · 4 comments
Open

Required fixes to build libzt on Windows #263

jbatnozic opened this issue Nov 16, 2023 · 4 comments

Comments

@jbatnozic
Copy link

jbatnozic commented Nov 16, 2023

I'm maintaining a homemade Conan package for libzt and I'm constantly having to apply patches to make it build properly on Windows. (note that I'm building it purely using CMake and not using the provided powershell scripts, though I doubt it would change things)

I will lay out here the recurring needed changes:

Linking declarations

[Link to relevant code]

This should be as follows:

#if defined(_WIN32)
    #ifndef ZTS_STATIC
        #ifdef ADD_EXPORTS
            #define ZTS_API __declspec(dllexport)
        #else
            #define ZTS_API __declspec(dllimport)
        #endif
    #else
        #define ZTS_API
    #endif
 	#define ZTCALL __cdecl
#else
    #define ZTS_API
    #define ZTCALL
#endif

We need these dllimport/dllexport declarations only when building a .dll, and NOT when building a static library. Currently in my Conan package I optionally provide this preprocessor define ZTS_STATIC based on the conan build configuration (static/shared). I see that the root CMakeLists.txt has multiple configurations at the same time so I wasn't sure how it would handle this - maybe per (cmake) target?

Side note: could we rename ADD_EXPORTS -> ZTS_ADD_EXPORTS? If you mixed this with another library which defined the generic ADD_EXPORTS you'd be stuck with either having both shared or both static (not always a problem but who knows?)

zts_errno linking

[Link to relevant code]

This should be as follows:

extern ZTS_API int zts_errno;

Otherwise you can't use this crucial variable at all when libzt is built as a DLL.

Side note: is this variable thread-local?

nlohmann/json include paths

[Link to relevant code]

The following line needs to be added:

include_directories(${ZTO_SRC_DIR}/ext/)

Otherwise certain headers from ZeroTierOne will try to #include <nlohmann/json.hpp> and won't be able to find it so the build will fail. I'm surprised that it even builds without this on other platforms (system package maybe?).

@janvanbouwel
Copy link
Contributor

As for nlohmann/json, this is disabled on other platforms and for some reason not on Windows, found it recently as part of #63 but it seemed someone else was working on it so I suggested the fix there for now IceSoulHanxi#2.

@jbatnozic
Copy link
Author

What about the others? I'd open a PR myself but I have no permissions on your repo.

@janvanbouwel
Copy link
Contributor

No idea sorry. (I'm not associated with ZeroTier to be clear, I've been working on nodejs bindings so know some parts of the project well.)

I'd open a PR myself but I have no permissions on your repo.

I'm a bit confused by what you mean? You haven't forked the repo, how are you trying to open a PR?

@jbatnozic
Copy link
Author

Apparently it's me who was confused here. So far I hadn't used GitHub to contribute to projects which weren't my own, so I wasn't aware that I had to fork the repo first. The whole time I was trying to set up my own branch in this repo.

AlexIndustrial added a commit to AlexIndustrial/libzt that referenced this issue Feb 2, 2024
AlexIndustrial added a commit to AlexIndustrial/libzt that referenced this issue Feb 2, 2024
AlexIndustrial added a commit to AlexIndustrial/libzt that referenced this issue Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants