Recent

Author Topic: The steps to create a 64-bit application using Lazarus 1.8.4 on OSX Mojave are?  (Read 9759 times)

Gizmo

  • Hero Member
  • *****
  • Posts: 831
Further to this thread and several others like it (http://forum.lazarus-ide.org/index.php/topic,39533.0.html?PHPSESSID=dnbfhggl9110tn9ousnnrhv7r4), there is clearly a bit of a panic for those of us who release Apple OSX applications which will soon no longer work on OSX because they are 32-bit and not 64-bit.

I've used Lazarus for years, always with the default options when I build and compile (except for Windows where I create a 64-bit version). So on OSX, I've built 'Carbon' based applications, using the default target processor, operating system etc, and I get an OSX app file at the end which works well on toher peopls Mac's; 32 or 64 bit alike. 

From what I gather this will soon not be the case, and the 32-bit applications created by Lazarus will no longer function on OSX. But a) there is no 64-bit Lazarus installation for OSX as far as I can tell. So I won't be able to build 64-bit app files unless I tweak the settings in the project options. But when I do that, it seems you need to know exactly which of them interact with others, because if one is set incorrectly, the others won't work either. I read in some places about terminal switches but the full syntax never seems to be given, so I don't know how to do it via terminal either.

So can anyone give me a steer as to exactly what the process is of creating a 64-bit application using Lazarus 1.8.4 on a 64-bit OSX Mojave system with XCode 10? My Mac is 64-bit, by the way, but I've always used the 32-bit Lazarus IDE with it.

ChrisR

  • Full Member
  • ***
  • Posts: 247
I do not have Mojave (I use High Sierra), but I would suggest you get Lazarus 2.0rc1 - the Cocoa support has improved a lot.
 Open your project with Lazarus and click Project/ProjectOptions - in the "Config and Target" panel set the "Target CPU family" to be "x86_64"; in the "Additions and Overrides" panel click on "Set LCLWidgetType" pulldown and set the value to "Cocoa". Now compile your project - with any luck it will work OK. If you have issues, see if they are posted on the Mantis bug tracker and if your issue is new try to create a minimal project to demonstrate your issue.

Hansaplast

  • Hero Member
  • *****
  • Posts: 674
  • Tweaking4All.com
    • Tweaking4All
Hi Gizmo,


Running Lazarus (for me anyway) came with a few challenges.
I'd recommend using a release candidate or from trunk (SVN) - quite a lot of work has been done by folks like Dmitry to get Cocoa better.


ChrisR already described how to compile a 64 bit Cocoa app.
With a fresh install, you may need to tinker a little (see this forum topic).
Even after doing all that, I still find refresh issues. So my current way of working is by setting up a Virtual Machine (using Parallels Desktop Lite - free in the App Store) with High Sierra. The compiled results of your applications will work well under Mojave as well.


I have yet to find a way to get Lazarus to run properly under Mojave.

cobata

  • New Member
  • *
  • Posts: 49
  • Programmer-analyst
    • COBATA Software - Research, Development, Testing, Consulting
I think, that it's useful to paste some info (at the moment I wrote it, I was a little bit nervous):
From Apple:
"Available on macOS Mojave
When users on macOS Mojave first open a notarized app, installer package, or disk image, they’ll see a more streamlined Gatekeeper dialog and have confidence that it is not known malware.

Note that in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple."

You have to NOTARIZE your EXISTING (already) software, for your new customers running macOS Mojave in order they to can use it!? NOTARIZATION, lets say that (just) attaches a ticked to your already SIGNED software - (NOTARIZATION) not useful software functuanality for the customer that involves time and effort!!! By my information macOS Mojave requires and allows only 64bit apps... I will postpone its usage to the end of the world where that depends by me. It is Apple commercial policy imposing the usage just of their own products against all native cross-platform technologies, destroing businesses and in this way against the reqular Mac Users, but without posts like this They will never know!
With other words: The Customer can not update to the latest software versions, because Apple disallowed 32bit apps store submitions and the native cross-platform development environment vendors are still not ready with the 64bit compilers and graphical user interfaces. According to their Road Map, they will be ready at the end of 2019. AND Because of the GateKeeper the software (in Apple store) can not be downloaded by the new Customer... But the taxes are paid!
COBATA Software - Research, Development, Testing, Consulting
https://www.COBATA.com/

