Skip to content

Conversation

eisenhauer
Copy link
Member

No description provided.

@vicentebolea
Copy link

In the debug windows jobs, it appears that ctest is wrongly trying to access the binaries needed for testing in the "bin/Release" directory. This does not occur in the "release" jobs but fixing this might give us a hint

@eisenhauer
Copy link
Member Author

In the debug windows jobs, it appears that ctest is wrongly trying to access the binaries needed for testing in the "bin/Release" directory. This does not occur in the "release" jobs but fixing this might give us a hint

I hard-coded the release directory in the path trying to get at least one build to work. If it had been successful I'd have added the logic to look at the build type, but unfortunately it was not.

@vicentebolea
Copy link

I have been reviewing what we do for the adios2/viskores windows jobs in gha and it seems that loading the dlls from the cmake build directory when using ctest must work out of the box. Might this be that the classic problem of having a wrong delimiter in PATH.

@eisenhauer
Copy link
Member Author

Hmm. Maybe! I can't look at anything until next week...

@eisenhauer
Copy link
Member Author

I have been reviewing what we do for the adios2/viskores windows jobs in gha and it seems that loading the dlls from the cmake build directory when using ctest must work out of the box. Might this be that the classic problem of having a wrong delimiter in PATH.

For what it's worth, I found no indication that this might be caused by a bad delimiter. Instead, it looks like it is just not finding DLLs that are in the PATH. I've tried several ways of setting the PATH, and I think i'm setting the registry key for SafeDllSearchMode correctly, but nothing seems to resolve this in a nice way. That the approach Chuck took here worked with windows2019 and stopped with windows2022 implies that something changed with DLL searching, and I thought the SafeDllSearchMode was a good bet, but nothing has come of it. Rather than spend yet more time on this, I'm just copying the built/installed atl and dill DLLs into a system directory which is already searched. That's a pretty ugly solution, but its the only one I have at the moment.

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

Successfully merging this pull request may close these issues.

2 participants