Support Board
Date/Time: Sat, 23 Nov 2024 18:20:09 +0000
Remote Build might be incorrectly building x64 dll when in ARM64
View Count: 685
| [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: 516 |
|
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: 262 |
|
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. |
 vs2022.png / V - Attached On 2024-02-29 06:31:21 UTC - Size: 10.21 KB - 80 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. |
| About Version.png / V - Attached On 2024-02-29 07:19:00 UTC - Size: 40.46 KB - 66 views Title Bar Version.png / V - Attached On 2024-02-29 07:19:08 UTC - Size: 29.62 KB - 78 views |
| [2024-02-29 07:51:46] |
| User719512 - Posts: 262 |
|
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: 541 |
|
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: 262 |
|
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: 17150 |
|
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: