Mac crt1.10.5 errata

You’ve got details here - https://github.com/castle-engine/castle-engine/wiki/iOS about symlinking crt1.10.5, the information is problematic owing to MacOS’s SIP (System Integrity Protection).

As I understand it SIP protects /usr/bin and /usr/lib from any unauthorized modifications

You can bypass SIP as follows to properly install crt1.* (I copied them all from the current XCode command line installation)

Boot into recovery terminal
csrutil disable
Boot into recovery terminal
cd /Volumes/<Mac>/usr/lib/
cp ../../Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/crt1.* .
csrutil enable
reboot

The <Mac> part of the path above varies depending on your Mac

Thanks for the info.

I use virtual mac now (through macInCloud), and as I see SIP is not enabled there (csrutil status tells me it’s disabled), with macOS 10.14.

Questions:

SIP info - https://support.apple.com/en-gb/HT204899

Before I did the SIP stuff I just copied crt1.10.5 into /usr/lib - this is before I found the info about what was going on. The result was that crt1.10.5 wasn’t used (obviously SIP at work)

The initial instructions I read on the procedure in FPC forums actually used a symlink. When I came to do the procedure though the filesystem is presented in a root-less state so the root you see in a terminal on a Mac is actually /Volumes/.

Owing to this situation after disabling SIP I copied the files as then I’d know 100% where I’d put them. Sure enough when I rebooted my Mac ls -la /usr/lib/crt1* showed three files (may as well copy them all in case FP starts using another version).

A symlink should be fine though but I would suggest using relative paths as I did above just to be safe.

If SIP is disabled you can do anything Stock Macs have SIP enabled and the only way to turn it off is as stated.

After SIP is disabled with csrutil yes reboot it required. The system tells you an reboot is needed, Presumably this all happens in some part of the Mac Kernel and some flag is checked on loading to decide whether or not to use SIP.

In normal use I guess leaving it turned on is a very good idea as it protects vital system files from nefarious meddling (e.g. virus-like stuff) the choice is up to the owner of the Mac.

While I was writing these instructions I was in the middle of completely resetting my Mac to factory-new state as part of an attempt to get FPC 3.2.0 working (complete fail - no castle-download available). 3.2.0 fixes won’t rebuild Lazarus (error in cocoascrollers, maked as fixed in bug tracker, still broken)

Actually, can’t get the cross compiler in there either so I can’t do any iOS tests (very annoying) - can’t find how to build the source for IOS either…

The best I can get on a Mac is FPC 3.0.5 + Lazarus 2.0.9 (the 3.0.4 + 2.0.8 versions on Sourceforge are badly broken)

I kept notes so I’ve actually got step-by-step instructions.

Thanks for the information about the SIP. So I understand that actually a reboot in the middle is also required? Your original post said

Boot into recovery terminal
csrutil disable
Boot into recovery terminal
...

It should be

Boot into recovery terminal
csrutil disable
reboot

Boot into recovery terminal
...

? I edited https://github.com/castle-engine/castle-engine/wiki/iOS to reflect this.

As for FPC version: I compiled FPC 3.2 fixes + Lazarus fixes last week, for x86_64/darwin. (So, with Cocoa as LCL backend course). So something got fixed. I still got errors when trying to make all cross-compilers for iOS (I was in hurry so didn’t even record them – I’ll get back to it one day).

Checked the docs page, more accurate now

It should be noted that anyone with an up to date Mac that ain’t a cloud instance will 99% have SIP enabled

Oh, yeah you’ve got…

# reboot

You can just type ‘reboot’ and press enter so dunno why it’s got a comment in front of it… Maybe things are different on the cloud Mac?

I’ll give FPC 3.2 fixes a go again tomorrow. I reported the issue around the time I wrote about SIP so they may have put the fix in since my report (no notification to self though)

Thanks!

reboot commented out is just me being sleepy :slight_smile: I improved the wiki page.

Yeah, that bit looks good now.

Not quite sure why you’ve still got the broken instructions first though.

If you do things step by step you’ll most likely do the wrong thing then realise the next step tells you how to do it correctly :slight_smile:

I’d either delete the confusing bit or put in a comment about using csrutil status to find out if you needed to disable SIP in the first place.

