Testers need.

I created a new installer for OSX that includes a 64-bit only Cocoa version of FPC and Lazarus. I don't have Catalina installed, so I am looking for testers and any variety of OSX.

The installer is a shells script that will walk you through Xcode, Homebrew or Macports, as well as setting up the debugger. You will also be prompted for a install folder that defaults to $HOME/Development/FreePascal, but you can change the install path during installation.

This setup will use configuration files inside of their own folder and will not interfere with you existing versions of Lazarus as long as you donot choose the same folder as your already existing fpc and lazarus locations. To uninstall simply delete the folder you choose for install.

Download setup.sh from:

https://www.getlazarus.org/download/?platform=macintosh

Then ...

chmod +x setup.sh
./setup.sh

After installation is complete you will get convenience lazarus.app file in you install folder which can be moved anywhere including to your Applications folder.

Please note, this setup program installs a 64 bit fpc and lazarus with Cocoa only. It does not install a 32 bit fpc and does not use the Carbon widgetset.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191014/ea9ca8d7/attachment.html>

Anthony Walter wrote

Testers need. ... https://www.getlazarus.org/download/?platform=macintosh

Thank you for making this.

The script itself installed all parts without problems.

I am having some difficulty with the gdb code signing: From your code signing link: https://www.getlazarus.org/setup/macintosh/ Step 6 only shows local certificates on my system. A prior step should be:
- Select "Keychains: System" from the left side window

Then the following line has two problems on my system: codesign -s gdb-cert /opt/local/bin/ggdb
my location ios /usr/local/bin
my file is gdb (not ggdb)

The following line:
sudo launchctl load /System/Library/LaunchDaemons/com.apple.taskgated.plist produced this error:
/System/Library/LaunchDaemons/com.apple.taskgated.plist: service already loaded

Then when I tried to run the example project1 in newly installed Lazarus. I got this error:
The GDB command:
"-exec-run"
returned the error:
",msg="Unable to find Mach task port for process-id 36454: (os/kern) failure (0x5).\n (please check gdb is codesigned - see taskgated(8))""

Anthony Tekatch wrote

I am having some difficulty with the gdb code signing:

You are aware that the IDE now supports LLDB too?
https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

Martin,

Yes I read the message requesting lldb testing the other day. I haven't taken the time to test it yet, but as I understand it's a great project that will hopefully allow for better debugging (such as inspecting and changing properties at runtime) but is still missing some important functionality.

About code signing the gnu debugger, yes this page hopefully will help you get started, but I understand it can be a bit finicky.

https://www.getlazarus.org/setup/macintosh/

Most of those steps apply, but the steps to stop the gatekeeper service and restart it may vary a bit depending on your OSX version.

Additionally, there may be a more related problem for OSX Catalina users, as it now is forcing non CLI applications from sources other than the official app store to be notarized before being allowed to run. The same gatekeeper service is responsible for this on Catalina. Apparently it can take hours to generate a certificate for you program.app files, and you need to manually insert xml data into the plist data. I've read that Apple has suspended this requirement until sometime in 2020, giving developers more time to adjust, but to me it seems rather draconian.

Here is a useful tip though, according to the first comment on a recent HN article you can bypass notarization checks when running your visual apps by right clicking them and selecting open the first time:

https://news.ycombinator.com/item?id=21179970

If that doesn't work I've heard holding alt when left clicking your program.app will also bypass notarization checks.

And finally, Ryan Joseph put together this useful information and github page related to fpc Catalina development:

https:/msg51807.html

The short of all this information is: We need more testing. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191014/bbe11a61/attachment.html>

Well, yes one day..

But for today, it means you no longer need to codesign gdb.

lldb comes with apples tools. (afaik). And lldb is already codesigned.

The IDE combines it with fpdebug in order improves the display of watches (more pascal-ish).

Also, about code signing gdb, my setup script will install it for you using either Homebrew or Macports, you get to choose. You may want to try these alternate steps and skip the debugger install steps (the script already installed it), and proceed with the code signing steps:

https://gist.github.com/hlissner/898b7dfc0a3b63824a70e15cd0180154

https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html

If you used Homebrew, then this bit of code will test if the dnu debugger is properly code signed:

