Eiffel Studio ARM Apple Silicon M1 - apple-m1

I am hoping to create some software with Eiffel & Eiffel Studio
I have a Mac mini with the Apple M1 Arm Processor.
Is there a port of EiffelStudio to native Mac M1?
Does Eiffel Studio support native MacOS Windowing or is it still requiring Windows?

EiffelStudio 21.11 download page does not list a native build for macOS running on M1, only on x86-64. Provided that there are builds for Linux running on ARM, there should be no obstacles to make a build for M1, though.
As to the GUI part, starting from 21.11, non-Windows installations of EiffelStudio rely on GTK 3, that utilizes Quartz API. So, it should not require X Windows.

For now, EiffelStudio for macos M1 is not yet built officially.
However you can download https://ftp.eiffel.com/pub/beta/nightly/PorterPackage_106046.tar and compile it yourself.
For usual macosx-x86-64 machine, the command from the extracted folder is
./compile_exes macosx-x86-64
You may need to get inspired by config files from PorterPackage/C/CONFIGS/ to have a dedicated config for macos on M1 .

Related

How to mix ARM64 and X64 versions of dotnet core on my MacBook M1

I have a new Macbook Pro (M1) and I need to install multiple versions of dotnet core - my large solution has a mixture of versions, to busy to address that issue right now.
But how to I handle this situation ? (note I have a symlink for the X64 version of dotnet)
I'm not sure if it will work for your specific case, but if you're okay with x64 architecture for all .NET versions, it should work.
Delete usr/local/share/dotnet if you have one.
Download installers with x64 architecture for all .NET versions you need;
You need to figure out which of them will be placed in 64 folder. !! Install them first !! After this inside usr/local/share/dotnet you will have only 64 folder.
Copy all files from usr/local/share/dotnet/64 to usr/local/share/dotnet
Delete usr/local/share/dotnet/64 folder
Install the rest of versions via installer and be sure that thay will be placed in usr/local/share/dotnet NOT in usr/local/share/dotnet/64

Can I build a PyInstaller binary for M1 Macs on an Intel Mac?

I have recently found out that PyInstaller now works on macOS Monterey, so I tried to build a binary. When testing on my Intel machine, it did work as expected. When testing it on an M1 MacBook, however, it failed to work because of "Damaged and cannot open". I think that was because of the incompatibility of Intel apps and M1 apps.
CLang has an option to build for a different architecture, but I don't know if PyInstaller has such parameter that does the same job.
Proof: From the picture, the app is clearly stated to be an "Intel" app.
Thanks for any ideas.
There is a target architecture in the .spec file. I'm have the opposite problem... built on M1 and need to target both.... in the middle of solving the problem but it may be as simple as specifying the Architecture in the .spec file.

Deploying JavaFx for different OS

I' m using netbeans IDE for create JavaFx application on ubuntu.My question that can i deploy installer for MAC Os and Windows OS on ubuntu?
For Mac OS you can look into Bundle Java program for Mac users with maven from GNU/Linux
For Windows look into Inno setup.

Howto use Linux 64 Bit Machine to compile Qt Application for 32 bit armV7

I an developing for an Odroid XU4 which is ARM V7 32 Bit Ubuntu MATE.
I know that I could develop on the embedded device directly, but this is not a suitable setup for my Team. Thus I would like to develop on my 64 Bit Linux maptop and cross compile for the 32 Bit armV7.
I use QtCreator for development
What I did so far to make the cross compile work is
compiled all libraries that I need (e.g. openCV) on my Odroid and
copied them to my Linux 64Bit to use for cross compile
downloaded the correct CrossCompiler (gcc-linaro-7.1.1-2017.08-x86_64_arm-eabi/bin/arm-eabi-g++)
compiled qt 5.9 on the odroid and copied to the linux machine to be used for cross compile
Now I setup a new Kit in qtCreator and define the correct qmake location. This is when I get the error, that the architecture is false (naturally since I compiled it on a 32 Bit)
So the question is, how do I have to build qt in order to us it for cross compiling an app for the target platform armV7 (32 bit) on a 64 bit linux laptop
Any help is very much appreciated.

Deployment of statically linked Qt application backward compatibility

This is my first attempt at making a Qt Application work on different systems.
I have opted for static linking method.I have already compiled the sources of Qt 5.5 and compiled my application with the static Qt. The executable is working fine on my computer.
My operating system is Ubuntu 15.04. But when I tried to run the same executable on Ubuntu 14.04 then I ran into trouble. The key details of the error message are given below.
libstdc++.so.6 cxxabi_1.3.8 not found
I did a standard Google search and realised it was because I had a newer version of it on my machine, the machine where I had created the executable. There were so many different approaches to handle this problem. One of the solutions I saw involved shipping your own copy of libstdc++.so with the executable. But when I tried to copy the .so file to a pen drive, there was a warning saying that the file system does not support such files.
My question is , what am I doing wrong ? Also if I wanted to make the executable target Ubuntu 10.04, what would be the correct procedure handling the backward compatibility issues. I know that one method would be to install the same OS on my machine and then create the executable , is there any other way?
libstd++ is backward compatible but not forward compatible, which means you can run a program with a newer version of libstdc++ than the one you compiled it with but not vice-versa. This is what you experienced.
One way to deal with this issue is using older OS versions as the build machine. When you for example use Ubuntu 14.04 LTS, you'll get this list of compatible target systems.
The build system you're using will probably limit available compilers. On Ubuntu 14.04 you get GCC 4.8, which is good for most C++11 and packages for clang 3.6 are available, which will give you full C++14 support.
Targeting Ubuntu 10.04 will be challenging if you do not want to use a stone age compiler.
The idea of shipping libstdc++ will not help you much because you'll run into the same problem with libc.

Resources