After all, the whole complex procedure is only necessary if your Mac says SIP is enabled (99% of the time the answer is yes, of course)

Done!

You say you’ve got 3.2_fixes working?

Using lazbuild on one of the trivial examples I get…

/Users/simon/bin/lazarus/lazarus_2_0/lcl/interfaces/./carbon/carbonbars.pp(16,2) Error: (2023) User defined: only cpu i386 is supported

If I start Lazarus with 3.2 + 2.0.9 then go Tools -> Build … Normal IDE I get failure due to cocoascrollers error

Do me a fave and check on yours please

Just checked the Wiki

Perfect!

I know my comments may seem petty but I always think accuracy is important in documentation - it’s now accurate and unambiguous

Now… getting the actual compiler to work still remains a problem as everything after SIP still breaks :frowning:

This message talks about Carbon. You need to change default LCL widgetset to Cocoa.

(The default is still Carbon for Lazarus on macOS. Which cannot work for 64-bit mac applications, and with macOS Catalina you have to make 64-bit applications only. I think this is a historical artifact, Cocoa was under-developed for some time, but this changed recently. So I guess they’ll change the default to Cocoa at some point.)

Hm, I’m 90% sure I did manage to compile FPC + Lazarus (both from their latest “fixes” branches) on macOS. I didn’t manage to get the cross-compilers on iOS, but I did get the native compiler to x86_64/Darwin (i.e. “modern macOS”).

I’ll check it on the weekend and will let you know 100%.

Your comments are much appreciated :slight_smile: I want to make documentation good. Setting up cross-compilers for mobile platforms is already hard enough :slight_smile:

At the bottom of this you’ll find the relevant part of my build command list, you’ll note that I use…

make LCL_PLATFORM=cocoa CPU_TARGET=x86_64 bigide

I’m making a highly detailed step-by-step list with all the pitfalls noted, for example XCode command line tools no longer includes subversion. The SIP issue is actually from this list.

If/When I can actually deploy to Mac and iOS (got neither ATM) I’ll write it all up properly with specific attention to CGE. I’m doing this for myself but you’ll be more than welcome to put it in the Wiki if you so desire.

I do things from the ground-up when documenting. I wiped the Mac a few weeks ago while ding SIP and when everything works I’ll re-wipe the Mac and do exactly what is says in the instructions.

The benefit of this approach is that you know for a fact that that a factory-clean machine will do exactly what’s expected if you follow the instructions to the letter.

I do the same thing for Windows / Linux + even mobile.

------------- Build Commands -------------
# Install subversion
brew install subversion

# Install FPC 3.0.4 from Sourceforge - not shown

mkdir ~/bin
mkdir ~/bin/lazarus
mkdir ~/bin/freepascal

cd ~/bin/freepascal
svn checkout http://svn.freepascal.org/svn/fpc/branches/fixes_3_2
cd fixes_3_2
svn cleanup --remove-unversioned
make clean all
sudo make install

cd ~/bin/lazarus
svn co https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0/ lazarus_2_0
cd lazarus_2_0
make LCL_PLATFORM=cocoa CPU_TARGET=x86_64 bigide

Release code for 3.2.0 still screws up on the Mac

End result is you can’t install any new components

Reported to bug tracker for the upteenth time. They keep saying it’s fixed and close the ticket which I then re-open and tell em it ain’t

The end-game here is to get anything into the iOS store - that’s not going too well ATM :frowning:

As mentioned on Discord -

  • please point me to the FPC / Lazarus bugreport. They don’t just ignore bugreports in my experience. Maybe they cannot reproduce the problem for some reason or there’s some misunderstanding.

  • Note that you don’t need Lazarus to create iOS applications at all. iOS applications use TCastleWindowBase and don’t depend on LCL. You compile them using the build tool, following https://github.com/castle-engine/castle-engine/wiki/iOS (which of course should be upgraded now to use FPC 3.2.0).

https://bugs.freepascal.org/view.php?id=37140

Note the related + duplicates as well

Dude just asked me a stupid question

I’ve not used build tool for anything other than compiling a few demos and ATM I want CGE to be used as part of the app - other bits are LCL-based.

I’ll give the build tool a go on Mac to at least see if I can get a demo running on iOS

Just testing 3.2.0 iOS build as per wiki’s test_compilation.lpr