Hansaplast

  • Hero Member
  • *****
  • Posts: 674
  • Tweaking4All.com
    • Tweaking4All
Yeah, I'm with you that Apple is not really "motivating" me to continue developing for macOS (also note that Microsoft is following this trend in their usual half-assed way, so in the next few years I'll probably will be a fulltime Linux user and hobby developer).


Unbelievable; One hurdle after the other. I've spend 2 days trying to get my application signed and working, to be surprised by one issue after another (like the sandboxing no longer allowing the use of OpenSSL, etc). Thanks to Phil's awesome explanation I managed to resolve a few of these issues, but still have 2 major issues to fix.


As for notarizing apps (not through the app store); Mojave (for now anyway) seems to be OK with apps that are notarized, but how happy we should be with this next step, I don't know. It seems though that getting your app notarized is easier than the signing and sandboxing ordeal. We will see, I'll do my first attempt in the next few days.



p.s. 32 bit apps work just fine under Mojave, just not from the App Store.

Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Yeah, I'm with you that Apple is not really "motivating" me to continue developing for macOS (also note that Microsoft is following this trend in their usual half-assed way, so in the next few years I'll probably will be a fulltime Linux user and hobby developer).
It is actually a better solution than codesigning only. I suppose there will be a solution for you and me (Apple products are not very interesting to me outside of hobby)
Specialize a type, not a var.

cobata

  • New Member
  • *
  • Posts: 49
  • Programmer-analyst
    • COBATA Software - Research, Development, Testing, Consulting
Hansaplast,

I think the same regarding Linux...
I have no time to develop software useful functionalities, because of all those Apple Store/ Windows Store ever changed developer agreements/ requirements NOT useful for the Customer (and this useless effort is since 2 years...)!
Thanks for the OpenSSL info!
You probably know about the OpenGL deprecation in favor to Metal 2 (by Apple) - It is in Embarcadero Road Map to be done till the end of 2019.

Regards
COBATA Software - Research, Development, Testing, Consulting
https://www.COBATA.com/

Hansaplast

  • Hero Member
  • *****
  • Posts: 674
  • Tweaking4All.com
    • Tweaking4All
@Thaddy; I agree - I do not think signing and notarizing is a bad way to do things at all. I can however imagine an easier way to do this. I've spend about 75% of my development time with all these "features" and about 25% on the actual functionality of my application. Why not provide a tool that handles all of this, and gives developers useful information in case something is wrong. The OpenSSL issue is something I ran into by accident (thanks again Phil!). And an error message like "nw_path_close_fd Failed to close guarded necp fd 7 [9: Bad file descriptor]" doesn't really tell me much.


@cobata; I see we share a similar path haha. I recently played with Delphi Community Edition (pretty cool), but they are still on 32 bit, and I don't like Firemonkey at all, so that is a no-go for now. I'll admit that I do not like XCode either. Maybe I'm getting too old for this hahah. And as you can read in my response to Thaddy; I'm "wasting" the majority of time, trying to figure out what new hurdle I have to overcome, instead of spending time on developing the actual functionality my app is supposed to provide.
In case you've looked at Windows; enjoy the new limitations there as well (UWP, signing, App Store stuff, etc).
The only platform that works super smooth seems to be Linux, but I'd hate to limit myself just to one OS.

Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Well, if programmers like you and me don't have access then time and history! will tell they are wrong:
Real innovations come from unexpected places. Probably not you and me but you'll never know.
Specialize a type, not a var.

Hansaplast

  • Hero Member
  • *****
  • Posts: 674
  • Tweaking4All.com
    • Tweaking4All
Agree; innovation may come from just doing something you enjoy, without the intend to make something magnificent. If it's not something innovative, we'd at least offer other users some fun tools to work with.
For me; it's a hobby (programming) and I like to make my little tools available to others (for free) on as many platforms as possible. Taking the motivation away from folks like us, that enjoy developing, well .. I'm not sure how "good" that in the end will be for the average user, time will tell ...  ;)

