Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Just for the record: Enrico wrote that the empty post was unintentional and 
regarding the drag
packages and "rexx -v":

> What is needed to create the "drag and drop packages"?
>
Just run cmake with 
-DBUILD_DMG=1

After that in the build directory 
./build_macOS_dmg.sh

I am almost done with ….
rexx -e "say .RexxInfo~processor"                                           
          
arm64


And with  
rexx -v                                                                     
                
Open Object Rexx Version 5.0.0 r12266
Build date: Jun  7 2021
Build mode: arm64.universal, 64 bits

I just have to check the cross builds and backward portability

---rony


On 10.06.2021 08:54, Rony G. Flatscher wrote:
>
> Hi Enrico,
>
> it seems that your posting from yesterday does not carry any new text of 
> yours?
>
> ---rony
>
>
> On 09.06.2021 16:41, Enrico Sorichetti via Oorexx-devel wrote:
>>
>>
>>> On 9 Jun 2021, at 15:51, Rony G. Flatscher >> > wrote:
>>>
>>> Enrico,
>>>
>>> just two quick questions inline, if you get some time on your hands:
>>>
>>> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:

> only installs once or a few times so I don’t see a benefit in spending 
> developers time in
> making big beast.

 I would not call adding from 6 to 12 lines of code to the cmakelists a big 
 effort

 6 for the simple task of adding the universal build and backwards 
 compatbility to high sierra
 around 6 more lines if you want to inform the user about the arch and the 
 universal build
 when issuing *rexx -v
 *
>>>
>>> What would these lines look like? :)
>>>
>>>
 and you do not need to build two different drag and drop packages
 also you can build from a x86_64 machine  the universal for the arm64  
>>>
>>> What is needed to create the "drag and drop packages"?
>>>
>>> TIA,
>>>
>>> ---rony
>>>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Hi Enrico,

it seems that your posting from yesterday does not carry any new text of yours?

---rony


On 09.06.2021 16:41, Enrico Sorichetti via Oorexx-devel wrote:
>
>
>> On 9 Jun 2021, at 15:51, Rony G. Flatscher > > wrote:
>>
>> Enrico,
>>
>> just two quick questions inline, if you get some time on your hands:
>>
>> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>>>
 only installs once or a few times so I don’t see a benefit in spending 
 developers time in
 making big beast.
>>>
>>> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
>>> effort
>>>
>>> 6 for the simple task of adding the universal build and backwards 
>>> compatbility to high sierra
>>> around 6 more lines if you want to inform the user about the arch and the 
>>> universal build
>>> when issuing *rexx -v
>>> *
>>
>> What would these lines look like? :)
>>
>>
>>> and you do not need to build two different drag and drop packages
>>> also you can build from a x86_64 machine  the universal for the arm64  
>>
>> What is needed to create the "drag and drop packages"?
>>
>> TIA,
>>
>> ---rony
>>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

> On 9 Jun 2021, at 15:51, Rony G. Flatscher  wrote:
> 
> Enrico,
> 
> just two quick questions inline, if you get some time on your hands:
> 
> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>> 
>>> only installs once or a few times so I don’t see a benefit in spending 
>>> developers time in making big beast.
>> 
>> 
>> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
>> effort
>> 
>> 6 for the simple task of adding the universal build and backwards 
>> compatbility to high sierra
>> around 6 more lines if you want to inform the user about the arch and the 
>> universal build
>> when issuing rexx -v 
> What would these lines look like? :)
> 
> 
> 
>> and you do not need to build two different drag and drop packages
>> also you can build from a x86_64 machine  the universal for the arm64   
> What is needed to create the "drag and drop packages"?
> 
> TIA,
> 
> ---rony
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Enrico,

just two quick questions inline, if you get some time on your hands:

On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>
>> only installs once or a few times so I don’t see a benefit in spending 
>> developers time in making
>> big beast.
>
> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
> effort
>
> 6 for the simple task of adding the universal build and backwards 
> compatbility to high sierra
> around 6 more lines if you want to inform the user about the arch and the 
> universal build
> when issuing *rexx -v
> *

