Re: [Oorexx-devel] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[P.O. Jonsson]

The steps I describe are manual steps so nothing for the automated build (yet), 
but I put my builds in my Dropbox 
 for 
Mac users, with a short howto, there is a link from the sourceforge site.

Regarding the original message above: I checked and on a freshly installed 
Catalina (not an upgrade) there is a stdlib.h (more than one actually) I did 
not have to apply the patch you proposed on that machine to make the build 
process work.

I will make some more tests to confirm that a build from Mojave or High Sierra 
works without any problems on Catalina, I think this is the case but I will 
signal if it is not.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 04.02.2020 um 17:47 schrieb René Jansen :
> 
> Hi P.O.,
> 
> that is great! Did you add this to the Jenkins task so we can upload the 
> daily builds for macos to sourceforge?
> 
> I hope someone fixes the cmake, but it is not my favourite tool. (I) is 
> disastrous of course, (II) is not that bad, but will require admin auth if I 
> am not mistaken, (III) can be avoided if we add a requirement to reboot after 
> install, or if rxapi smells funny.  
> 
> Let’s postpone Catalina for the Mac build machine for now. I does not bring 
> any advantage for ooRexx anyways. So I add my vote to yours.
> 
> best regards,
> 
> René.
> 
> 
> 
>> On 4 Feb 2020, at 16:47, P.O. Jonsson > > wrote:
>> 
>> Dear René,
>> 
>> I have built from source now on Catalina and all the build tools work and I 
>> can get a working installation as before on Mojave or High Sierra.
>> 
>> The build tools have slightly different (higher) version numbers but as long 
>> as the test suite runs without problems I assume it is ok.
>> 
>> I am building to ~/Applications/ooRexx5 locally (same as on the Jenkins 
>> slave) and then I use Disk Utility to make a .dmg.
>> 
>> All the user needs to do is to click the .dmg and then drag the content into 
>> ~/Applications/ (or to any place of choice, the current build for Mac is 
>> truly relocatable!) and adding ~/Applications/ooRexx5/bin to the path.
>> 
>> For Mojave and older I add the following to .bash_profile in the users home 
>> directory to make it work permanently: 
>> 
>> # Setting PATH for ooRexx
>> export PATH=~/Applications/ooRexx5/bin:$PATH
>> 
>> That is all that is needed for installing ooRexx on Mac.
>> 
>> For Catalina I used .zshrc instead .bash_profile when using the z shell. An 
>> alternative is to switch to bash and use .bash_profile, both works.
>> 
>> With some minor changes to cmakelists.txt the cpack command can be used to 
>> create a .dmg directly from the build, it even installs to the right place 
>> so you can omit the make install step.
>> 
>> unfortunately:
>> (i) the dmg is empty, the installation is not included
>> (ii) the symlink inside the .dmg that you drag the installation to points to 
>> /Applications rather than to ~/Applications
>> (iii) pre- and postinstall scripts are missing (such as for making the path 
>> addition permanent, stopping rxapi etc).
>> 
>> Maybe with some detective work this is a way forward. 
>> 
>> There should be a decision if we want the Mac build machine migrated to 
>> Catalina. Currently I would vote against, Catalina is the Millennium (or 
>> Windows 8) of Apple :-(
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se 
>> 
>> 
>> 
>>> Am 02.02.2020 um 18:27 schrieb René Jansen >> >:
>>> 
>>> Hi P.O.,
>>> 
>>> I understand your points. I have always been ‘bleeding edge’ and I mostly 
>>> enjoy solving the problems. I agree that Apple make a lot of trouble for us 
>>> but I always have a linux machine which is one 'git pull' away from me 
>>> being able to continue whatever I am working on.
>>> 
>>> Personally, I used the zsh shell for years and years already and I would 
>>> not have noticed the switch if Cataling did not break autoenv that I used a 
>>> lot. But I think the decision to discontinue the use of 32bit executables 
>>> is a really daft decision; it is really a downward slope: z/OS can run 24, 
>>> 31 and 64 bit code alongside and call eachother, OS/2 could thunk 16 and 32 
>>> bit code, then Linux made it impossible to mix libraries and now Apple only 
>>> has 64 bit. Even Raspberries can (with nearly everything except Raspbian) 
>>> mix ARM7 and aarch64.
>>> 
>>> I have a plan to have a .dmg installer ready very soon, for my own use but 
>>> maybe as a standard for the portable mac version. I’ll let you know this 
>>> week, my plan was to just run it from the Jenkins machine after the builds. 
>>> I need to look at your portable distribution first. I found you can turn 
>>> the notarization off recursively for a directory tree with:
>>> 
>>> sudo xattr -r -d com.apple.quarantine $OOREXX_HOME
>>> 
>>> even without turning off SIP. So a .dmg installer seems fine and has my 
>>>

Re: [Oorexx-devel] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[René Jansen]

Hi P.O.,

that is great! Did you add this to the Jenkins task so we can upload the daily 
builds for macos to sourceforge?

I hope someone fixes the cmake, but it is not my favourite tool. (I) is 
disastrous of course, (II) is not that bad, but will require admin auth if I am 
not mistaken, (III) can be avoided if we add a requirement to reboot after 
install, or if rxapi smells funny.  

Let’s postpone Catalina for the Mac build machine for now. I does not bring any 
advantage for ooRexx anyways. So I add my vote to yours.

best regards,

René.



> On 4 Feb 2020, at 16:47, P.O. Jonsson  wrote:
> 
> Dear René,
> 
> I have built from source now on Catalina and all the build tools work and I 
> can get a working installation as before on Mojave or High Sierra.
> 
> The build tools have slightly different (higher) version numbers but as long 
> as the test suite runs without problems I assume it is ok.
> 
> I am building to ~/Applications/ooRexx5 locally (same as on the Jenkins 
> slave) and then I use Disk Utility to make a .dmg.
> 
> All the user needs to do is to click the .dmg and then drag the content into 
> ~/Applications/ (or to any place of choice, the current build for Mac is 
> truly relocatable!) and adding ~/Applications/ooRexx5/bin to the path.
> 
> For Mojave and older I add the following to .bash_profile in the users home 
> directory to make it work permanently: 
> 
> # Setting PATH for ooRexx
> export PATH=~/Applications/ooRexx5/bin:$PATH
> 
> That is all that is needed for installing ooRexx on Mac.
> 
> For Catalina I used .zshrc instead .bash_profile when using the z shell. An 
> alternative is to switch to bash and use .bash_profile, both works.
> 
> With some minor changes to cmakelists.txt the cpack command can be used to 
> create a .dmg directly from the build, it even installs to the right place so 
> you can omit the make install step.
> 
> unfortunately:
> (i) the dmg is empty, the installation is not included
> (ii) the symlink inside the .dmg that you drag the installation to points to 
> /Applications rather than to ~/Applications
> (iii) pre- and postinstall scripts are missing (such as for making the path 
> addition permanent, stopping rxapi etc).
> 
> Maybe with some detective work this is a way forward. 
> 
> There should be a decision if we want the Mac build machine migrated to 
> Catalina. Currently I would vote against, Catalina is the Millennium (or 
> Windows 8) of Apple :-(
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 02.02.2020 um 18:27 schrieb René Jansen > >:
>> 
>> Hi P.O.,
>> 
>> I understand your points. I have always been ‘bleeding edge’ and I mostly 
>> enjoy solving the problems. I agree that Apple make a lot of trouble for us 
>> but I always have a linux machine which is one 'git pull' away from me being 
>> able to continue whatever I am working on.
>> 
>> Personally, I used the zsh shell for years and years already and I would not 
>> have noticed the switch if Cataling did not break autoenv that I used a lot. 
>> But I think the decision to discontinue the use of 32bit executables is a 
>> really daft decision; it is really a downward slope: z/OS can run 24, 31 and 
>> 64 bit code alongside and call eachother, OS/2 could thunk 16 and 32 bit 
>> code, then Linux made it impossible to mix libraries and now Apple only has 
>> 64 bit. Even Raspberries can (with nearly everything except Raspbian) mix 
>> ARM7 and aarch64.
>> 
>> I have a plan to have a .dmg installer ready very soon, for my own use but 
>> maybe as a standard for the portable mac version. I’ll let you know this 
>> week, my plan was to just run it from the Jenkins machine after the builds. 
>> I need to look at your portable distribution first. I found you can turn the 
>> notarization off recursively for a directory tree with:
>> 
>> sudo xattr -r -d com.apple.quarantine $OOREXX_HOME
>> 
>> even without turning off SIP. So a .dmg installer seems fine and has my 
>> preference.
>> 
>> best regards,
>> 
>> René.
>> 
>> 
>>> On 2 Feb 2020, at 18:07, P.O. Jonsson >> > wrote:
>>> 
>>> Hi René,
>>> 
>>> I have a new computer running Catalina as well (not updated but clean 
>>> built). I noticed the problems but did not get around to inform you all. 
>>> Sorry.
>>> 
>>> Re "I keep my MacBook always on the latest OS“
>>> 
>>> This is no longer a good strategy with MacOS; you have to wait at least to 
>>> the first update (10.15.1 for Catalina) before you can be sure it works. It 
>>> is now on 10.15.3 and it is still no good, compared to Mojave or High 
>>> Sierra. Apple have started to ship beta versions of the OS :-(
>>> 
>>> 1. As of Catalina Apple have decided to use Z as the standard shell instead 
>>> of Bash. Unknown why but it messes things up
>>> 
>>> 2. There is no support for 32 bit code any more, apparently.
>>> 
>>> I could make my ooRexx installation work by switching 

Re: [Oorexx-devel] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[P.O. Jonsson]

Dear René,

I have built from source now on Catalina and all the build tools work and I can 
get a working installation as before on Mojave or High Sierra.

The build tools have slightly different (higher) version numbers but as long as 
the test suite runs without problems I assume it is ok.

I am building to ~/Applications/ooRexx5 locally (same as on the Jenkins slave) 
and then I use Disk Utility to make a .dmg.

All the user needs to do is to click the .dmg and then drag the content into 
~/Applications/ (or to any place of choice, the current build for Mac is truly 
relocatable!) and adding ~/Applications/ooRexx5/bin to the path.

For Mojave and older I add the following to .bash_profile in the users home 
directory to make it work permanently: 

# Setting PATH for ooRexx
export PATH=~/Applications/ooRexx5/bin:$PATH

That is all that is needed for installing ooRexx on Mac.

For Catalina I used .zshrc instead .bash_profile when using the z shell. An 
alternative is to switch to bash and use .bash_profile, both works.

With some minor changes to cmakelists.txt the cpack command can be used to 
create a .dmg directly from the build, it even installs to the right place so 
you can omit the make install step.

unfortunately:
(i) the dmg is empty, the installation is not included
(ii) the symlink inside the .dmg that you drag the installation to points to 
/Applications rather than to ~/Applications
(iii) pre- and postinstall scripts are missing (such as for making the path 
addition permanent, stopping rxapi etc).

Maybe with some detective work this is a way forward. 

There should be a decision if we want the Mac build machine migrated to 
Catalina. Currently I would vote against, Catalina is the Millennium (or 
Windows 8) of Apple :-(

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 02.02.2020 um 18:27 schrieb René Jansen :
> 
> Hi P.O.,
> 
> I understand your points. I have always been ‘bleeding edge’ and I mostly 
> enjoy solving the problems. I agree that Apple make a lot of trouble for us 
> but I always have a linux machine which is one 'git pull' away from me being 
> able to continue whatever I am working on.
> 
> Personally, I used the zsh shell for years and years already and I would not 
> have noticed the switch if Cataling did not break autoenv that I used a lot. 
> But I think the decision to discontinue the use of 32bit executables is a 
> really daft decision; it is really a downward slope: z/OS can run 24, 31 and 
> 64 bit code alongside and call eachother, OS/2 could thunk 16 and 32 bit 
> code, then Linux made it impossible to mix libraries and now Apple only has 
> 64 bit. Even Raspberries can (with nearly everything except Raspbian) mix 
> ARM7 and aarch64.
> 
> I have a plan to have a .dmg installer ready very soon, for my own use but 
> maybe as a standard for the portable mac version. I’ll let you know this 
> week, my plan was to just run it from the Jenkins machine after the builds. I 
> need to look at your portable distribution first. I found you can turn the 
> notarization off recursively for a directory tree with:
> 
> sudo xattr -r -d com.apple.quarantine $OOREXX_HOME
> 
> even without turning off SIP. So a .dmg installer seems fine and has my 
> preference.
> 
> best regards,
> 
> René.
> 
> 
>> On 2 Feb 2020, at 18:07, P.O. Jonsson  wrote:
>> 
>> Hi René,
>> 
>> I have a new computer running Catalina as well (not updated but clean 
>> built). I noticed the problems but did not get around to inform you all. 
>> Sorry.
>> 
>> Re "I keep my MacBook always on the latest OS“
>> 
>> This is no longer a good strategy with MacOS; you have to wait at least to 
>> the first update (10.15.1 for Catalina) before you can be sure it works. It 
>> is now on 10.15.3 and it is still no good, compared to Mojave or High 
>> Sierra. Apple have started to ship beta versions of the OS :-(
>> 
>> 1. As of Catalina Apple have decided to use Z as the standard shell instead 
>> of Bash. Unknown why but it messes things up
>> 
>> 2. There is no support for 32 bit code any more, apparently.
>> 
>> I could make my ooRexx installation work by switching to the bash shell but 
>> we might need to revise the strategy for distributing ooRexx for Mac.
>> 
>> On the positive side: the oo installer from Bsf4ooRexx works out of the box, 
>> it uses dynamic links so it is not affected by the shell change!
>> 
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> 
>>> Am 02.02.2020 um 15:51 schrieb René Jansen :
>>> 
>>> I keep my MacBook always on the latest OS and Xcode levels, and suddenly, 
>>> with MacOS Catalina 10.15.2 and the latest XCode the ooRexx build missed 
>>> stdlib.h
>>> 
>>> I googled stackoverflow a bit and encountered a lot of solutions that did 
>>> not work. I will not withhold the one that did work from you: 
>>> 
>>> sudo ln -s 
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* 
>>> /usr/local/include/
>>> 
>>> best r