Compiling for Mac-OS

[mdijkens]

For a customer I have created a utility in QB64 (console-mode).
It's relatively small and simple (some REST calls via SHELL "wget ..." to update csv-files)
I develop everything on Windows 10 and use the latest QB64pe x64 3.12

Now it's finished and need to compile it for Mac-OS (customer uses macbooks everywhere)
Since I don't have a Mac, I use a VirtualBox with Mac Big Sur (11?) for some time now to compile my QB64 programs for a Mac.
This always worked, until now...
When tested by customer they see binary stuff scrolling by very fast in a terminal window; as if the executable is displayed instead of executed...
Since I know nothing about Mac, I don't know what goes wrong here.
Anyone?

[TerryRitchie]

For a customer I have created a utility in QB64 (console-mode).
It's relatively small and simple (some REST calls via SHELL "wget ..." to update csv-files)
I develop everything on Windows 10 and use the latest QB64pe x64 3.12

Now it's finished and need to compile it for Mac-OS (customer uses macbooks everywhere)
Since I don't have a Mac, I use a VirtualBox with Mac Big Sur (11?) for some time now to compile my QB64 programs for a Mac.
This always worked, until now...
When tested by customer they see binary stuff scrolling by very fast in a terminal window; as if the executable is displayed instead of executed...
Since I know nothing about Mac, I don't know what goes wrong here.
Anyone?

Does your code compiled with version 3.11.0 work correctly on your customer's system? If so this may be a dependency issue. Unfortunately I don't have a Mac any longer to test this theory. The binary stuff in the terminal is probably error messages scrolling by. Is there a way to capture that output?

[mdijkens]

For a customer I have created a utility in QB64 (console-mode).
It's relatively small and simple (some REST calls via SHELL "wget ..." to update csv-files)
I develop everything on Windows 10 and use the latest QB64pe x64 3.12

Now it's finished and need to compile it for Mac-OS (customer uses macbooks everywhere)
Since I don't have a Mac, I use a VirtualBox with Mac Big Sur (11?) for some time now to compile my QB64 programs for a Mac.
This always worked, until now...
When tested by customer they see binary stuff scrolling by very fast in a terminal window; as if the executable is displayed instead of executed...
Since I know nothing about Mac, I don't know what goes wrong here.
Anyone?

Does your code compiled with version 3.11.0 work correctly on your customer's system? If so this may be a dependency issue. Unfortunately I don't have a Mac any longer to test this theory. The binary stuff in the terminal is probably error messages scrolling by. Is there a way to capture that output?

Not sure about 3.11 (not so easy to test for me; don't want to bother customer too much with trial and error)
It is not errormessages we see in terminal. it much more looks like:

╧·φ■☺♥☻♀àÇ!↓H__PAGEZERO☺↓╚☻__TEXT☺@♫@♫♣__text__TEXT"☺♂"♦♦Ç__stubs__TEXTå*♂☺0♠å*♂♦Ç♠__stub_helper__TEXT╕0♂☺Ä    ╕0♂☻♦Ç__gcc_except_tab__TEXTH:♂☺h      H:♂☻__const__TEXT░C♂☺Y5☺░C♂♦__cstring__TEXT    y♀☺K╗☺  y♀☻__objc_methname__TEXTT4♫☺<T4☻__unwind_info__TEXTÉ4♫☺l♂É4♫☻↓╪☺__DATA_CONST@♫☺Ç@♫Ç♥♥♣►__got__DATA_CONST@♫☺8☺@♫♥☺__mod_init_func__DATA_CONST8A♫☺88A♫♥  __const__DATA_CONSTpA♫☺áApA♫♦__cfstring__DATA_CONST►â♫☺@►â♫♥__objc_imageinfo__DATA_CONSTPâ♫Pâ♫☻↓(☻__DATA└♫☺i└♫@♥♥♠__la_symbol_ptr__DATA└♫☺└♫♥/☺__objc_selrefs__DATA@╚♫☺►@╚♫♥♣►__objc_classrefs__DATAP╚♫P╚♫♥►__data__DATA`╚♫☺4♂`╚♫♦__common__DATAá╙♫☺P╙e♦☺__bss__DATA≡ªt☺ú√☻♦☺↓H__LINKEDIT└w☺Ç♣☼@w♣☺☺"Ç0☼êê☼°    Ç
☼└♠@◄☼X

To me it seems the application is not recognized as an application but maybe some other file-type that makes it list its content ?
The fact that this customer already has a hard time using terminal command make me wonder if there's just one step missing that other (experienced) customers did right automatically?

[mdijkens]

If anyone with a Mac wants to give it a try, please do
  mdAnswerIntents.zip (Size: 461.01 KB / Downloads: 25)

You will get an error/message to supply a token but at least we know if/that it works then

To run it completely create an account & token on openai.com and put that in the ini file
and make sure you've got wget installed (explained in ini file)

[DSMan195276]

Is it possible the customer did not mark the program as executable? If you gave it to them as a zip file then the flag wouldn't be carried over. Other options like `.tar.gz` would carry over file permissions like the executable bit and might be a better option for giving the program to the customer (though I don't know if `.tar.gz` is the preferred one on Mac OS or if they like something else).

[mdijkens]

Is it possible the customer did not mark the program as executable? If you gave it to them as a zip file then the flag wouldn't be carried over. Other options like `.tar.gz` would carry over file permissions like the executable bit and might be a better option for giving the program to the customer (though I don't know if `.tar.gz` is the preferred one on Mac OS or if they like something else).

Yes that's what I've been thinking... This customer certainly is not capable of doing that

I created the zip in the Mac VM to make sure not to loose properties/attributes.
I'm not sure if mac-user (after unzipping) is supposed to double-click the file without extension or the .command file to start the program?
I think in my first attempt I only send the customer the file without extension (zipped in Mac VM) so without the .command file

So also still wondering if it normally is enough to only send the compiled executable without extension (just 1 file) in a zipfile created in my Mac VM?

[SpriggsySpriggs]

Have you tried running this program in your own VM?

[NakedApe]

Howdy. I tried expanding the zip file, but the unArchiver said the contents were corrupted. On the second try it worked with complaints from the utility... The program ran on my Mac asking for the security token. I'm running it on an M1 Mac with Sonoma 14.2.1. Good luck with it.

Ted

[mdijkens]

Howdy. I tried expanding the zip file, but the unArchiver said the contents were corrupted. On the second try it worked with complaints from the utility... The program ran on my Mac asking for the security token. I'm running it on an M1 Mac with Sonoma 14.2.1. Good luck with it.

Ted

This is great news! (well not that it was corrupt zip first time) THANKS TED
Basically means you got it running!

Did you have to do something with the application before you could run it? Then I can create a readme.txt for dummies 
Is there a better/safer way to zip/archive this on mac? I only found in Finder > right mouseclick > compress
Do I also need to include the .command file?

Really like to get this sorted robust for future also

[Kernelpanic]

@mdijkens, I'm not sure if mac-user (after unzipping) is supposed to double-click the file without extension or the .command file to start the program?

I don't have a Mac, but from the way the file looks, you probably have to click on mdAnswerIntents_start.command to start the actual program. It's like a bat file.

Code: (Select All)

cd "$(dirname "$0")"

./mdAnswerIntents &

osascript -e 'tell application "Terminal" to close (every window whose name contains "mdAnswerIntents_start.command")' &

osascript -e 'if (count the windows of application "Terminal") is 0 then tell application "Terminal" to quit' &

exit