You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm building UDUNITS 2.2.28 with expat 2.5.0 on Windows using cmake and visual studio 2022
I first built expat with cmake and visual studio. Expat provides options to build static libraries and using the static runtime library, which I used. I'm then building a static library build of UDUNITS using the BUILD_SHARED_LIBS=OFF option. It seems like you don't have an option for using the static c runtime library.
The first issue is that this causes the expat build system to add an "MT" suffix to its library file names, so the findExpat CMAKE module can't find expat. This is an expat/CMake issue I guess, but I can't seem to log in to CMake's bug reporting system to report this. I can workaround this by removing the MT suffix from the libraries. Then cmake completes successfully.
I then have to manually edit the visual studio files to use the static runtime. This is expected as I couldn't find an option to configure this with Cmake
The second issue is that the debug version of the expat library adds a d suffix to the library name. The workaround for this is to edit the visual studio files for UDUNITS created by cmake for the debug build.
The third issue is that when using the static library, the calling program must #define XML_STATIC before including expat.h. UDUNITS doesn't do this, so when building the tools, we get link errors. The workaround is to add that define to the preprocessor definitions for both the UDUNITS library and the tools (libudunits2 and udunits2 projects in visual studio)
The workarounds mean I can build, but it would be nice if UDUNITS was able to add the d suffix to the expat lib for debug builds and also when building UDUNITS as a static lib maybe it should use the appropriate static define for expat. It would also be nice to have a static runtime cmake switch.
If these aren't possible, then maybe this post will serve as help to others trying to do the same (or just to me when I try and rebuild some years into the future).
The text was updated successfully, but these errors were encountered:
I'm building UDUNITS 2.2.28 with expat 2.5.0 on Windows using cmake and visual studio 2022
I first built expat with cmake and visual studio. Expat provides options to build static libraries and using the static runtime library, which I used. I'm then building a static library build of UDUNITS using the BUILD_SHARED_LIBS=OFF option. It seems like you don't have an option for using the static c runtime library.
The first issue is that this causes the expat build system to add an "MT" suffix to its library file names, so the findExpat CMAKE module can't find expat. This is an expat/CMake issue I guess, but I can't seem to log in to CMake's bug reporting system to report this. I can workaround this by removing the MT suffix from the libraries. Then cmake completes successfully.
I then have to manually edit the visual studio files to use the static runtime. This is expected as I couldn't find an option to configure this with Cmake
The second issue is that the debug version of the expat library adds a d suffix to the library name. The workaround for this is to edit the visual studio files for UDUNITS created by cmake for the debug build.
The third issue is that when using the static library, the calling program must #define XML_STATIC before including expat.h. UDUNITS doesn't do this, so when building the tools, we get link errors. The workaround is to add that define to the preprocessor definitions for both the UDUNITS library and the tools (libudunits2 and udunits2 projects in visual studio)
The workarounds mean I can build, but it would be nice if UDUNITS was able to add the d suffix to the expat lib for debug builds and also when building UDUNITS as a static lib maybe it should use the appropriate static define for expat. It would also be nice to have a static runtime cmake switch.
If these aren't possible, then maybe this post will serve as help to others trying to do the same (or just to me when I try and rebuild some years into the future).
The text was updated successfully, but these errors were encountered: