Add support for building for Windows ARM64 devices #3430

anthony-linaro · 2024-11-19T11:56:04Z

Description of Change(s)

Add support for Windows ARM64 devices.

This was tested using the following command line:

python build_scripts/build_usd.py --no-python --onetbb --tests --no-imaging C:/WoA/OpenUSD/build_dir

Python is currently switched off due to lack of support for PySide on these devices. I am looking at that seperately.

I also had to disable imaging, as building boost appears to be broken when using newer CMake versions (similar issue to #3285)

TBB is set to OneTBB, as 2020u3 doesn't support these devices.

I also had to make a small modification in testWrapper.py, and change line 134 to pathPattern = pathPattern + r'(\S*)', as otherwise the escape sequence was invalid.

Checklist

[x] I have created this PR based on the dev branch

[x] I have followed the coding conventions

[ ] I have added unit tests that exercise this functionality (Reference:
testing guidelines)

[x] I have verified that all unit tests pass with the proposed changes

[x] I have submitted a signed Contributor License Agreement (Reference:
Contributor License Agreement instructions)

jesschimein · 2024-11-19T18:04:56Z

Filed as internal issue #USD-10450

❗ Please make sure that a signed CLA has been submitted!

jesschimein · 2024-11-19T18:04:57Z

/AzurePipelines run

azure-pipelines · 2024-11-19T18:05:09Z

Azure Pipelines successfully started running 1 pipeline(s).

anthony-linaro · 2024-11-21T09:59:42Z

CLA sorted - approved by Tim Palmer

pmolodo · 2024-11-25T23:49:03Z

Any reason why the testWrapper.py change you mentioned isn't included here? Otherwise, lgtm

anthony-linaro · 2024-11-27T14:58:50Z

I figured it was more related to the version of python I have installed (3.12.5), rather than the one used for validation on other devices - as I didn't have those devices/versions to hand, and knew the script already worked as-was on them, I opted not to change it

nvmkuruc · 2024-12-03T16:14:37Z

build_scripts/build_usd.py

@@ -393,7 +393,10 @@ def RunCMake(context, force, extraArgs = None):

    # Note - don't want to add -A (architecture flag) if generator is, ie, Ninja
    if IsVisualStudio2019OrGreater() and "Visual Studio" in generator:
-        generator = generator + " -A x64"
+        if "ARM" in os.environ.get('PROCESSOR_IDENTIFIER'):


Could the platform module be used here?
https://docs.python.org/3/library/platform.html#module-platform

(repost from correct account)

It could be, but problems arise when running an emulated x64 version of python (which is easy to do by mistake, as that's what the website gives you by default).

This way checks the name of the processor directly, which is not affected by emulation.

asluk · 2024-12-19T06:35:29Z

"Python is currently switched off due to lack of support for PySide on these devices. I am looking at that seperately."

Hi @anthony-linaro , per our call yesterday, you also mentioned that the python bindings are failing to compile -- can you post the error messages you are seeing there?

"I also had to disable imaging, as building boost appears to be broken... "

@sunyab , is it expected that the command line

python build_scripts/build_usd.py --no-python --onetbb --tests C:/WoA/OpenUSD/build_dir

would attempt to build boost in v24.11+ ?

Thanks all!

anthony-linaro · 2025-01-08T11:57:52Z

Hi @asluk - I have tried to reproduce the compilation errors, but am unable, so will chalk it down to an env issue - with things set up properly, I have most of the tests passing.

However, when I run ctest, I get this:

The following tests FAILED:
          2 - python_properties (Failed)
         47 - python_pickle1 (Failed)
         50 - python_pickle4 (Failed)
        225 - testPlug (Failed)
        666 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        708 - testUsdChecker1 (Failed)
        709 - testUsdChecker2 (Failed)
        710 - testUsdChecker3 (Failed)
        711 - testUsdChecker4 (Failed)
        712 - testUsdChecker5 (Failed)
        720 - testUsdChecker13 (Failed)
        778 - testUsdResolverExample (Failed)

I have attached the output file from the tests to this comment. Are these tests expected to fail? If not, do you have any idea why they might be? All env paths are set as instructed after build (bin and lib on path, python on pythonpath)

LastTest.log

asluk · 2025-01-08T16:21:32Z

@anthony-linaro I don't think those test failures are expected -- can you try rebasing your branch to be on top of the "dev" branch? That is the most up to date commit. Thanks and happy new year!

sunyab · 2025-01-08T16:55:42Z

@sunyab , is it expected that the command line

python build_scripts/build_usd.py --no-python --onetbb --tests C:/WoA/OpenUSD/build_dir

would attempt to build boost in v24.11+ ?

(sorry for the late reply, was out on vacation)

Yes, I would expect that to build boost in v24.11+. When imaging is enabled the --tests option requires the idiff tool from OpenImageIO for image diffs, and the version of OIIO the build script uses still requires boost.

sunyab · 2025-01-08T17:00:00Z

However, when I run ctest, I get this:

The following tests FAILED:
          2 - python_properties (Failed)
         47 - python_pickle1 (Failed)
         50 - python_pickle4 (Failed)
        225 - testPlug (Failed)
        666 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        708 - testUsdChecker1 (Failed)
        709 - testUsdChecker2 (Failed)
        710 - testUsdChecker3 (Failed)
        711 - testUsdChecker4 (Failed)
        712 - testUsdChecker5 (Failed)
        720 - testUsdChecker13 (Failed)
        778 - testUsdResolverExample (Failed)

Hi @anthony-linaro, the python_* test failures are due to #3384, which is fixed in the dev branch. The other failures don't look familiar to me, so I'm not sure what's going on there.

anthony-linaro · 2025-01-08T17:06:43Z

Hi both, thanks for the responses!

@sunyab You're right, those python issues are now fixed, thanks to the suggestion from @asluk to merge dev.

Sadly, the list of errors has now changed, and I now get this:

The following tests FAILED:
        225 - testPlug (Failed)
        656 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        764 - testUsdChecker1 (Failed)
        765 - testUsdChecker2 (Failed)
        766 - testUsdChecker3 (Failed)
        767 - testUsdChecker4 (Failed)
        768 - testUsdChecker5 (Failed)
        776 - testUsdChecker13 (Failed)
        777 - testUsdChecker14 (Failed)
        778 - testUsdChecker15 (Failed)
        779 - testUsdChecker16 (Failed)
        780 - testUsdChecker17 (Failed)
        781 - testUsdChecker18 (Failed)
        788 - testUsdChecker26 (Failed)
        789 - testUsdChecker27 (Failed)
        799 - testUsdChecker37 (Failed)
        802 - testUsdResolverExample (Failed)

I have once again attached the logs: LastTest.log

Any suggestions of where I could start to look? It looks like it's not seeing the "Tf" python module. The path variable is correct, and added as specified when building (ie, modified PATH and PYTHONPATH) - is there another one that got missed somewhere? Was there an extra step required between build_usd.py and ctest for python to be able to see the module?

jesschimein · 2025-01-08T18:30:25Z

/AzurePipelines run

azure-pipelines · 2025-01-08T18:30:36Z

Azure Pipelines successfully started running 1 pipeline(s).

dgovil · 2025-01-08T19:15:43Z

build_scripts/build_usd.py

@@ -393,7 +393,10 @@ def RunCMake(context, force, extraArgs = None):

    # Note - don't want to add -A (architecture flag) if generator is, ie, Ninja
    if IsVisualStudio2019OrGreater() and "Visual Studio" in generator:
-        generator = generator + " -A x64"
+        if "ARM" in os.environ.get('PROCESSOR_IDENTIFIER'):


It might be good to follow the convention in apple_utils.py and extract this into GetHostArch https://github.com/PixarAnimationStudios/OpenUSD/blob/release/build_scripts/apple_utils.py#L66

Is the suggestion here to write a whole new windows_utils.py (and extract/refactor some things like IsVisualStudioXXXXOrGreater() which are windows only), or just add a function to build_usd.py called something along the lines of GetWindowsHostArch()?

I'm not sure I'd advocate for another file necessarily (though it is the route I would take myself)

But just extracting the heuristics for detecting arm into a function somewhere in this file itself should be fine?

I just imagine that in the future, we'll need to modify the build parameters for certain dependencies etc based on the current arch, and so it'd be nice to have it as a function from the get go.

I have now moved it out to a seperate function - it should now reliably detect ARM or x64

Critique very much welcome - I've never been much of a python dev

build_scripts/build_usd.py

pxr/base/arch/defines.h

anthony-linaro · 2025-01-08T20:27:53Z

I didn't add support for ARM64EC, as I didn't have a use-case for it - if you guys have one internally I'm unaware of, I can try and add support. The biggest issue with ARM64EC will likely be around the use of any intrinsics - as it defines both _M_ARM64EC, and _M_X64, use of intrinsics that could be considered "safely" gated behind _M_X64 (or similar) are suddenly not so safe, so I'd need to go over the source with a fine tooth comb. Not impossible, but requires substantially more work than a plain old ARM64 enablement.

dgovil · 2025-01-08T20:32:01Z

That's fair. At the very least, I'd suggest then adding a caveat to the README somewhere to document that EC isn't supported yet?

Also mention incompatibility with ARM64EC

anthony-linaro · 2025-01-09T13:48:04Z

Good idea - I have updated the README.md file to reflect the work done on this PR

jesschimein · 2025-01-09T18:30:04Z

/AzurePipelines run

azure-pipelines · 2025-01-09T18:30:14Z

Azure Pipelines successfully started running 1 pipeline(s).

asluk · 2025-01-21T18:30:02Z

Hi both, thanks for the responses!

@sunyab You're right, those python issues are now fixed, thanks to the suggestion from @asluk to merge dev.

Sadly, the list of errors has now changed, and I now get this:
The following tests FAILED:
        225 - testPlug (Failed)
        656 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        764 - testUsdChecker1 (Failed)
        765 - testUsdChecker2 (Failed)
        766 - testUsdChecker3 (Failed)
        767 - testUsdChecker4 (Failed)
        768 - testUsdChecker5 (Failed)
        776 - testUsdChecker13 (Failed)
        777 - testUsdChecker14 (Failed)
        778 - testUsdChecker15 (Failed)
        779 - testUsdChecker16 (Failed)
        780 - testUsdChecker17 (Failed)
        781 - testUsdChecker18 (Failed)
        788 - testUsdChecker26 (Failed)
        789 - testUsdChecker27 (Failed)
        799 - testUsdChecker37 (Failed)
        802 - testUsdResolverExample (Failed)
I have once again attached the logs: LastTest.log

Any suggestions of where I could start to look? It looks like it's not seeing the "Tf" python module. The path variable is correct, and added as specified when building (ie, modified PATH and PYTHONPATH) - is there another one that got missed somewhere? Was there an extra step required between build_usd.py and ctest for python to be able to see the module?

I think the testUsdResolverExample failure is expected, and/or might need the example resolver to be bootstrapped in PATH and PYTHONPATH as well (@sunyab or @pmolodo , do you remember the incantation for that?)

@tallytalwar , looks like the usdchecker rules are failing (also affects testUsdUtilsCreateNewUsdzPackageEditInPlace), but I'm not sure why-- does anything in the log stand out to you or have a clear root cause in your experience? (e.g., Shader </World/simpleMaterial/boardMat/PBRShader> has invalid shader node. (fails 'ShaderPropertyTypeConformanceChecker'))

It's not clear to me what the testPlug failure is.

tallytalwar · 2025-01-21T20:17:59Z

@asluk all the usdchecker tests (both old <13 and new framework >=13) are failing because its not able to find any of the usdShaders, example UsdPreviewSurface etc in sdr:

New compliance checker failing here: https://github.com/PixarAnimationStudios/OpenUSD/blob/dev/pxr/usdValidation/usdShadeValidators/validators.cpp#L341-L353
Old compliance checerk failing here: https://github.com/PixarAnimationStudios/OpenUSD/blob/dev/pxr/usd/usdUtils/complianceChecker.py#L712

Both these point to a build issue which is not picking up some plugins example, usdShaders here: https://github.com/PixarAnimationStudios/OpenUSD/tree/dev/pxr/usdImaging/plugin/usdShaders

Maybe the testPlug failure also points to that :/

asluk · 2025-01-22T18:39:38Z

Thanks @tallytalwar ! Is there something additional in PATH or PYTHONPATH etc that @anthony-linaro needs to do to detect the shaders?

@anthony-linaro , can you post the relevant bits from your PATH and PYTHONPATH when running tests?

tallytalwar · 2025-01-23T06:09:04Z

Ahh I see.. I think the "--no-imaging" arg to the build script doesn't build pxr/usdImaging which is where these shader plugins live.

From the PR description:

python build_scripts/build_usd.py --no-python --onetbb --tests --no-imaging C:/WoA/OpenUSD/build_dir

I also had to disable imaging, as building boost appears to be broken when using newer CMake versions (similar issue to #3285)

asluk · 2025-01-23T18:50:25Z

Thanks @tallytalwar .... @anthony-linaro , those failures are expected then ... @tallytalwar , is it worth a separate PR disabling some cases in the usdchecker tests when Imaging is not enabled in the build?

tallytalwar · 2025-01-23T18:51:58Z

@asluk yes definitely. I was planning to do that, but a PR will also be appreciated. Will sync it in for internal consumption promptly.

anthony-linaro · 2025-01-24T14:16:08Z

So, we would consider this ready to go then? Or is there a requirement to fix the imaging first?

asluk · 2025-01-27T19:14:06Z

So, we would consider this ready to go then? Or is there a requirement to fix the imaging first?

@anthony-linaro can you try running just testPlug to see if you can get more output from it? something like ctest -R testPlug

Overall I think this is generally ready to go, but defer to @sunyab as to next steps. Thanks all!

anthony-linaro · 2025-01-30T16:38:15Z

@asluk Full output:

C:\WoA\OpenUSD\build_dir\build\OpenUSD>ctest -C Release -R testPlug --output-on-failure
Test project C:/WoA/OpenUSD/build_dir/build/OpenUSD
    Start 226: testPlug
1/1 Test #226: testPlug .........................***Failed    0.21 sec
Warning: in _DeclareAliases at line 526 of C:\WoA\OpenUSD\pxr\base\plug\plugin.cpp -- Expected string for alias name, but found int
.Error: return code 3221225477 doesn't match expected 0 (EXPECTED_RETURN_CODE).chdir: C:\Users\Anthony\AppData\Local\Temp\tmp4oyg3b4d
cmd: ['C:/Program', 'Files/Python311-arm64/python.exe', 'C:/WoA/OpenUSD/build_dir/tests/testPlug']


0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.31 sec

The following tests FAILED:
        226 - testPlug (Failed)
Errors while running CTest

asluk · 2025-01-30T19:56:34Z

@asluk Full output:

C:\WoA\OpenUSD\build_dir\build\OpenUSD>ctest -C Release -R testPlug --output-on-failure
Test project C:/WoA/OpenUSD/build_dir/build/OpenUSD
    Start 226: testPlug
1/1 Test #226: testPlug .........................***Failed    0.21 sec
Warning: in _DeclareAliases at line 526 of C:\WoA\OpenUSD\pxr\base\plug\plugin.cpp -- Expected string for alias name, but found int
.Error: return code 3221225477 doesn't match expected 0 (EXPECTED_RETURN_CODE).chdir: C:\Users\Anthony\AppData\Local\Temp\tmp4oyg3b4d
cmd: ['C:/Program', 'Files/Python311-arm64/python.exe', 'C:/WoA/OpenUSD/build_dir/tests/testPlug']


0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.31 sec

The following tests FAILED:
        226 - testPlug (Failed)
Errors while running CTest

Thanks @anthony-linaro -- I can't think of something that would cause this, and I don't think that the warning is what is causing the failure. Also I'd expect many more tests to be broken if plugins were broken.

@sunyab , any ideas on how we can get more diagnostics on the failure? Maybe run with TF_DEBUG=PLUG* in the environment? Thanks!

asluk · 2025-02-12T01:24:57Z

@anthony-linaro can you set TF_DEBUG to be "PLUG*" in the environment ? Here is my LastTest.log file that gets output from ctest, when running the test successfully on Windows x86_64

LastTest.log

anthony-linaro · 2025-02-12T10:29:09Z

@asluk Attached:
LastTestWithPluginDebug.log

Looks like it's failing on TestPlugDsoUnloadable - I noticed I'm using Python 3.11, and you 3.10 - could this be the issue, maybe 3.11 is more strict on the unloadable plugin?

asluk · 2025-02-13T01:39:23Z

@asluk Attached: LastTestWithPluginDebug.log

Looks like it's failing on TestPlugDsoUnloadable - I noticed I'm using Python 3.11, and you 3.10 - could this be the issue, maybe 3.11 is more strict on the unloadable plugin?

Thanks @anthony-linaro -- I suspect it's something else-- I do see usdShadeValidators in your output so I wonder if it's what @tallytalwar suspects as well, that running the tests in a no-imaging build will fail due to the shaders not being available.

I'll try to repro on Windows x86_64 with imaging disabled.

nvmkuruc · 2025-02-13T01:43:50Z

There's an open issue for checkers failing without imaging for reference

#3055

asluk · 2025-02-13T02:41:03Z

confirmed that testPlug does pass for me with a --no-imaging --tests build on Windows x86_64 with python 3.11 -- I am at commit 67e851b , which is the current Pixar "dev" branch -- @anthony-linaro , can you rebase on top of that?

(these tests fail for me)

The following tests FAILED:
554 - testUsdZipFile (Failed)
657 - testUsdUtilsCreateNewUsdzPackageUdim (Failed)
658 - testUsdUtilsCreateNewUsdzPackageRemapClipsDir (Failed)
659 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
767 - testUsdChecker1 (Failed)
768 - testUsdChecker2 (Failed)
769 - testUsdChecker3 (Failed)
770 - testUsdChecker4 (Failed)
771 - testUsdChecker5 (Failed)
779 - testUsdChecker13 (Failed)
780 - testUsdChecker14 (Failed)
781 - testUsdChecker15 (Failed)
782 - testUsdChecker16 (Failed)
783 - testUsdChecker17 (Failed)
784 - testUsdChecker18 (Failed)
791 - testUsdChecker26 (Failed)
792 - testUsdChecker27 (Failed)
802 - testUsdChecker37 (Failed)
805 - testUsdResolverExample (Failed)

asluk · 2025-02-13T04:19:27Z

All tests pass for me with --imaging with python 3.10 in dev, windows x86_64

with python 3.11 in dev, windows x86_64 these --imaging tests fail

The following tests FAILED:
554 - testUsdZipFile (Failed)
657 - testUsdUtilsCreateNewUsdzPackageUdim (Failed)
867 - testUsdviewNavigationKeys (Failed)
883 - testUsdResolverExample (Failed)

@anthony-linaro , if testPlug still fails for you after rebasing, can you try commenting out blocks of test_ErrorCases in testPlug.py until it passes, to keep zeroing in on specifics?

It looks like TestPlugDsoUnloadable is expected to fail to load, but not to crash, and I'm not sure if any ARM64 specifics with how TestPlugDsoUnloadable gets compiled may be in play-- these compiler flags may need tweaking for ARM64 - https://github.com/PixarAnimationStudios/OpenUSD/blob/dev/pxr/base/plug/CMakeLists.txt#L105

asluk · 2025-02-14T00:28:11Z

small update-- I am now getting the same test results with --imaging builds on Windows x86_64 with python 3.10 and 3.11 in the dev branch -- testUsdZipFile , testUsdviewNavigationKeys , and testUsdResolverExample are the known failures for that. (My previous python 3.10 test run was implicitly excluding tests that are known to fail on Windows).

testPlug is the only real test that needs further investigation in this PR, and I think the approach I recommended for zeroing in on the error cases and compiler flags for the deliberately "bad" plugins being processed in that test should get the PR over the hump.

all the other failing tests in the PR are from the missing usdShaders in --no-imaging builds, that is tracked in #3055

anthony-linaro · 2025-02-14T16:34:59Z

@asluk My error list after merging dev now looks like:

The following tests FAILED:
        226 - testPlug (Failed)
        659 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        767 - testUsdChecker1 (Failed)
        768 - testUsdChecker2 (Failed)
        769 - testUsdChecker3 (Failed)
        770 - testUsdChecker4 (Failed)
        771 - testUsdChecker5 (Failed)
        779 - testUsdChecker13 (Failed)
        780 - testUsdChecker14 (Failed)
        781 - testUsdChecker15 (Failed)
        782 - testUsdChecker16 (Failed)
        783 - testUsdChecker17 (Failed)
        784 - testUsdChecker18 (Failed)
        791 - testUsdChecker26 (Failed)
        792 - testUsdChecker27 (Failed)
        802 - testUsdChecker37 (Failed)
        805 - testUsdResolverExample (Failed)

So looks like testPlug wasn't fixed - I'll try and drill down to the specific issue in the suggested way

asluk · 2025-02-14T16:46:52Z

@asluk My error list after merging dev now looks like:

The following tests FAILED:
        226 - testPlug (Failed)
        659 - testUsdUtilsCreateNewUsdzPackageEditInPlace (Failed)
        767 - testUsdChecker1 (Failed)
        768 - testUsdChecker2 (Failed)
        769 - testUsdChecker3 (Failed)
        770 - testUsdChecker4 (Failed)
        771 - testUsdChecker5 (Failed)
        779 - testUsdChecker13 (Failed)
        780 - testUsdChecker14 (Failed)
        781 - testUsdChecker15 (Failed)
        782 - testUsdChecker16 (Failed)
        783 - testUsdChecker17 (Failed)
        784 - testUsdChecker18 (Failed)
        791 - testUsdChecker26 (Failed)
        792 - testUsdChecker27 (Failed)
        802 - testUsdChecker37 (Failed)
        805 - testUsdResolverExample (Failed)

So looks like testPlug wasn't fixed - I'll try and drill down to the specific issue in the suggested way

thanks for the update @anthony-linaro -- yep, I think once you start disabling error cases in testPlug.py, we'll get a more targeted sense of the actual severity and root causes of what it's reporting -- cc @sunyab 🙏🏼

anthony-linaro · 2025-02-26T17:33:44Z

I've spent an amount of time debugging this, and have narrowed it down to an interesting difference in behaviour, which I'm not entirely sure on why it's happening - I will continue to try and debug, but thought I would update here.

The issue is actually coming from the LoadLibrary call in library.cpp when the DLL is loaded for TestPlugDsoUnloadable - on x64, the DLL fails to load as intended/documented, and execution continues with the handle being a NULLPTR.

On ARM64 however, there is an EXCEPTION_ACCESS_VIOLATION when the LoadLibrary call is made, that just doesn't seem to want to be caught. I've tried both regular try blocks, and also the MSVC extension __try blocks. Regardless of those, the exception seems to immediately kill off the process, causing the error we can see of return code 3221225477 doesn't match expected 0, which comes from testWrapper.py, line 321. Using LoadLibraryEx makes no difference.

I'm not entirely sure what's going on here - by all documentation, this function should just fail, and return NULLPTR - however, it doesn't seem to be doing that at all. Is it because the DLL is so intentionally broken we're running into undefined behaviour?

asluk · 2025-02-26T21:40:32Z

Thanks for digging into it @anthony-linaro -- I suspect someone from Microsoft would have more info on why the exception is not being caught. If you comment out

    # try to load an unloadable plugin
    badPlugin = Plug.Registry().GetPluginForType('TestPlugUnloadable')
    self.assertIsNotNone(badPlugin)
    with self.assertRaises(RuntimeError):
        badPlugin.Load()

does the rest of testPlug pass? If so, @sunyab , is there a way to conditionally skip that case behind some sort of Arch query in Python?

sunyab · 2025-02-26T22:36:12Z

Sure, that test case could certainly be skipped over using the same logic to detect whether we're in a Windows ARM64 environment as in build_usd.py -- we wouldn't need anything from the Arch library itself (which isn't wrapped to Python anyway).

The main trickiness with TestPlugDsoUnloadable is its intentional use of an unresolved external symbol. I didn't see anything in the LoadLibrary docs that explicitly mention that loading such a library will result in the function returning NULL, so I guess technically its undefined behavior? At the same time, it feels like it'd be pretty weird if the behavior differed between ARM and x64 for this particular case.

One thing I'm kind of curious about is whether moving this code in TestPlugDsoUnloadable.cpp:

OpenUSD/pxr/base/plug/testenv/TestPlugDsoUnloadable.cpp

Lines 22 to 23 in 6284755

    
           static int something = 
        
               Unresolved_external_symbol_error_is_expected_Please_ignore();

to within the TF_REGISTRY_FUNCTION block here:

OpenUSD/pxr/base/plug/testenv/TestPlugDsoUnloadable.cpp

Line 43 in 6284755

TF_REGISTRY_FUNCTION(TfType)

makes a difference. I have no real reason to think it should, I'm just throwing stuff against the wall.

anthony-linaro · 2025-02-26T22:54:30Z

The intended behaviour of the function is mentioned here: https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya#return-value The intention, as I understand it, is that you call the function, and if it returns a null pointer, then you call "GetLastError()" for more information. This is how it has worked when I have used it previously (for example, if a DLL had a DEPENDENTLOADFLAG=0x2000, which I encountered last week). Catching an access violation exception from inside a Win32 API would be unusual, AIUI, as they are designed to be called from C, too. Perhaps it is undefined behaviour, but the documentation doesn't make it clear either way. I will try the rearrangement inside the plugin tomorrow. Oddly - this all seems to happen before testPlug - in my testing I even went as far as emptying testPlug.py of anything but a "hello world" print, yet I still hit the error. Is the python compiled, and so requires a rebuild for changes to apply? There is also the possibility I did something wrong there, of course

asluk · 2025-02-27T01:58:31Z

@anthony-linaro , yes OpenUSD needs to be incrementally "rebuilt" in order for modified tests to get re-installed to the location from which they are run.

Add support for building for Windows ARM64 devices

afaa6f3

asluk added the build Build-related issue/PR label Nov 20, 2024

anthony-linaro mentioned this pull request Nov 25, 2024

Add support for Windows ARM64 AcademySoftwareFoundation/OpenColorIO#2089

Merged

nvmkuruc reviewed Dec 3, 2024

View reviewed changes

asluk added the needs review Issue needing input/review by the repo maintainer (Pixar) label Dec 3, 2024

Merge remote-tracking branch 'origin/dev' into windows-arm64-support

bae81cd

dgovil reviewed Jan 8, 2025

View reviewed changes

mattyjams reviewed Jan 8, 2025

View reviewed changes

pxr/base/arch/defines.h Show resolved Hide resolved

Update README.md to mention Windows ARM64

85c8853

Also mention incompatibility with ARM64EC

Implement seperate windows host arch detection function

d76e076

Add support for building for Windows ARM64 devices #3430

Are you sure you want to change the base?

Add support for building for Windows ARM64 devices #3430

Conversation

anthony-linaro commented Nov 19, 2024 • edited Loading

Description of Change(s)

Checklist

jesschimein commented Nov 19, 2024

jesschimein commented Nov 19, 2024

azure-pipelines bot commented Nov 19, 2024

anthony-linaro commented Nov 21, 2024

pmolodo commented Nov 25, 2024

anthony-linaro commented Nov 27, 2024

nvmkuruc Dec 3, 2024

Choose a reason for hiding this comment

anthony-linaro Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

asluk commented Dec 19, 2024

anthony-linaro commented Jan 8, 2025

asluk commented Jan 8, 2025

sunyab commented Jan 8, 2025

sunyab commented Jan 8, 2025

anthony-linaro commented Jan 8, 2025 • edited Loading

jesschimein commented Jan 8, 2025

azure-pipelines bot commented Jan 8, 2025

dgovil Jan 8, 2025

Choose a reason for hiding this comment

anthony-linaro Jan 9, 2025

Choose a reason for hiding this comment

dgovil Jan 9, 2025

Choose a reason for hiding this comment

anthony-linaro Jan 9, 2025

Choose a reason for hiding this comment

anthony-linaro commented Jan 8, 2025 via email

dgovil commented Jan 8, 2025

anthony-linaro commented Jan 9, 2025

jesschimein commented Jan 9, 2025

azure-pipelines bot commented Jan 9, 2025

asluk commented Jan 21, 2025

tallytalwar commented Jan 21, 2025 • edited Loading

asluk commented Jan 22, 2025

tallytalwar commented Jan 23, 2025 • edited Loading

asluk commented Jan 23, 2025

tallytalwar commented Jan 23, 2025

anthony-linaro commented Jan 24, 2025

asluk commented Jan 27, 2025

anthony-linaro commented Jan 30, 2025

asluk commented Jan 30, 2025

asluk commented Feb 12, 2025

anthony-linaro commented Feb 12, 2025

asluk commented Feb 13, 2025

nvmkuruc commented Feb 13, 2025

asluk commented Feb 13, 2025 • edited Loading

asluk commented Feb 13, 2025 • edited Loading

asluk commented Feb 14, 2025 • edited Loading

anthony-linaro commented Feb 14, 2025

asluk commented Feb 14, 2025

anthony-linaro commented Feb 26, 2025

asluk commented Feb 26, 2025

sunyab commented Feb 26, 2025

anthony-linaro commented Feb 26, 2025 via email

asluk commented Feb 27, 2025

anthony-linaro commented Nov 19, 2024 •

edited

Loading

anthony-linaro Dec 10, 2024 •

edited

Loading

anthony-linaro commented Jan 8, 2025 •

edited

Loading

tallytalwar commented Jan 21, 2025 •

edited

Loading

tallytalwar commented Jan 23, 2025 •

edited

Loading

asluk commented Feb 13, 2025 •

edited

Loading

asluk commented Feb 13, 2025 •

edited

Loading

asluk commented Feb 14, 2025 •

edited

Loading