cobata

  • New Member
  • *
  • Posts: 49
  • Programmer-analyst
    • COBATA Software - Research, Development, Testing, Consulting
Nice words guys, I like the optimism... - just the developers can optimise :-)
COBATA Software - Research, Development, Testing, Consulting
https://www.COBATA.com/

Gizmo

  • Hero Member
  • *****
  • Posts: 831
Thanks for the help with this guys.

Regarding the question I asked, I tried what you suggested and built a VM using High Sierra in Parallels Free Edition and tried the RC of Lazarus v2.0. I then tried compiling a project using x86_64 as CPU type and Cocoa widgets. It all went well, so thank you there.

Having determined those steps I returned to my 64-bit host Mac running 64-bit Mojave where I have spent some time installing 1.8.4 and configuring GDB and so on and I also managed successfully to compile my existing project there. So all was looking good.

However, the problem is that despite setting the CPU type in the project options and rebuilding the project, when it runs, it still runs as a 32 bit application! I checked this by going to the System Information menu of my Mac (press the apple icon top left, then the Option key and the top entry changes to 'System Information'). If I then go to 'Software' then 'Applications', and sort by the 64-bit column or by the name of my project, it says "No" instead of "Yes".

So I too am getting tired of Apple nonsense. As it is, I have already spent £300 this year buying a code signing certificate so I can sign my open source program. Not because I think I need to but because Windows and OSX do not like running unsigned applications anymore. Add all this hassle for OSX development and I am beginning it is not worth my time and effort. All I want to do is open my project on OSX, build it, and run it, and find it runs as 64-bit.

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
....
However, the problem is that despite setting the CPU type in the project options and rebuilding the project, when it runs, it still runs as a 32 bit application! ...

Gizmo, as well as setting 64bit, did you also select the Cocoa widget set ?

 (ProjectOptions->CompilerOptions->ConfigAndTarget->SelectedAnotherLCL.....)

Seems widget set directive overrides the 'bit-ness'.

The 'file' command from command line and your binary name is useful to confirm.

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Hansaplast

  • Hero Member
  • *****
  • Posts: 674
  • Tweaking4All.com
    • Tweaking4All
Gizmo, I ran into this issue for maybe different reasons, so I'm not sure if it helps;
In the past, for some reason my Lazarus kept setting the compiler to "/usr/local/bin/ppc386" - which results in 32 bit apps.
Make sure under Tools->Options that "Compiler Executable" is set to "/usr/local/bin/fpc" to get 64 bit apps.


As you can read in this post I'm slowly getting sick and tired of Apple and Microsoft shenanigans as well. But ... I try to stay optimistic and find a solution. I do enjoy developing little applications still enough to try to hang in!  :)
« Last Edit: October 30, 2018, 11:04:22 am by Hansaplast »

brentk

  • Newbie
  • Posts: 1
@Thaddy; I agree - I do not think signing and notarizing is a bad way to do things at all. I can however imagine an easier way to do this. I've spend about 75% of my development time with all these "features" and about 25% on the actual functionality of my application. Why not provide a tool that handles all of this, and gives developers useful information in case something is wrong. The OpenSSL issue is something I ran into by accident (thanks again Phil!). And an error message like "nw_path_close_fd Failed to close guarded necp fd 7 [9: Bad file descriptor]" doesn't really tell me much.

@Hansaplast I found this thread with a Google search for the obscure error message that you mentioned: "nw_path_close_fd Failed to close guarded necp fd 7 [9: Bad file descriptor]" -- I am getting this error for another app on OSX Mojave, and I'm trying to track down the cause and what it means (the app's author would love to know too!). Given this thread, I'm guessing it has something to do with either 64-bitness, SSL, or Mojave's sandboxing requirements? Any tips would be greatly appreciated!

PS. I believe this app I'm trying to run is written in Python with QT libraries.

 

TinyPortal © 2005-2018