Sorry for top posting, I write on the phone. About windows and LLVM I read that Microsoft accepts in Visual Studio, which in interpret as sign that llvm is better on windows then mingw. Plus llvm tries to be Abi compatible. See: https://clang.llvm.org/docs/MSVCCompatibility.html
may be we should consider a switch to llvm in mid future. about the bridge. I thought we can utilize hourglass Interfaces. Example c++ to python https://github.com/ReliaSolve/Hourglass And a slide deck https://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis I thought maybe these works other way round, too. All the best Peter Am 24. Dezember 2022 11:59:53 MEZ schrieb Damjan Jovanovic <dam...@apache.org>: >Yes, and bridges are specific to CPU, OS compiler version, and compiler >settings. Eg. Even on Win32, the legacy mingw compiler uses sjlj exception >handling, which is completely incompatible with MSVC's exception handling, >so a separate bridge is needed for each. We would likely need a >gcc_linux_arm64 bridge for the Pinebooks and Raspberry Pis, >msvc_win64_arm64 for Windows on ARM64, and s5abi_macosx_arm64 for the new >Macs. > >LLVM is permissively licensed and highly compatible with MSVC's exception >handling, and someone told me AOO successfully builds and runs with >LLVM-based mingw using our MSVC bridge, so the LLVM code could help us >complete our Win64 bridge. > >What's your idea to get rid of the assembler code? > >On Sat, Dec 24, 2022 at 12:06 PM Peter kovacs <peter.kov...@posteo.de> >wrote: > >> The blocker is more ore less the bridge. >> There we have Assembler code which helps bridging binaries through the JDI >> into Java. >> You need to write the same for Arm64. >> At least it looks for me like that. >> >> (The same is true imho for Win64 builds. So maybe if you check for the >> Windows 64 mails from Damjan, you will find some info.) >> >> I think in addition for Mac you need to update to the latest SDK in order >> to get something that natively works. >> >> Imho it would be cool to build on Mac as is and fix the 4.2. blockers >> first. >> >> In the long run I would like to get rid of the assembler code. I have an >> idea how to do this, but I am not sure if the idea is viable. >> >> Am 23. Dezember 2022 16:29:00 MEZ schrieb Matthias Seidel < >> matthias.sei...@hamburg.de>: >> >Hi Carl, >> > >> >Am 23.12.22 um 16:19 schrieb Carl Marcum: >> >> Hi Matthias, >> >> >> >> >> >> On 12/23/22 10:12 AM, Matthias Seidel wrote: >> >>> Hi Carl, >> >>> >> >>> Am 23.12.22 um 15:21 schrieb Carl Marcum: >> >>>> Hi All, >> >>>> >> >>>> I'm working on setting up a MacBook Pro M2 with Ventura and was >> >>>> wondering on the current state of building AOO 4.2+ or trunk on ARM64 >> >>>> for macOS or Linux. It seems pretty good at virtualization with ARM64 >> >>>> OS's. >> >>>> >> >>>> I seem to remember patches being submitted for ARM but I don't find >> >>>> much about building. >> >>> Yes, it would be great if we had a native ARM build... ;-) >> >>> >> >>>> Otherwise I'll have to try emulation for x64 and would probably be >> >>>> much less performant. >> >>> macOS on M1/M2 runs the Intel binaries automatically via "Rosetta 2" >> >>> [1]. I haven't heard of performance issues. >> >> >> >> Yes I'm running AOO on macOS fine. This is about the ARM64 platform >> >> building it ;) >> > >> >I think the patches you remember were for ARM32. To my knowledge we >> >never got a build for that out officially... >> > >> >ARM64 is definitely worth it, but I also would like to run AOO on my >> >Raspberry Pi! ;-) >> > >> >Regards, >> > >> > Matthias >> > >> >> >> >> Best regards, >> >> Carl >> >> >> >>> >> >>> Regards, >> >>> >> >>> Matthias >> >>> >> >>> [1]https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2 >> >>> >> >>>> Thanks, >> >>>> >> >>>> Carl >> >>>> >> >>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail:dev-unsubscr...@openoffice.apache.org >> >>>> For additional commands, e-mail:dev-h...@openoffice.apache.org >> >>>> >> > >>