What would these lines look like? :)


> and you do not need to build two different drag and drop packages
> also you can build from a x86_64 machine  the universal for the arm64  

What is needed to create the "drag and drop packages"?

TIA,

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

> only installs once or a few times so I don’t see a benefit in spending 
> developers time in making big beast.


I would not call adding from 6 to 12 lines of code to the cmakelists a big 
effort

6 for the simple task of adding the universal build and backwards compatbility 
to high sierra
around 6 more lines if you want to inform the user about the arch and the 
universal build
when issuing rexx -v 

and you do not need to build two different drag and drop packages
also you can build from a x86_64 machine  the universal for the arm64   

enrico

PS
I posted the results of building the universal on the mac mini silicon
i did the other way around in february, but to be sure I will rerun the whole 
thing and post the results again



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[P.O. Jonsson]

> Am 07.06.2021 um 18:11 schrieb Rony G. Flatscher :
> 
> The reason why I came up with the question right now is a student who has a 
> physical new M1 and gets into troubles when running BSF4ooRexx from the Intel 
> version with Java that got compiled for M1 it seems. 
> 
> 

Hi Rony, I do not think you can mix native M1 applications and ones running in 
Rosetta, at least not complex ones, I think your Student should use a Intel 
based JAVA together with the „normal“ BSF4ooRexx (compiled for Intel) in 
Rosetta 2 or use both compiled for the M1 processor. We do not (yet) have any 
M1 based Mac connected to Jenkins so I have no possibility to experiment. Maybe 
Enrico can shed some light on the combo? See also 
https://support.apple.com/en-us/HT211861 


My take on it would be to have two versions of ooRexx for MacOS, one for Intel 
and one for M1, we have different versions of ooRexx for Win32 and Win64, why 
complicate things? A normal user only installs once or a few times so I don’t 
see a benefit in spending developers time in making big beast.

/P.O.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

It appears that both intel and arm (by default) are little endians. arm V8 can 
be configured to be both.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---rony
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> Oorexx-devel mailing list
>> >> Oorexx-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Buona sera Enrico,

On 07.06.2021 17:26, Enrico Sorichetti via Oorexx-devel wrote:
> BTDTGTTS ( Been There Done That Got The Tee Shirt )
> At the beginning of March I made a post 
> > 
> > I built the APPLE  ooRexx universal binaries  and the test suite runs 
> > well down to El Capitan
> > ( both the x86_64 and the apple silicon  builds)>
> > to run the multi arch, multi OS versions tests I used the drag and drop 
> > installer
>
>
> Nobody was curios on how it was done so I had no incentive to follow on with 
> the implementation
> details

*Wow*!

Sorry, you have been too quick with your solution as you did not even wait for 
a need or question to
come up back then!  ;-)

---

