Open jdavison-mo opened 5 years ago
MAC64 build available only for people with license exactly for 10.3.2. My license older, so i cant check it;.
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.
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.
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:
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
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.