Login Page - Create Account

Support Board


Date/Time: Fri, 18 Oct 2024 05:20:19 +0000



Remote Build might be incorrectly building x64 dll when in ARM64

View Count: 634

[2024-02-29 03:50:35]
kaydotle - Posts: 15
When doing Remote Build in ARM64.exe it builds an _ARM64.dll file, but it doesn't appear in my custom studies and has an error:
2024-02-28 19:22:41.112 | AutoPositionSizer_ARM64.dll loading error. Windows error code 193: %1 is not a valid Win32 application.

Doing a local build instead has the same error (though I may be doing it wrong), but when it's being built I do notice it says arm64 first, but then x64 in the output:
C:\Windows\system32\cmd.exe /C "C:\SierraChart\ACS_Source\VisualCCompile.Bat"


C:\SierraChart\ACS_Source>call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.9.2
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
AutoPositionSizer.cpp
Creating library AutoPositionSizer.lib and object AutoPositionSizer.exp
Generating code
Finished generating code
-- End of Build -- 19:43:12

But I was able to load this ARM64.dll in my regular x64.exe so it might be being built incorrectly in my ARM program.

May not be relevant, but in my About my version says "2604 64-bit" - should it say ARM anywhere?

I've already gone through https://www.sierrachart.com/index.php?page=doc/ResolvingCustomStudyFileAndAccessIssues.php#CustomStudyProblems-ThingsToCheck.
[2024-02-29 04:07:36]
Tony - Posts: 511
I believe Remote Build is done by MinGW running on Ubuntu, it doesn't build ARM64 dlls.
[2024-02-29 04:24:09]
kaydotle - Posts: 15
Oh interesting. If so, then it's confusing that it names it as an ARM64 dll file.
[2024-02-29 06:32:10]
User719512 - Posts: 248
I show the following bat files for VS2022

vcvars32.bat
vcvars64.bat
vcvarsall.bat
vcvarsamd64_arm64.bat
vcvarsamd64_x86.bat
vcvarsx86_amd64.bat
vcvarsx86_arm64.bat

vcvarsamd64_arm64.bat calls @call "%~dp0vcvarsall.bat" x64_arm64 %*

Personally, I find it more convenient to build from inside the IDE and switch from the menus. See attached.
imagevs2022.png / V - Attached On 2024-02-29 06:31:21 UTC - Size: 10.21 KB - 65 views
[2024-02-29 07:24:56]
kaydotle - Posts: 15
I've tried building in VS2022 as well, but then I get this error:
2024-02-27 18:42:02.340 | Loading DLL: C:\SierraChart\Data\AutoPositionSizer.dll (AutoPositionSizer_ARM64.dll). Handle: 7ff8b5dd0000
2024-02-27 18:42:02.340 | The custom study AutoPositionSizer.dll requires version 2604 or higher of Sierra Chart. Current version: 2604. Select 'Help >> Download Current Version'.

I'm running ARM64.exe - everything says I'm on the newest version (attached), I already did Help > Download Current Version. All I did was change SC_DLL_VERSION = 2604 in the sierrachart.h file that came in ACS_Source folder w/ installation. Is there anything else I'm supposed to do?

When I built remotely in x64 it loaded fine. When I try the same exact cpp file in VS it gives the same error as above, so it must be building incorrectly in VS.
imageAbout Version.png / V - Attached On 2024-02-29 07:19:00 UTC - Size: 40.46 KB - 58 views
imageTitle Bar Version.png / V - Attached On 2024-02-29 07:19:08 UTC - Size: 29.62 KB - 71 views
[2024-02-29 07:51:46]
User719512 - Posts: 248
You should not edit the sierrachart.h header file. That defines the minimum Sierra Chart version required to run your study, and which APIs are available for your study to call.
[2024-02-29 18:12:09]
kaydotle - Posts: 15
Oh wow that was the issue! I thought I read I had to manually update the version in the header file if building locally, and that when building remotely, they run their own header file that gets updated. It works now, thanks so much!

Sort of unrelated - do you have the same issue with overwriting the dll file? If I've already loaded the study in my chart and build a new version and try to replace the file in Data folder, I can't since it's "open in another program". Even after removing the study, so I have to restart the SC program. I was having this issue when building remotely too, even tho the docs say you shouldn't have to remove+re-add the study when building new code changes.
[2024-02-29 18:32:17]
User431178 - Posts: 517

Sort of unrelated - do you have the same issue with overwriting the dll file? If I've already loaded the study in my chart and build a new version and try to replace the file in Data folder, I can't since it's "open in another program". Even after removing the study, so I have to restart the SC program. I was having this issue when building remotely too, even tho the docs say you shouldn't have to remove+re-add the study when building new code changes.


1. Analysis Menu: Release All DLLs and Deny Load (Build Advanced Custom Studies DLL Window >> Build)
2. copy file to data folder
3. Analysis Menu: Allow Load DLLs (Build Advanced Custom Studies DLL Window >> Build)
[2024-02-29 18:57:28]
User719512 - Posts: 248
FYI, You can also do this programmatically @User431178. Posting here so others might discover this as well.
UDP Interface
and of course
ACSIL Programming Concepts

For best experience, it is most reliable to close all chartbooks before releasing/replacing/allowing DLLs. It can work well without and just refresh your chart...well...till it doesn't. #YMMV
[2024-03-01 02:29:42]
kaydotle - Posts: 15
Much appreciated y'all - gonna make my workflow so much better!
[2024-03-01 15:30:20]
Sierra_Chart Engineering - Posts: 16656
The latest version of Sierra Chart released (2609), includes an up-to-date ARM64 version.

Remote build does not support ARM64. And also we did not develop any special support for ARM64 when building with Visual C++ from within Sierra Chart. You really just need to build externally using Visual C++ for ARM 64.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2024-03-01 15:30:42
[2024-03-01 18:26:22]
kaydotle - Posts: 15
Thanks for confirming. It was confusing since the Remote Build creates an _ARM64.dll file, leading me to think it had the capability to do so.

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account