Seriously, just went back and found your posting from March 7th, 16:15! I am 
pretty sure that I read
it and thought wow, but we have time and in the meantime have *totally* 
forgotten about it! :(

The reason why I came up with the question right now is a student who has a 
physical new M1 and gets
into troubles when running BSF4ooRexx from the Intel version with Java that got 
compiled for M1 it
seems.

So I would be interested in having a fat binary for ooRexx, if possible at all, 
and you proofed that
it is possible as you had created such an animal already three months ago and 
tested it on both
architectures! With that I should be able to create a fat binary for BSF4ooRexx 
as well, such that
any combination with Intel/arm Java would work!

---

Would you be able to share how you did that such that the project becomes able 
to apply/incorporate
whatever is necessary for creating a fat binary for ooRexx on Apple?

I am sure, that many would *really* appreciate this a *lot*, even if this is 
not explicitly said!

Again, I am stumped about you having solved that problem already three months 
ago, kudos to you!

---rony


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Thank-you Enrico. I guess I missed it. Thanks.

Sent by Magic!

> On Jun 7, 2021, at 8:43 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> BTDTGTTS ( Been There Done That Got The Tee Shirt )
> At the beginning of March I made a post 
> > 
> > I built the APPLE  ooRexx universal binaries  and the test suite runs 
> > well down to El Capitan
> > ( both the x86_64 and the apple silicon  builds)>
> > to run the multi arch, multi OS versions tests I used the drag and drop 
> > installer
> 
> 
> Nobody was curios on how it was done so I had no incentive to follow on with 
> the implementation details 
> 
> > One could put multiple copies of oorexx into the .dmg file, and then 
> > let the installer select the correct/best binary to install.
> 
> Why waste time when the system is perfectly capable of it
> 
> ~/ooRexx/testsuite % uname -a 
>   [enrico@enrico-macmini]
> Darwin enrico-macmini.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 
> 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64
> 
> 
> Open Object Rexx Version 5.0.0 r12264
> Build date: Jun  7 2021
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
> This program and the accompanying materials are made available under the terms
> of the Common Public License v1.0 which accompanies this distribution or at
> https://www.oorexx.org/license.html
> 
> ~/ooRexx/svn.src.build % which rexx   
>   [enrico@enrico-macmini]
> /opt/ooRexx/bin/rexx
> 
> ~/ooRexx/svn.src.build % lipo -info /opt/ooRexx/bin/rexx  
>   [enrico@enrico-macmini]
> Architectures in the fat file: /opt/ooRexx/bin/rexx are: x86_64 arm64 
> ~/ooRexx/svn.src.build %  
>   [enrico@enrico-macmini]
> 
> 
> 
> ~/ooRexx/testsuite % rexx testOORexx.rex -s -X native_API   
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
> OS Name:DARWIN
> SysVersion: Darwin 20.5.0
> 
> Tests ran:  23293
> Assertions: 385129
> Failures:   0
> Errors: 0
> 
> File search:00:00:00.536408
> Suite construction: 00:00:00.694814
> Test execution: 00:04:31.740606
> Total time: 00:04:33.461738
> 
> 
> 
> and here the same from a drag and drop install of the arm build on a x8664 
> machine
> 
> 
> ~/ooRexx/testSuite % uname -a 
>   [enrico@enrico-mbp]
> Darwin enrico-mbp 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 
> PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
> 
> 
> ~/ooRexx/testSuite % lipo -info /applications/ooRexx5/bin/rexx
>   [enrico@enrico-mbp]
> Architectures in the fat file: /applications/ooRexx5/bin/rexx are: x86_64 
> arm64 
> 
> 
> ~/ooRexx/testSuite % rexx -v  
>   [enrico@enrico-mbp]
> Open Object Rexx Version 5.0.0 r12264
> Build date: Jun  7 2021
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
> This program and the accompanying materials are made available under the terms
> of the Common Public License v1.0 which accompanies this distribution or at
> https://www.oorexx.org/license.html
> ~/ooRexx/testSuite % 
> 
> 
> ~/ooRexx/testSuite % rexx testOORexx.rex -s -X native_API 
>   [enrico@enrico-mbp]
> 
> NOTE NOTE 
> the error is expected because the case sensitive/case insensitive filesystem 
> detection detection and handling is still broken
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
> OS Name:DARWIN
> SysVersion: Darwin 20.5.0
> 
> Tests ran:  23288
> Assertions: 385289
> Failures:   2
> Errors: 0
> 
> [failure] 20210607 17:09:21.128157
>   svn:r12195   Change date: 2021-03-15 17:46:10 +0100
>   Test:   TEST_SEARCHPATH1
>   Class:  File.testGroup
>   File:   .../ooRexx/testSuite/ooRexx/base/class/File.testGroup
>   Line:   674
>   Failed: assertEquals
> Expected: /Applications/ooRexx5/bin/rexx
> Actual:   /applications/ooRexx5/bin/rexx
> Message:  this may fail if rexx is run directly from a build tree
> 
> [failure] 20210607 17:10:10.527207
>   svn:r12195   Change date: 2021-03-15 17:46:10 +0100
>   Test:   TEST_SEARCHPATH_REXX
>   Class:  SYSSEARCHPATH.TESTGROUP
>   File:   

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

BTDTGTTS ( Been There Done That Got The Tee Shirt )
At the beginning of March I made a post 
> 
> I built the APPLE  ooRexx universal binaries  and the test suite runs 
> well down to El Capitan
> ( both the x86_64 and the apple silicon  builds)>
> to run the multi arch, multi OS versions tests I used the drag and drop 
> installer


Nobody was curios on how it was done so I had no incentive to follow on with 
the implementation details 

> One could put multiple copies of oorexx into the .dmg file, and then let 
> the installer select the correct/best binary to install.

Why waste time when the system is perfectly capable of it

~/ooRexx/testsuite % uname -a   
[enrico@enrico-macmini]
Darwin enrico-macmini.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 
05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64


Open Object Rexx Version 5.0.0 r12264
Build date: Jun  7 2021
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
This program and the accompanying materials are made available under the terms
of the Common Public License v1.0 which accompanies this distribution or at
https://www.oorexx.org/license.html 

~/ooRexx/svn.src.build % which rexx 
[enrico@enrico-macmini]
/opt/ooRexx/bin/rexx

~/ooRexx/svn.src.build % lipo -info /opt/ooRexx/bin/rexx
[enrico@enrico-macmini]
Architectures in the fat file: /opt/ooRexx/bin/rexx are: x86_64 arm64 
~/ooRexx/svn.src.build %
[enrico@enrico-macmini]



~/ooRexx/testsuite % rexx testOORexx.rex -s -X native_API   

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23293
Assertions: 385129
Failures:   0
Errors: 0

File search:00:00:00.536408
Suite construction: 00:00:00.694814
Test execution: 00:04:31.740606
Total time: 00:04:33.461738



and here the same from a drag and drop install of the arm build on a x8664 
machine


~/ooRexx/testSuite % uname -a   
[enrico@enrico-mbp]
Darwin enrico-mbp 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 PDT 
2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64


~/ooRexx/testSuite % lipo -info /applications/ooRexx5/bin/rexx  
[enrico@enrico-mbp]
Architectures in the fat file: /applications/ooRexx5/bin/rexx are: x86_64 arm64 


~/ooRexx/testSuite % rexx -v
[enrico@enrico-mbp]
Open Object Rexx Version 5.0.0 r12264
Build date: Jun  7 2021
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
This program and the accompanying materials are made available under the terms
of the Common Public License v1.0 which accompanies this distribution or at
https://www.oorexx.org/license.html
~/ooRexx/testSuite % 


~/ooRexx/testSuite % rexx testOORexx.rex -s -X native_API   
[enrico@enrico-mbp]

NOTE NOTE 
the error is expected because the case sensitive/case insensitive filesystem 
detection detection and handling is still broken

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23288
Assertions: 385289
Failures:   2
Errors: 0

[failure] 20210607 17:09:21.128157
  svn:r12195   Change date: 2021-03-15 17:46:10 +0100
  Test:   TEST_SEARCHPATH1
  Class:  File.testGroup
  File:   .../ooRexx/testSuite/ooRexx/base/class/File.testGroup
  Line:   674
  Failed: assertEquals
Expected: /Applications/ooRexx5/bin/rexx
Actual:   /applications/ooRexx5/bin/rexx
Message:  this may fail if rexx is run directly from a build tree

[failure] 20210607 17:10:10.527207
  svn:r12195   Change date: 2021-03-15 17:46:10 +0100
  Test:   TEST_SEARCHPATH_REXX
  Class:  SYSSEARCHPATH.TESTGROUP
  File:   .../ooRexx/testSuite/ooRexx/base/rexxutil/SysSearchPath.testGroup
  Line:   122
  Failed: assertSame
Expected: /Applications/ooRexx5/bin/rexx
Actual:   /applications/ooRexx5/bin/rexx
Message:  this may fail if rexx is run directly from a build tree

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23288
Assertions: 

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Rick, thanks for keeping me honest.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---rony
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> Oorexx-devel mailing list
>> >> Oorexx-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rick McGuire]