SIGNED="$(codesign -dv /usr/local/bin/gdb 2>&1)"
echo $SIGNED

And on Macports use this code:

SIGNED="$(codesign -dv /opt/local/bin/ggdb 2>&1)"
echo $SIGNED

Unsigned gnu debuggers will include this text in $SIGNED:

"object is not signed"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191014/cc86f910/attachment-0001.html>

It worked for me (Catalina). You did a brilliant job. Just curious, why use GDB instead of LLDB? I’ve been using LLDB debugger in VSCode which works really well except for displaying strings is a mess because it shows them as arrays of chars.

Anyways, it didn’t take long to crash though. :) I’m not a Lazarus user but the few times I have used it there were lots of crashes.

Application Specific Information:
*** Terminating app due to uncaught exception 'NSGenericException', reason: '-[NSAlert runModal] may not be invoked inside of transaction begin/commit pair, or inside of transaction commit (usually this means it was invoked inside of a view's -drawRect: method.)' abort() called
terminating with uncaught exception of type NSException

Application Specific Backtrace 1:
0 CoreFoundation 0x00007fff2d50ad63 __exceptionPreprocess + 250 1 libobjc.A.dylib 0x00007fff633f9bd4 objc_exception_throw + 48 2 CoreFoundation 0x00007fff2d50abb9 +[NSException raise:format:] + 189 3 AppKit 0x00007fff2af0a98c _NSRunModal + 152 4 AppKit 0x00007fff2a9d2aa8 -[NSAlert runModal] + 225 5 lazarus 0x00000001062d549a COCOAINT_$$_COCOAPROMPTUSER$crcF62BAB40 + 1130 6 lazarus 0x00000001062d5640 COCOAINT$_$TCOCOAWIDGETSET_$__$$_PROMPTUSER$crc484A2DB2 + 80 7 lazarus 0x000000010625c3ed LCLINTF_$$_PROMPTUSER$crc484A2DB2 + 93 8 lazarus 0x000000010625cd09 LCLINTF_$$_PROMPTUSER$crcB76EAC20 + 185 9 lazarus 0x0000000106125ff0 FORMS$_$TAPPLICATION_$__$$_SHOWEXCEPTION$EXCEPTION + 704 10 lazarus 0x00000001065201a8 LCLEXCEPTIONSTACKTRACE$_$TEVENTCONTAINER_$__$$_HANDLEAPPLICATIONEXCEPTION$TOBJECT$EXCEPTION + 440 11 lazarus 0x0000000106124fca FORMS$_$TAPPLICATION_$__$$_HANDLEEXCEPTION$TOBJECT + 426 12 lazarus 0x00000001061256cd FORMS$_$TAPPLICATION_$__$$_RUNLOOP + 157 13 lazarus 0x00000001062ca7e8 -[TCocoaApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 136 14 AppKit 0x00007fff2a674fd4 -[NSApplication run] + 658 15 lazarus 0x00000001062cac13 COCOAINT$_$TCOCOAWIDGETSET_$__$$_APPRUN$TAPPLICATIONMAINLOOP + 83 16 lazarus 0x000000010612561f FORMS$_$TAPPLICATION_$__$$_RUN + 95 17 lazarus 0x00000001060b405d PASCALMAIN + 701 18 lazarus 0x00000001060d7cdc FPC_SysEntry + 12 19 libdyld.dylib 0x00007fff64758405 start + 1

Regards,
Ryan Joseph

Ryan,

To answer your question, I just haven't taken the time to try out lldb yet. I guess it can be switched to lldb in the Lazarus interface.

About that crash, it probably comes from somewhere in the Cocoa widgetset, which is currently still in development. It's far along enough to enable the Lazarus IDE to run, but still has problems. Unfortunately Catalina and all OSX versions going forward are 64 bit only, and Carbon is 32 bit only, so we're all going to have to help improve the Cocoa widgetset. The means were going to need to fix errors like you posted. Hopefully we can get some patches submitted to Mantis tagged with Cocoa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191014/20328870/attachment.html>

Here is a short video where I demonstrate how to switch between the gdb and lldb inside Lazarus. I also demonstrate how to move docked windows. There is no audio, but anyone should be able to follow along. Interestingly the Cocoa widgetset throws an exception when a docked window is undocked or docked again. Would someone be kind enough to submit this issue to Mantis on my behalf?

https://cache.getlazarus.org/videos/lazarus-lldb.mp4

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191014/39799539/attachment.html>

Anthony Walter wrote

Here is a short video where I demonstrate how to switch between the gdb and lldb inside Lazarus. https://cache.getlazarus.org/videos/lazarus-lldb.mp4

You can add a 2nd configuration via the toolbar. Then use the toolbar to toggle. That way you  (once the conf is added) you only need to select in the toolbars dropdown, instead of having to change 2 fields. (The toolbar is Lazarus 2.1 only)

https://wiki.lazarus.freepascal.org/IDE_Window:_DebuggerClassOptionsFrame

Also, you should NOT use the "lldb debugger (ALPHA)"

There is a "LLDB debugger (with fpdebug) (beta)" which I recommend. It features watches in Pascal format.

If it does not show, then install the package LazDebuggerFPlldb. Mind the FP before lldb.
If you build "bigide" I would have expected it to be there by default.

I'll test the debugger options later.

I tried installing online package manager and got these errors after trying to rebuild: Compile package laz.virtualtreeview_package 5.5.3.1: Exit code 1, Errors: 1

  laz.virtualtrees.pas(68,3) Fatal: Cannot find laz.FakeActiveX used by laz.VirtualTrees of package laz.virtualtreeview_package.

Just tried to actually compile a new project and got:

Error: ld: framework not found Cocoa

along with various lines like

Error: <stdin>:77532:10: warning: section "__datacoal_nt" is deprecated

Do we need to set some additional options?

Regards,
Ryan Joseph

Note to all, the install source I posted comes from a random clone of svn trunk fpc and trunk lazarus put together from whatever was in the svn repository on Saturday. As such it might contain any number of potential bugs. That said, the reason trunk sources should be used is that the Cocoa widgetset is still in a beta state.

Personally I've implemented some OSX core classes in a manner that is much more elegant manner that what's currently used in the Cocoa widgetset and if time permits I may propose some of my changes that could push Cocoa forward in a positive direction. I feel that many of the problems everyone might be experiencing is tied to the specific implementation state we currently have. This is not meant as a dig on the Cocoa LCL widgetset developers, obviously its difficult and tedious work trying to create a 100% compatible and bug free implementation and you work is very much appreciated so please keep it up! I know well get it working.

On a side note, if anyone reading this message has done some work on committing widgetset code to Lazarus, either with the Gtk3 or Cocoa libraries, and would like to coordinate some of my improvements we can take this discussion to private emails or perhaps freenode irc and we can hash out merging my work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/7c917fa0/attachment.html>

On Tue, Oct 15, 2019 at 11:50 AM Anthony Walter via lazarus <

a preview or sneak peek available?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/3985b19a/attachment.html>

Dimitry,

What I've done is created a reference counted class hierarchy to match part of the Cocoa framework. It's only partially done, but it allows Pascal code to be written to simplify interaction with native OSX frameworks and APIs like AppKit in the following ways:

Using NSWindow class as an example:
https://developer.apple.com/documentation/appkit/nswindow

* TNSWindow mirrors NSWindow and uses an automatic reference counting scheme to automatically release objects when they are are no longer needed.

* All methods and properties of NSWindow are provided by TNSWindow and there is no need to pass native objects as handles to functions. It's implicit in Self and the underlying handle is manged by TNSWindow -> TNSResponder -> TNSObject -> and ultimately TFrameworkObject.

* It uses an object oriented hierarchy the same as the Apple frameworks, only translated to Pascal objects. That is you can pass a derived class to methods of other object methods which may expect any less specific class.

* Other classes such as CGContext (TCGContext -> TFrameworkObject) are provided as well as other Apple frameworks classes, all translated to Pascal classes with all the same benefits as outlined above.

My implementation isn't complete, which is to say I haven't wrapped every single Apple framework class in the manner described above. For the extremely limited amount of translations I did complete, I saw a big benefit in my own personal projects on OSX. Most notably the way of organizing code I outlined above allowed me to much more easily understand how to use Apple's frameworks, reduce errors with type safety and automatic object lifetime management, as well as aid in the discovery when combining Apple framework object to accomplish programming tasks. I expect if this were integrated into the Cocoa widgetset it would make development a bit easier. Certainly there is a lot of work involved in defining every Apple framework object in this way, but it provides a certain level of organization and usability that I at least feel makes a big difference when working with native Apple APIs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/fed505c0/attachment-0001.html>

I see. Thanks for the insight

On Tuesday, October 15, 2019, Anthony Walter via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/e58eb7e0/attachment.html>

I have to search my backup drives for some of this code, but I believe I also added a few extra classes to simplify some of the weirdness of Apple's classes. For example I greatly simplified the steps needed to work with CGContext and CGBitmapContextCreate such that it was completely transparent. A TCGBitmap class was defined (not in the framework, but wrapping CGBitmapContextCreate), and it would be compatible with TCGContext, but adding methods for loading, saving, blitting ect.

Also some types have been simplified, NSString becomes regular pascal string, NSRect/CGRect becomes TRectF, and so on.

Obviously defining all these types is definitely a lot of work, but to reiterate it does aid in type safety, object management, and discovery (how to combine the use the Framework objects with each other). One approach to tackling all this work, if anyone decides it's beneficial, might be to add it in gradually for what is needed, which is how I am using it right now. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/824485bc/attachment.html>

On Tue, Oct 15, 2019 at 1:07 PM Anthony Walter via lazarus <

No need (to do it right now).
I was wondering about the approach in general.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191015/7079b7bc/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191018/ec68cfd3/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191018/1fcca0f5/attachment.html>

On Oct 18, 2019, at 3:16 PM, Dan Star via lazarus wrote: On Mojave 10.14.6 I received Framework Not Found with a Linking Error. Is this due to difference between where Majave and Catalina locate Cocoa?

I never could figure it out so I gave up. Maybe there were conflicts with config files from other Lazarus installations.

Regards,
Ryan Joseph

Ryan,

Regarding config files, the lazarus.app file is configured to get and set all configuration data from the install/lazarurs/config folder. There should be no conflicts with other existing installations.

Regarding lazarus 2.2, yes there is a typo in the installer. The lazarus version is 2.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191018/3a9c15d3/attachment.html>

Had to install MacPorts manually on my Catalina Mac.  Used LLVM Lazarus 2.1 installed and runs OK.   Note that GDB Debugger I cannot get to work with Cocoa.

Dan

You do not need the gdb debugger. just switch to "lldb (with fpdebug)"

search the forum announcement board

On 23/10/19 15:37, Dan Star via lazarus wrote: /> Had to install MacPorts manually on my Catalina Mac.  Used LLVM />/> Lazarus 2.1 installed and runs OK.   Note that GDB Debugger I cannot />/> get to work with Cocoa. />>//>/> Dan /> You do not need the gdb debugger. just switch to "lldb (with fpdebug)"

I do not know where to down the fpdebug package so it shows in the Debugger Window for picking. It is not listed there (script didn't install it). Please advise. Thanks.

It is included in Lazarus, but may need to be added as package.

Menu Package > Install Packages

There should be LazDebuggerFPLldb  (ensure FP in the name).

Then rebuild

If you cant find it, the package is in
components/lazdebuggers/lazdebuggerfplldb

Then go to Tools > Options

under debugger > debugger backend

you can change the settings. Instead of gdb, choose usr/bin/lldb (or whatever path lldb has)

lldb comes with the apple tools

https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

On my other Catalina Mac I cannot install LLDB FPDebug.  I get the following error when I rebuild the IDE with fpdebug and laz...fplldb packages:

Build IDE: Exit code 2, Errors: 3
Error: ld: framework not found Cocoa
make[2]: *** [lazarus] Error 1
make[1]: *** [idepkg] Error 2
Error: make: *** [idepkg] Error 2
An error occurred while linking
Error: Error while linking

Xcode 11.1 is installed so I assume the Cocoa Framework (only needed for programming or for Macos too?) is installed too.   Please advise.

I should add that this Mac OS system had a previous 32 bit version of Laz on it that I removed. The Mac OS system Laz 64 runs fine on never had Laz 32 installed. So was a legacy config left behind from Laz 32 that is mucking things up?

Unfortunately I don't have to much experience in the Mac related build process. So someone else will need to answer this.

I can't think how the fpdebug/lazdebugfp package causes this. Can you rebuild the IDE, if you install other packages?

Also do you build from within the IDE, or call make? You may be accidentally building for 32bit. And cocoa does not exist for 32bit.

The 'Build Lazarus" Information window appears OK for Cocoa but just guessing; there is no way to copy this information to the clipboard nor can I find a config file with it.   I looked in ~/tmp and see no build log for today after trying to build again.  Where is the build log file located?   I am building from withing Laz 2.1 MacOS.

If I remove those 2 packages and try to build vanilla Laz MacOS 64 I get the same errors so looks like a configuration problem caused by having had Laz 32 installed previously.

Dan Star wrote

If I remove those 2 packages and try to build vanilla Laz MacOS 64 I get the same errors so looks like a configuration problem caused by having had Laz 32 installed previously.

Maybe go to "configure build lazarus" and choose target cpu (and target OS)

On Fri, Oct 25, 2019 at 10:54 AM Dan Star via lazarus <

Try to build IDE from command-line, instead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191025/47d0d724/attachment.html>

I tried that initially using MacOS and x86-64 but Laz wouldn't build if I spec'd that stating

/Compiler
"/Users/Dan/Development/FreePascal/fpc/bin/x86-64-darwin/fpc.sh" does not support target x86-64-macos./

On Fri, Oct 25, 2019 at 11:12 AM Dan Star via lazarus <

"macos" platform target refers to Classic MacOS (MacOS 9), rather than MacOSX (or the modern name macOS)
You might need to adjust platform target as well to "darwin"

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20191025/81e4ea09/attachment-0001.html>

Same error now:

Build IDE: Exit code 2, Errors: 3
Error: ld: framework not found Cocoa
make[2]: *** [lazarus] Error 1
make[1]: *** [idepkg] Error 2
Error: make: *** [idepkg] Error 2
Linking ../lazarus
An error occurred while linking
Error: Error while linking

so something with config.  Will look up details on how to build from command line and try that.  Thanks.

Is x86-64-macos a typo?
The target OS name is "darwin", not "macos"?

Mattias

The Cocoa LCL passes "-k-framework Cocoa" to fpc.
Check your /etc/fpc.cfg for -XR and -Fl options.
The -XR prepends a path to all -Fl paths.
I don't have Catalina to test, but maybe this works: -Fl/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

Mattias

I have 2 fpc.cfg files and the one in /etc is from year 2017 so I think that one only applies to Laz 32.   The other fpc.cfg is in ~/ Development/FreePascal/fpc/bin/x86_64-darwin/fpc.cfg and is from October 18th 2019.   So inspecting this second file I find:

#ifndef cpupowerpc64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

#ifdef cpui386
-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib

# searchpath for libraries
#-Fl/Users/danstar/Development/FreePascal/fpc/lib
#-Fl/lib;/usr/lib
-Fl/Users/danstar/Development/FreePascal/fpc/lib/$FPCTARGET

# library search path
-Fl/usr/lib/$FPCTARGET;/usr/lib/$FPCTARGET-gnu;/lib/$FPCTARGET;/lib/$FPCTARGET-gnu;/usr/lib/gcc/

And my reading of this is -Fl only applies to PowerPC cpu hardware.   So I am confused what to change.  Any help appreciated.

Martin Frb wrote

You are aware that the IDE now supports LLDB too? https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

Thank you. LLDB did work and helped me find some problems in my program on to get it to work on Mac OSX Catalina.

I upgraded from Mojave to Catalina

executed "xcode-select --install"

And then to find the crt1.10.5 I changed in /etc/fpc.cfg the -Fl behind "#ifdef cpux86_64" from
-Fl/Applications/Xcode.app/Contents/Developer/Toolchain... to
-Fl/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/

Now Lazarus can compile itself.

Mattias

What are the correct file permissions on /etc/fpc.cfg?

root wheel 644

Mattias