Yipee - more missing libraries… Time to go play with SIP again…

Free Pascal Compiler version 3.2.0 [2020/05/31] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Darwin/iPhoneSim for x86_64
Compiling test_compilation.lpr
Assembling (pipe) test_compilation.s
Linking libtest_compilation.dylib
ld: file not found: /usr/lib/dylib1.o
An error occurred while linking
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode

There’s are copies of dylib at…

[email protected] /tmp % locate dylib1.o
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/dylib1.o
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/lazydylib1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/dylib1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/lazydylib1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/lazydylib1.o

Further investigation shows some other likely problem object files…

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/bundle1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/crt1.10.5.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/crt1.10.6.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/crt1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.10.5.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.o
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/lazydylib1.o

I think that the SIP instructions should be to copy *.o into lib as the others may be used but we just don’t know it (yet)

I’m going to do that now…

Suggested modification for SIP instructions…

Change…
cp ../../Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/crt1.* .
to
cp ../../Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/*.o .

I just went thru the SIP stuff and did exactly that which adds dylib1, lazydylib1 and bundle1

Compilation now works for x86_64 with warnings as follows

Free Pascal Compiler version 3.2.0 [2020/05/31] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Darwin/iPhoneSim for x86_64
Compiling test_compilation.lpr
Assembling (pipe) test_compilation.s
Linking libtest_compilation.dylib
ld: warning: building for iOS 5.1 is deprecated
ld: warning: building for iOS, but linking in object file (/usr/lib/dylib1.o) built for macOS
ld: warning: building for iOS, but linking in object file (test_compilation.o) built for iOS Simulator
ld: warning: building for iOS, but linking in object file (/usr/local/lib/fpc/3.2.0/units/x86_64-iphonesim/rtl/sysinit.o) built for iOS Simulator
ld: warning: building for iOS, but linking in object file (/usr/local/lib/fpc/3.2.0/units/x86_64-iphonesim/rtl/system.o) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib//libc.tbd) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcache.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcommonCrypto.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcompiler_rt.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcopyfile.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcorecrypto.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libdispatch.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libdyld.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/liblaunch.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libmacho.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libremovefile.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_asl.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_blocks.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_c.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_configuration.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_containermanager.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_coreservices.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_darwin.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_dnssd.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_featureflags.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_info.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_m.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_malloc.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_notify.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sandbox.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_kernel.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_platform.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_pthread.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_trace.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libunwind.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libxpc.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_kernel_host.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_platform_host.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_sim_pthread_host.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_kernel.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_platform.dylib) built for iOS Simulator
ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libsystem_pthread.dylib) built for iOS Simulator
1 lines compiled, 0.8 sec
[email protected] /tmp % ls /usr/lib/lazydylib1.o
/usr/lib/lazydylib1.o

Looked at the bugreport https://bugs.freepascal.org/view.php?id=37140 . Well, one side must have made a mistake – either the fix was not done as they claim, or you accidentally have Lazarus installation pointing to the old sources (from SVN revision without the fix; you can see in Lazarus options where does it look for it’s own sources).

I’ve not used build tool for anything other than compiling a few demos and ATM I want CGE to be used as part of the app - other bits are LCL-based.

To be clear, using the build tool and TCastleWindowBase require a different approach, without LCL forms, to the application.

LCL doesn’t have a widgetset working on iOS with OpenGL control, at least as far as I know. They had a custom-drawn widgetset in LCL, but it was limited and not supporting OpenGL control anyway (and I don’t know whether it worked on iOS anyway). So there’s no way to simply recompile LCL application with OpenGL to iOS (whether using CGE or not), AFAIK.

That is why we have TCastleWindowBase and build tool, that work on all CGE platforms.

So if you want iOS, you need to use TCastleWindowBase, and not TCastleControlBase (or anything else from LCL, like LCL forms). You could have TCastleWindowBase only for iOS if you want (and share code with TCastleControlBase version), or just switch to TCastleWindowBase for all platforms.

That is why we advise TCastleWindowBase on https://castle-engine.io/manual_cross_platform.php .

Of course I understand you still want to have Lazarus working on macOS, as an IDE to develop, and you can use it to make a version for macOS/Windows/Linux. But for compiling CGE applications to iOS – Lazarus is not really needed.