On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:

> Now that I think about it rexx.img was the primary problem. It contains
> executable code, but is not in a library format. You can’t even combine x86
> and amd64 into one binary.
>
I contains no native code, only core classes and and methods that are
written in Rexx in a pre-compiled format. However, all values are stored in
the .img file using the native architecture endian-ness. Intel is
little-endian and I'm pretty sure ARM is big-endian, do the images would
not be compatible.


>
> There was probably a good reason why rexx.img was implemented (speed or
> space?).
>
It was a huge savings in startup time, particularly back when a really fast
machine ran at about 100Mhz and memory was still very expensive. It might
be that things have gotten fast enough now that removing this might not be
a huge impact, and there might even be some advantages to no longer having
this, but it would not be a simple experiment to perform.



>
> Perhaps it’s time to talk about eliminating or replacing it with something
> more standard.
>
The replacement would be to reparse and translate all of the core classes
from source each time the interpreter is started.

Rick


>
> Bruce
>
> Sent by Magic!
>
> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
> >
> > The last time I looked at this, probably ppc/x86, it wasn’t possible
> because Rexx is   invoked during the build. There are tools to combine
> single binaries into “universal” binaries, but what your are really asking
> is can OORexx be cross compiled for a non-native architecture.  Even then
> there were, if I remember correctly, problems with the Rexx.img file.
> > Bruce
> >
> > Sent by Magic!
> >
> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher 
> wrote:
> >>
> >> As Apple has been selling new hardware with a proper processor, it
> would be important to support
> >> that hardware platform.
> >>
> >> In the past Apple allowed for "fat binaries" which included binaries
> for different hardware
> >> architectures in the same file. Would it be possible with CMake to have
> such ooRexx "fat binaries"
> >> created for the MacOS platform? If so, how would one be able to achieve
> that?
> >>
> >> ---rony
> >>
> >>
> >>
> >> ___
> >> Oorexx-devel mailing list
> >> Oorexx-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

One could put multiple copies of oorexx into the .dmg file, and then let the 
installer select the correct/best binary to install.

Sent by Magic!

> On Jun 7, 2021, at 7:37 AM, CV Bruce  wrote:
> 
> Now that I think about it rexx.img was the primary problem. It contains 
> executable code, but is not in a library format. You can’t even combine x86 
> and amd64 into one binary.
> 
> There was probably a good reason why rexx.img was implemented (speed or 
> space?).
> 
> Perhaps it’s time to talk about eliminating or replacing it with something 
> more standard.
> 
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> 
>> The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> because Rexx is   invoked during the build. There are tools to combine 
>> single binaries into “universal” binaries, but what your are really asking 
>> is can OORexx be cross compiled for a non-native architecture.  Even then 
>> there were, if I remember correctly, problems with the Rexx.img file.
>> Bruce
>> 
>> Sent by Magic!
>> 
 On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
 wrote:
>>> 
>>> As Apple has been selling new hardware with a proper processor, it would 
>>> be important to support
>>> that hardware platform.
>>> 
>>> In the past Apple allowed for "fat binaries" which included binaries for 
>>> different hardware
>>> architectures in the same file. Would it be possible with CMake to have 
>>> such ooRexx "fat binaries"
>>> created for the MacOS platform? If so, how would one be able to achieve 
>>> that?
>>> 
>>> ---rony
>>> 
>>> 
>>> 
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Now that I think about it rexx.img was the primary problem. It contains 
executable code, but is not in a library format. You can’t even combine x86 and 
amd64 into one binary.

There was probably a good reason why rexx.img was implemented (speed or space?).

Perhaps it’s time to talk about eliminating or replacing it with something more 
standard.

Bruce

Sent by Magic!

> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
> 
> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
> Rexx is   invoked during the build. There are tools to combine single 
> binaries into “universal” binaries, but what your are really asking is can 
> OORexx be cross compiled for a non-native architecture.  Even then there 
> were, if I remember correctly, problems with the Rexx.img file.
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> wrote:
>> 
>> As Apple has been selling new hardware with a proper processor, it would be 
>> important to support
>> that hardware platform.
>> 
>> In the past Apple allowed for "fat binaries" which included binaries for 
>> different hardware
>> architectures in the same file. Would it be possible with CMake to have such 
>> ooRexx "fat binaries"
>> created for the MacOS platform? If so, how would one be able to achieve that?
>> 
>> ---rony
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rick McGuire]

I suspect rexx.img would not be compatible between the two because of
endian issues.

Rick

On Mon, Jun 7, 2021 at 10:23 AM CV Bruce  wrote:

> The last time I looked at this, probably ppc/x86, it wasn’t possible
> because Rexx is   invoked during the build. There are tools to combine
> single binaries into “universal” binaries, but what your are really asking
> is can OORexx be cross compiled for a non-native architecture.  Even then
> there were, if I remember correctly, problems with the Rexx.img file.
> Bruce
>
> Sent by Magic!
>
> > On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher 
> wrote:
> >
> > As Apple has been selling new hardware with a proper processor, it
> would be important to support
> > that hardware platform.
> >
> > In the past Apple allowed for "fat binaries" which included binaries for
> different hardware
> > architectures in the same file. Would it be possible with CMake to have
> such ooRexx "fat binaries"
> > created for the MacOS platform? If so, how would one be able to achieve
> that?
> >
> > ---rony
> >
> >
> >
> > ___
> > Oorexx-devel mailing list
> > Oorexx-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Bruce, thank you very much for your insights!

So then maybe one would need two separate builds on each architecture and then 
maybe create
optionally with "lipo" the fat binaries for each dylib.

For this it would be handy to have "stick" versions of ooRexx be buildable, 
because then one could
ask for the stick version of the different architectures and become able to 
build the fat binaries
on a single system.

---rony


On 07.06.2021 16:22, CV Bruce wrote:
> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
> Rexx is   invoked during the build. There are tools to combine single 
> binaries into “universal” binaries, but what your are really asking is can 
> OORexx be cross compiled for a non-native architecture.  Even then there 
> were, if I remember correctly, problems with the Rexx.img file.
> Bruce
>
> Sent by Magic!
>
>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> wrote:
>>
>> As Apple has been selling new hardware with a proper processor, it would be 
>> important to support
>> that hardware platform.
>>
>> In the past Apple allowed for "fat binaries" which included binaries for 
>> different hardware
>> architectures in the same file. Would it be possible with CMake to have such 
>> ooRexx "fat binaries"
>> created for the MacOS platform? If so, how would one be able to achieve that?
>>
>> ---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

The last time I looked at this, probably ppc/x86, it wasn’t possible because 
Rexx is   invoked during the build. There are tools to combine single binaries 
into “universal” binaries, but what your are really asking is can OORexx be 
cross compiled for a non-native architecture.  Even then there were, if I 
remember correctly, problems with the Rexx.img file.
Bruce

Sent by Magic!

> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  wrote:
> 
> As Apple has been selling new hardware with a proper processor, it would be 
> important to support
> that hardware platform.
> 
> In the past Apple allowed for "fat binaries" which included binaries for 
> different hardware
> architectures in the same file. Would it be possible with CMake to have such 
> ooRexx "fat binaries"
> created for the MacOS platform? If so, how would one be able to achieve that?
> 
> ---rony
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

As Apple has been selling new hardware with a proper processor, it would be 
important to support
that hardware platform.

In the past Apple allowed for "fat binaries" which included binaries for 
different hardware
architectures in the same file. Would it be possible with CMake to have such 
ooRexx "fat binaries"
created for the MacOS platform? If so, how would one be able to achieve that?

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel