Add a static windows build to CI #4037

eisenhauer · 2024-02-18T03:44:25Z

No description provided.

vicentebolea · 2024-02-19T20:14:30Z

https://stackoverflow.com/a/7511679/2420872

vicentebolea · 2024-02-19T20:25:24Z

I can see something in here: https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md . It appears that the default image ships something called: Microsoft.VisualStudio.Component.VC.TestAdapterForGoogleTest that might be injecting the wrong settings so that we produce a shared lib instead of a static for gtest as it seems that we are doing.

vicentebolea · 2024-02-19T20:27:01Z

How about trying to update google test to a newer version, maybe this was resolved later on. BTW I strongly recommend not to use main but tag releases (v1.14.0 Latest)

eisenhauer · 2024-02-19T20:27:32Z

https://stackoverflow.com/a/7511679/2420872

OK, but this PR forces external GTest to OFF, which seems to result in the desire behavior, which is GTest being build in thirdparty and the use of the same compiler settings as the rest of the project, yes? So I'm not sure how to apply the information above.

I found a number of suggestions about modifying the flags specified in the visual studio project, bug of course this is CMake generating those, nothing that we've specified. We just did -DBUILD_SHARED=OFF. Could this be a cmake problem?

vicentebolea · 2024-02-19T20:30:43Z

hmm I think that they key issue is this: https://stackoverflow.com/questions/14714877/mismatch-detected-for-runtimelibrary.

Basically we need to set the same https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html in both gtest and ADIOS2

vicentebolea · 2024-02-19T20:31:19Z

Here is the excerpt from the CI of this PR:

2024-02-19T16:36:46.9549109Z   Generating Code...
2024-02-19T16:36:48.4067951Z   adios2_cxx11.vcxproj -> D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\lib\Debug\adios2_cxx11.lib
2024-02-19T16:36:48.4687841Z   Building Custom Rule D:/a/ADIOS2/ADIOS2/source/thirdparty/GTest/googletest/googletest/CMakeLists.txt
2024-02-19T16:36:48.5299357Z   gtest-all.cc
2024-02-19T16:36:50.4028311Z   gtest.vcxproj -> D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\lib\Debug\gtest.lib
2024-02-19T16:36:50.4520778Z   Building Custom Rule D:/a/ADIOS2/ADIOS2/source/testing/adios2/bindings/C/CMakeLists.txt
2024-02-19T16:36:50.5174694Z   TestNullWriteRead.cpp
2024-02-19T16:36:51.8200782Z gtest.lib(gtest-all.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in TestNullWriteRead.obj [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]
2024-02-19T16:36:51.9833412Z msvcprtd.lib(MSVCP140D.dll) : error LNK2005: "public: struct _Cvtvec __cdecl std::_Locinfo::_Getcvt(void)const " (?_Getcvt@_Locinfo@std@@QEBA?AU_Cvtvec@@XZ) already defined in gtest.lib(gtest-all.obj) [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]
2024-02-19T16:36:52.0060454Z msvcprtd.lib(MSVCP140D.dll) : error LNK2005: "public: bool __cdecl std::ios_base::good(void)const " (?good@ios_base@std@@QEBA_NXZ) already defined in gtest.lib(gtest-all.obj) [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]

eisenhauer · 2024-02-19T20:31:41Z

How about trying to update google test to a newer version, maybe this was resolved later on. BTW I strongly recommend not to use main but tag releases (v1.14.0 Latest)

I considered that too. The fly in the ointment there is that everything past v1.12 requires C++14 (which is more than the rest of ADIOS requires). Not a problem for a quick test, but potentially something to consider. I suppose we could also consider a win2019 static build to see if that was better, or at if it at least let us get to problems in ADIOS.

eisenhauer · 2024-02-19T20:32:59Z

Here is the excerpt from the CI of this PR:

2024-02-19T16:36:46.9549109Z   Generating Code...
2024-02-19T16:36:48.4067951Z   adios2_cxx11.vcxproj -> D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\lib\Debug\adios2_cxx11.lib
2024-02-19T16:36:48.4687841Z   Building Custom Rule D:/a/ADIOS2/ADIOS2/source/thirdparty/GTest/googletest/googletest/CMakeLists.txt
2024-02-19T16:36:48.5299357Z   gtest-all.cc
2024-02-19T16:36:50.4028311Z   gtest.vcxproj -> D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\lib\Debug\gtest.lib
2024-02-19T16:36:50.4520778Z   Building Custom Rule D:/a/ADIOS2/ADIOS2/source/testing/adios2/bindings/C/CMakeLists.txt
2024-02-19T16:36:50.5174694Z   TestNullWriteRead.cpp
2024-02-19T16:36:51.8200782Z gtest.lib(gtest-all.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in TestNullWriteRead.obj [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]
2024-02-19T16:36:51.9833412Z msvcprtd.lib(MSVCP140D.dll) : error LNK2005: "public: struct _Cvtvec __cdecl std::_Locinfo::_Getcvt(void)const " (?_Getcvt@_Locinfo@std@@QEBA?AU_Cvtvec@@XZ) already defined in gtest.lib(gtest-all.obj) [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]
2024-02-19T16:36:52.0060454Z msvcprtd.lib(MSVCP140D.dll) : error LNK2005: "public: bool __cdecl std::ios_base::good(void)const " (?good@ios_base@std@@QEBA_NXZ) already defined in gtest.lib(gtest-all.obj) [D:\a\ADIOS2\ADIOS2\win2022-vs2022-static-serial\Testing\adios2\bindings\C\Test.Bindings.C.NullWriteRead.Serial.vcxproj]

Yeah, seeing this is why I tried forcing the use of the internal GTest. Didn't change anything though. Maybe find_package() is still picking up the external version despite us building one.

vicentebolea · 2024-02-19T20:34:57Z

Yeah, seeing this is why I tried forcing the use of the internal GTest. Didn't change anything though. Maybe find_package() is still picking up the external version despite us building one.

that is not true, if I check the cmakecache.txt I see this:


//Value Computed by CMake
googletest-distribution_BINARY_DIR:STATIC=D:/a/ADIOS2/ADIOS2/win2022-vs2022-static-serial/thirdparty/GTest/googletest

//Value Computed by CMake
googletest-distribution_IS_TOP_LEVEL:STATIC=OFF

//Value Computed by CMake
googletest-distribution_SOURCE_DIR:STATIC=D:/a/ADIOS2/ADIOS2/source/thirdparty/GTest/googletest

//Value Computed by CMake
gtest_BINARY_DIR:STATIC=D:/a/ADIOS2/ADIOS2/win2022-vs2022-static-serial/thirdparty/GTest/googletest/googletest

//Value Computed by CMake
gtest_IS_TOP_LEVEL:STATIC=OFF

//Value Computed by CMake
gtest_SOURCE_DIR:STATIC=D:/a/ADIOS2/ADIOS2/source/thirdparty/GTest/googletest/googletest

//Build gtest's sample programs.
gtest_build_samples:BOOL=OFF

vicentebolea · 2024-02-19T20:46:15Z

hmm we are still having the issue. error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in TestNullWriteRead.ob

For some reason the flag CMAKE_MSVC_RUNTIME_LIBRARY is not being passed down to gtest.

vicentebolea · 2024-02-19T21:21:43Z

Now we only have errors with FFS

eisenhauer · 2024-02-19T21:30:39Z

Well, that's a start. I'll see what I can do from here. Thanks!

vicentebolea · 2024-02-19T21:53:24Z

Do you think that the remain errors are due to wrong dllexport directives in FFS?

eisenhauer · 2024-02-19T22:02:04Z

Yes, there are remains from pre-cmake build environments in ffs and dependent libraries. That it’s likely not just ffs and that I don’t have working windows CI in those libraries means the next steps will take a while.

…

Sent from my iPhone On Feb 19, 2024, at 4:53 PM, Vicente Bolea ***@***.***> wrote: Do you think that the remain errors are due to wrong dllexport directives in FFS? — Reply to this email directly, view it on GitHub<#4037 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHF7GJEVPVNOX4VUNL3II3YUPCWBAVCNFSM6AAAAABDN2GUNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTGE4TSNZSHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

vicentebolea · 2024-02-19T22:09:45Z

Does it make sense to force an export all for windows? On Mon, Feb 19, 2024 at 5:02 PM Greg Eisenhauer ***@***.***> wrote:

…

Yes, there are remains from pre-cmake build environments in ffs and dependent libraries. That it’s likely not just ffs and that I don’t have working windows CI in those libraries means the next steps will take a while. Sent from my iPhone On Feb 19, 2024, at 4:53 PM, Vicente Bolea ***@***.***> wrote: Do you think that the remain errors are due to wrong dllexport directives in FFS? — Reply to this email directly, view it on GitHub< #4037 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AAHF7GJEVPVNOX4VUNL3II3YUPCWBAVCNFSM6AAAAABDN2GUNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTGE4TSNZSHE>. You are receiving this because you authored the thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#4037 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHFOFWPJONESBZ7GN63CE3YUPDWPAVCNFSM6AAAAABDN2GUNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTGIYDONBRHE> . You are receiving this because your review was requested.Message ID: ***@***.***>

-- [image: logo shows large letter K with the word Kitware below it] <http://www.kitware.com> Vicente Bolea, MSc. *Senior R&D Engineer*

eisenhauer · 2024-02-19T23:59:17Z

Does it make sense to force an export all for windows?

Probably. I've just been stuck at CI until now. I was digging around trying to sort of things like GENERATE_EXPORT_HEADER are still necessary or recommended, but hadn't landed on any obviously correct examples.

vicentebolea · 2024-02-20T03:20:30Z

It appears that the issue was with the use of dllexport | import. The latest change seems to have a address it. https://github.com/ornladios/ADIOS2/actions/runs/7967848404/job/21751218798?pr=4037

IT also seems that this affects DILL too.

eisenhauer · 2024-02-20T12:48:22Z

thirdparty/GTest/googletest/googletest/CMakeLists.txt

We can't make direct changes inside thirdparty libraries (at least not without killing our ability to easily update them). You also have this in the dashboard_cache list in ci-win2-22-vs2-22-static-serial.cmake. I assume that wasn't sufficient? Can we do this in a file we own like thirdparty/GTest/CMakeLists.txt?

@eisenhauer these are exploratory changes, once we find the right changes we can add them in their respective repos

@eisenhauer these are exploratory changes, once we find the right changes we can add them in their respective repos

Understand of course, and that's my plan for the GTKorvo stuff, but I'm assuming that it's not so trivial for googletest...

eisenhauer · 2024-02-20T12:53:01Z

Yeah, I knew the dllimport spec was the problem, but the question was how to fix it. It does look like changing to dllexport in source and outside helps. I can extend this to dill, atl and evpath as well (we're not pulling in evpath on Windows yet, but we need to for SST and remote stuff). No Windows CI on those packages, but the ADIOS CI can likely serve as an indirect proxy to try things out. Thanks!

eisenhauer · 2024-02-21T16:04:25Z

@vicentebolea Just to close the loop for the final status. In general, the declspec(dllimport) was the problem in the static build, but it wasn't necessary to replace them with dllexport. That is all taken care of by CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS. However, the one place we do still need a declspec is in dill where we are exporting not just code symbols, but also data symbols. Data symbols require a declspec(dllimport) to be imported by the VS compiler, but it must only appear in the declaration where the symbol is used (not where it's defined), and only when we are building shared and not static libraries.

vicentebolea · 2024-02-21T17:35:59Z

@eisenhauer sounds great, CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS was what we were looking for initially in this thread. CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is a good compromise for the time being, if in the future we have more people using adios2 static build (probably through pip) we could go the fine grain dllexport/inport not to incur in the size/perf overhead which CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS implies.

eisenhauer · 2024-02-21T17:51:52Z

The EXPORT_ALL_SYMBOLS was actually already in use in all those GTkorvo projects, we just hadn't killed the declspec defines that were leftover from pre-CMake configuration. That they hadn't been killed both made the static build fail, but also happened to make the dynamic build work for the data symbols that dill needed to export). That messiness was probably why this hadn't been sorted before. In any case, I'm in the process of folding those changes into the upstream GTkorvo repos. When I'm done I'll probably kill this PR and re-submit something with a less complex history... Thanks for your help!

vicentebolea · 2024-02-21T18:07:53Z

When I'm done I'll probably kill this PR and re-submit something with a less complex history

Can you keep it in this PR, you can rebase/reset all the commits in a single one. In the future it will be easier to find the reason of this if this is done in a single PR 👼

eisenhauer · 2024-02-21T18:11:40Z

The awkwardness it that I have to kill all the GTkorvo commits, because they really have to come in via the update script. I suppose I could reset all these commits away, kill the GTkorvo changes, redo them via update, etc. Just not keeping very much, but I guess it does keep the dialogue.

Code extracted from: https://github.com/GTkorvo/dill.git at commit 2bd038273c1083cdaddb9a402fff5db8dbb385f4 (master). Upstream Shortlog -----------------

# By dill Upstream * upstream-dill: dill 2024-02-21 (2bd03827)

Code extracted from: https://github.com/GTkorvo/ffs.git at commit cc3da1a07d5040a9d76e0fafe89b082ce6121145 (master). Upstream Shortlog -----------------

# By ffs Upstream * upstream-ffs: ffs 2024-02-21 (cc3da1a0)

Code extracted from: https://github.com/GTkorvo/EVPath.git at commit 6587d0f0d7a80dbc0afb56ae4aca9250fe366e57 (master). Upstream Shortlog -----------------

# By EVPath Upstream * upstream-EVPath: EVPath 2024-02-21 (6587d0f0)

eisenhauer · 2024-02-21T19:06:14Z

The inability to do a rebase on any PR that has used the update.sh script in a thirdparty package is a nuisance...

vicentebolea · 2024-02-21T19:35:37Z

I think that the proper way would be to do a reset --soft (soft is the default mode so just git reset)

…

On Wed, Feb 21, 2024 at 2:06 PM Greg Eisenhauer ***@***.***> wrote: The inability to do a rebase on any PR that has used the update.sh script in a thirdparty package is a nuisance... — Reply to this email directly, view it on GitHub <#4037 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHFOFXFILLKHQZMZ4VUNIDYUZATFAVCNFSM6AAAAABDN2GUNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXG4YTSNRYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- [image: logo shows large letter K with the word Kitware below it] <http://www.kitware.com> Vicente Bolea, MSc. *Senior R&D Engineer*

eisenhauer · 2024-02-21T19:40:38Z

I think that the proper way would be to do a reset --soft (soft is the default mode so just git reset)

Well, since rebase often simply doesn't work in that scenario (during the rebase commits to things like ADIOS2/thirdparty/ffs/ffs/CMakeLists.txt get applied to ADIOS2/CMakeLists.txt), you do have to have to do something else...

eisenhauer · 2024-02-21T19:41:24Z

@vicentebolea I believe that this is ready for review at this point.

vicentebolea

Tiny comment, everything else great! Good job

thirdparty/GTest/CMakeLists.txt

Co-authored-by: Vicente Bolea <[email protected]>

eisenhauer · 2024-02-21T21:11:44Z

Ok, removed that...

- Upstream EVpath, FFS and dill. - Actually add the CI Co-authored-by: Vicente Bolea <[email protected]>

eisenhauer requested a review from vicentebolea as a code owner February 18, 2024 03:44

eisenhauer changed the title ~~Try to do a static windows build in CI~~ WIP: Try to do a static windows build in CI Feb 18, 2024

vicentebolea force-pushed the WindowsStatic branch from dd96df1 to dfa8637 Compare February 19, 2024 20:59

vicentebolea force-pushed the WindowsStatic branch 7 times, most recently from e0e1fbf to 67a56fc Compare February 20, 2024 02:47

vicentebolea force-pushed the WindowsStatic branch from e2818d8 to 4f14aa8 Compare February 20, 2024 03:24

eisenhauer commented Feb 20, 2024

View reviewed changes

eisenhauer force-pushed the WindowsStatic branch from 1778dfa to aef1a7b Compare February 21, 2024 18:21

dill Upstream and others added 6 commits February 21, 2024 13:30

dill 2024-02-21 (2bd03827)

c260dc6

Code extracted from: https://github.com/GTkorvo/dill.git at commit 2bd038273c1083cdaddb9a402fff5db8dbb385f4 (master). Upstream Shortlog -----------------

Merge branch 'upstream-dill' into WindowsStatic

319e6a6

# By dill Upstream * upstream-dill: dill 2024-02-21 (2bd03827)

ffs 2024-02-21 (cc3da1a0)

3aeaac9

Code extracted from: https://github.com/GTkorvo/ffs.git at commit cc3da1a07d5040a9d76e0fafe89b082ce6121145 (master). Upstream Shortlog -----------------

Merge branch 'upstream-ffs' into WindowsStatic

0abfc4e

# By ffs Upstream * upstream-ffs: ffs 2024-02-21 (cc3da1a0)

EVPath 2024-02-21 (6587d0f0)

ef58475

Code extracted from: https://github.com/GTkorvo/EVPath.git at commit 6587d0f0d7a80dbc0afb56ae4aca9250fe366e57 (master). Upstream Shortlog -----------------

Merge branch 'upstream-EVPath' into WindowsStatic

90f0640

# By EVPath Upstream * upstream-EVPath: EVPath 2024-02-21 (6587d0f0)

eisenhauer force-pushed the WindowsStatic branch from aef1a7b to 90f0640 Compare February 21, 2024 18:35

eisenhauer changed the title ~~WIP: Try to do a static windows build in CI~~ Add a static windows build to CI Feb 21, 2024

Actually add the CI and mod GTest to work

20d825c

vicentebolea requested changes Feb 21, 2024

View reviewed changes

thirdparty/GTest/CMakeLists.txt Outdated Show resolved Hide resolved

Update thirdparty/GTest/CMakeLists.txt

f2fb97e

Co-authored-by: Vicente Bolea <[email protected]>

vicentebolea approved these changes Feb 21, 2024

View reviewed changes

eisenhauer enabled auto-merge (squash) February 21, 2024 21:25

eisenhauer merged commit b0b197f into ornladios:master Feb 21, 2024
39 checks passed

vicentebolea mentioned this pull request Feb 22, 2024

CI: All-Static builds (Linux/macOS/Win) #4025

Closed

eisenhauer deleted the WindowsStatic branch February 22, 2024 01:15

vicentebolea pushed a commit to vicentebolea/ADIOS2 that referenced this pull request Feb 28, 2024

Add a static windows build to CI (ornladios#4037)

96dd323

- Upstream EVpath, FFS and dill. - Actually add the CI Co-authored-by: Vicente Bolea <[email protected]>

This was referenced Feb 28, 2024

backports from master #4058

Closed

backports from master #4059

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a static windows build to CI #4037

Add a static windows build to CI #4037

eisenhauer commented Feb 18, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024 via email

vicentebolea commented Feb 19, 2024 via email

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 20, 2024

eisenhauer Feb 20, 2024

vicentebolea Feb 20, 2024

eisenhauer Feb 20, 2024

eisenhauer commented Feb 20, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024 via email

eisenhauer commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea left a comment

eisenhauer commented Feb 21, 2024

Add a static windows build to CI #4037

Add a static windows build to CI #4037

Conversation

eisenhauer commented Feb 18, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 19, 2024

eisenhauer commented Feb 19, 2024 via email

vicentebolea commented Feb 19, 2024 via email

eisenhauer commented Feb 19, 2024

vicentebolea commented Feb 20, 2024

eisenhauer Feb 20, 2024

Choose a reason for hiding this comment

vicentebolea Feb 20, 2024

Choose a reason for hiding this comment

eisenhauer Feb 20, 2024

Choose a reason for hiding this comment

eisenhauer commented Feb 20, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea commented Feb 21, 2024 via email

eisenhauer commented Feb 21, 2024

eisenhauer commented Feb 21, 2024

vicentebolea left a comment

Choose a reason for hiding this comment

eisenhauer commented Feb 21, 2024