Vizit0r
commented
5 years ago MAC64 build available only for people with license exactly for 10.3.2. My license older, so i cant check it;.
Open jdavison-mo opened 5 years ago
Vizit0r
commented
5 years ago MAC64 build available only for people with license exactly for 10.3.2. My license older, so i cant check it;.
jdavison-mo
commented
5 years ago Thanks. That makes sense why I see this. I'll dig a bit further and if I'm able to solve it post a pull request.
Vizit0r
commented
4 years ago The reason of all problems in OSX64 (and Linux64, i think also) with PS is " The LongInt and LongWord Data Type are different on 64-bit POSIX platforms To keep interoperability between Delphi and POSIX API, for 64-bit POSIX platforms, the size of LongInt and LongWord types are changed to 64-bit. All 32-bit platforms and 64-bit Windows platforms keep 32-bit for the LongInt and LongWord types." - http://docwiki.embarcadero.com/RADStudio/Rio/en/Delphi_Considerations_for_Multi-Device_Applications#The_LongInt_and_LongWord_Data_Type_are_different_on_64-bit_POSIX_platforms
So, fixing is versy simple - change ALL LongInt type to Integer. Files: uPSCompiler, uPSComponent, uPSDebugger, uPSRuntime, uPSUtils
But dont change by autoreplace from "Longint" to "Integer", because in this case declarations like
AddTypeCopyN('Integer', 'LongInt');
and other - will be broken.
P.S. Ah, one more point to fix: in uPSRuntime.pas change lines
{$ifdef CPUX64}
{.$DEFINE empty_methods_handler}
{$ENDIF}to
{$ifdef POSIX64}
{$DEFINE empty_methods_handler}
{$ENDIF}looks like thats all.
Later on, when i will have time for check it on Linux64, i will arrange all this changes to commit. but i'm sure, that @carlokok will be unhappy for hundreds (or thousands?) of changed types everywhere.
P.P.S. As i see now, in FPC opposite situation - Integer has variable size, but LongInt is const. Need to add another type, will do this later when will prepare commit.
jdavison-mo
commented
3 years ago I've just come back to check on this issue and see if anything has changed. I downloaded the latest code and got the same error.
Thanks @Vizit0r for your suggestions.
I wanted to explore what the issues were stopping it compiling. I found a number of conflict Integer implementation declarations mismatching their interface which was LongInt. I fixed those to LongInt. I realise this will increase the length for Linux64 but is this a problem? I only found a handful of these not too many.
I stubbed out 2 assembler routines which I hope could be translated to pure pascal by someone who understands their intent. I'm not sure what the assembler is doing
procedure MyAllMethodsHandler; procedure PutOnFPUStackExtended(ft: extended);
Perhaps as suggested we can just {$DEFINE empty_methods_handler} to avoid the assembler. But I don't know what its trying to do, so is a stub acceptable or do we need it to do something? If a stub was acceptable, why didn't the implementer just do that on Windows in the first place instead of having complicated asm?
I've post my patches here:
jdavison-mo
commented
3 years ago Progress has been made in that I've compiled the TestApplication sample with CrossVCL 1.27 for Mac64.
When I choose compile from the menu I receive the following error.
First chance exception at $0000000100419E9E. Exception class EAccessViolation with message 'Access violation at address 0000000100419E9E, accessing address 00000009017241F8'. Process TestApplication (5741) Source Breakpoint at : C:\JD\pascalscript\Source\uPSRuntime.pas line 2060. Process TestApplication (5741) First chance exception at $0000000100419E9E. Exception class EAccessViolation with message 'Access violation at address 0000000100419E9E, accessing address 00000009017241F8'. Process TestApplication (5741) Source Breakpoint at : C:\JD\pascalscript\Source\uPSRuntime.pas line 2060. Process TestApplication (5741)
Upsruntime.TPSExec.Clear()(0x00000002017350d0) Upsdebugger.TPSCustomDebugExec.Clear()(0x00000002017350d0) Upscomponent.TPSScript.Compile()(0x0000000201734c20) Fmain.TForm1.Compile1Click(System.TObject)(0x00007ffeefbfe038) Vcl.Menus.TMenuItem.Click()(0x0000000201734960) Vcl.Menus.TMenu.DispatchCommand(unsigned short)(0x0000000201734340,2) Vcl.Forms.TCustomForm.WMCommand(Winapi.Messages.TWMCommand&)(0x0000000205039ff0,0x00007ffeefbfe878) :000000010001132B System::TObject::Dispatch(void) Vcl.Controls.TControl.WndProc(Winapi.Messages.TMessage&)(0x0000000205039ff0,0x00007ffeefbfe878) Vcl.Controls.TWinControl.WndProc(Winapi.Messages.TMessage&)(0x0000000205039ff0,0x00007ffeefbfe878) Vcl.Forms.TCustomForm.WndProc(Winapi.Messages.TMessage&)(0x0000000205039ff0,0x00007ffeefbfe878) Vcl.Controls.TWinControl.MainWndProc(Winapi.Messages.TMessage&)(0x0000000205039ff0,0x00007ffeefbfe878) :00000001013E5777 _lldb_unnamedfunction2542$$libcrossvcl64.dylib :0000000101400450 lldb_unnamed_function3782$$libcrossvcl64.dylib :000000010140E07B _lldb_unnamedfunction4430$$libcrossvcl64.dylib :000000010140DF76 lldb_unnamed_function4428$$libcrossvcl64.dylib :0000000101465FA3 _lldb_unnamed_function6181$$libcrossvcl64.dylib :00007FFF3EA22644 -[NSApplication(NSResponder) sendAction:to:from:] :00007FFF3EA7E86B -[NSMenuItem _corePerformAction] :00007FFF3EA7E5DC -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] :00007FFF3EAE258F -[NSMenu performActionForItemAtIndex:] :00007FFF3EAE24FC -[NSMenu _internalPerformActionForItemAtIndex:] :00007FFF3EAE232E -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] :00007FFF3EA4CDC6 NSSLMMenuEventHandler :00007FFF4039722E DispatchEventToHandlers(EventTargetRec, OpaqueEventRef, HandlerCallRec) :00007FFF403965DF SendEventToEventTargetInternal(OpaqueEventRef, OpaqueEventTargetRef, HandlerCallRec) :00007FFF403B39B6 SendEventToEventTarget :00007FFF40405CD2 SendHICommandEvent(unsigned int, HICommand const, unsigned int, unsigned int, unsigned char, void const, OpaqueEventTargetRef, OpaqueEventTargetRef, OpaqueEventRef) :00007FFF4042E14E SendMenuCommandWithContextAndModifiers :00007FFF4042E0FD SendMenuItemSelectedEvent :00007FFF4042DFE5 FinishMenuSelection(SelectionData, MenuResult, MenuResult) :00007FFF4042E9B3 MenuSelectCore(MenuData, Point, double, unsigned int, OpaqueMenuRef, unsigned short*) :00007FFF4042E6C8 _HandleMenuSelection2 :00007FFF3E73AA81 _NSHandleCarbonMenuEvent :00007FFF3E73A8E6 _DPSEventHandledByCarbon :00007FFF3E72F92B -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] :0000000101418883 ___lldb_unnamedfunction4761$$libcrossvcl64.dylib :00000001013FD9C9 lldb_unnamed_function3667$$libcrossvcl64.dylib :00000001001444B9 Winapi::Windows::WaitMessage() Vcl.Forms.TApplication.Idle(tagMSG const&)(0x0000000204321960) Vcl.Forms.TApplication.HandleMessage()(0x0000000204321960) Vcl.Forms.TApplication.Run()(0x0000000204321960) main(1,0x00007ffeefbff9a0,0x00007ffeefbff9b0,0x00007ffeefbffa68) :00007FFF6D0C43D5 start
jdavison-mo
commented
3 years ago My code has been pushed so should be reproducable with by checking out my branch.
I have latest revision with patches from issue #202 (commit 86a057c8686143ce0443be6995d6515c5c9b705c) but I am unable to compile the files that are part of the PascalScript_Core_D26.dpk for that platform for Linux64 nor MacOS64.
Here's some compiler output using Delphi 10.3.2 Rio dccosx64 compiler (similar results exist for dcclinux64):
If I comment out that offending code then I get the following which is starting to look non-trivial...
I am grateful for your assistance.