Cross platform linux mac

Как кросскомпилировать из Linux для MacOS? ::)

Стек MS простой mingw для сборки wine для тестирования (хотя есть нежданчики ну да ладно)

А что делать для MacOSX? Собрать можно для неё? А как? Ну я сейчас гуглю но вдруг кто сразу может пнуть в нужном направлении или просто что-то дельное подсказать. Но ладно собрать, если можно то соберу, а вот ещё более прикольный вопрос, а каким боком можно запустить приложение собранное для Mac на Linux? Или может какой онлайн сервис есть? Ну я бы рад конечно на реальной машине проверять, но эта как его, они стоят как самолёт.

Ну в общем если есть чё по радужной OS буду рад =) Модераторы велкам 😀

Cast export MSG=»У вас вроде есть макось и вы кодите» su -c jollheef ; wakeonlan -p 8 beastie

никак, покупать макбук

или конпелять у знакомых маководов

никак, покупать макбук Что прям вообще,вообще никак? =(

или конпелять у знакомых маководов

У тебя есть Мак? Если да то будешь моим друганом!? 😀

У тебя есть Мак? Если да то будешь моим друганом!? 😀

кхм-кхм, я подумаю на эту тему 🙂

стыдно признаться, но мне макбук, в общем это самое, подарили

лежит в шкафу и иногда достаётся исключительно для конпеляния

Сборка под mac не отличается от сборки под линукс. Тот же make да pkg-config —cflags —libs sdl2 и вперёд.

А вот запустить под линуксом ты это вряд ли сможешь. Тестить можешь например на travis (но если честно, я это сам ещё не пробовал).

Ну я, шучу конечно. ::)

Пойду гуглить, вдруг на гитбахах кто-то что-то запилил, ибо даже при возможности конпелять через кого-то не комельфо, ещё я напрягать кого-то буду, ну нафиг =) Если ничего не найду то просто выпилю всё что связано с mac сборкой =)

Можно через гитхаб вроде, используя их CI/CD. Но лично я не пробовал.

lol, а я умудрился не заметить! Спасибо бисти

Ща попробую, надеюсь там можно билд скачать

Сборка под mac не отличается от сборки под линукс. Тот же make да pkg-config –cflags –libs sdl2 и вперёд.

Да это я понимаю, но хотелось собрать под mac на linux хосте. =) Не могу же я gcc main.c -o apple и запиндюрить apple в mac на запуск =)

Я боюсь васяносборок, osx хоть и вроде бесплатна, но скачать яблоко не даёт. Ну я попробую всё же, где бы только образ без малвари найти.

А что делать для MacOSX? Собрать можно для неё? А как?

Эпол прилагает изрядные усилия, что бы предотвратить это. Так что покупка эплодевайса — наиболее правильное решение.

Как вариант — запуск макоси в виртуальной машине. Но:

• Танцы с бубном гарантированы.
• Дикие тормоза.
• Скорее всего более-менее свежие версии macOS не заработают.
• Свежий SDK идет в комплекте со свежим Xcode.
• Свежий Xcode требует свежей macOS.

И это, разве SDL поддерживает Metal? В сентябре все OpenGL и GL|ES приложения превратятся в тыкву и под macOS, и под iOS, и под tvOS.

что за нубы на лоре? https://github.com/tpoechtrager/osxcross — все работает, сам юзаю для релиза под мак. Имей ввиду, лучше юзать gcc8.3+, в 8.2 были траблы

Я боюсь васяносборок, osx хоть и вроде бесплатна, но скачать яблоко не даёт.

Она бесплатна, но лицензия запрещает ее использовать на железе отличном от железа эпол.

Ну я попробую всё же, где бы только образ без малвари найти.

Есть какие-то большие ресурсы, где описано как установить это дело на стороннее железо. Есть списки совместимого железа. Есть модули ядра, которые позволяют завести железяки, которые не поддерживаются ядром макоси.

И это, разве SDL поддерживает Metal?

В сентябре все OpenGL и GL|ES приложения превратятся в тыкву и под macOS, и под iOS, и под tvOS.

Уууу, мне девелопить своё поделие ещё год как минимум наверное, погуглил и таки да начиная с 12 версии opengl переводят в разряд устаревших технологий. Кто-то пишет что уже траблы (ну там в основном steam публикации использующие glmgr и их магаз ) Но так как я один и мне сейчас просто собирать, то смысла сейчас в поддержке mac уже не вижу. Я один у меня всё скромно, лишние траблы не к чему ыходят. Спасибо за инфу!

Значит на текущий момент дропаю поддержку mac, благо это легко, для этого мне просто ничего не надо делать ))))) Разве что при случае просто попробую собрать и запустить что-то на радужной если кто минут на 15 уделит мне время со своей машинкой =)

Ну, с новостями про OpenGL всё стало печально для меня, но ссылку на это я отложил просто ещё не добрался до пробы, но спасибо попробую

Источник

QtCreator: Qt кросс-компиляция из linux 64 в linux 32, win32, win64 и Mac OS X; upx, usb, dmg, etc

Библиотека Qt позволяет делать действительно кроссплатформенные приложения. Единожды написанный код можно откомпилировать под многие операционные системы. Но проблема именно в слове «компилировать», т.к. подразумевается, что необходимо перезагрузиться под целевую систему, иметь в ней настроенную среду разработки, установленный и настроенный зоопарк библиотек. Спасает кросс-компиляция — компиляция, производящая исполняемый код для платформы, отличной от той, на которой исполняется.

Кросс-компиляция для Windows 64

Обычно одной из наиболее востребованных проблем является сборка Windows-версии своего приложения, изначально разрабатывающегося под Linux. Пример решения этой проблемы можно увидеть тут или на русском. Необходимо создать mkspecs-конфигурацию, положить файлы Qt в соответствующие директории и всё. Компилировать Qt в таком случае не обязательно, можно скачать бинарники с официального сайта.
У такого подхода есть несколько минусов: 1) QtCreator об установленной таким образом библиотеке ничего не знает; 2) Официальной сборки Qt для Windows x64 не существует. И если с первой проблемой ещё как-то можно бороться, то против второй поможет только компиляция…

Перед кросс-компиляцией не забудьте поставить непосредственно сам кросс-компилятор (ищется в пакетом менеджере по названию «mingw»). И скачать исходники qt-everywhere с официального сайта. В директории mkspecs распакованного архива копируем папку win32-g++ в win64-x-g++ и корректируем содержимое файла qmake.conf. У меня получилось следующее:

По сути в файле спецификации были заменены только пути.

Я выполнял configure со следующими параметрами:
./configure -xplatform win64-x-g++ CROSS_COMPILE=x86_64-w64-mingw32- -prefix /usr/local/qt4win64 -no-webkit -no-phonon -no-phonon-backend -no-script -no-scripttools -no-multimedia -no-qt3support -fast -nomake demos -nomake examples -nomake tools -device-option -little-endian -qt-zlib -qt-libpng -qt-libjpeg -openssl-linked -no-fontconfig -no-3dnow -no-ssse3 -continue
Здесь собираю минимальную версию Qt без webkit, phonon, multimedia и т.п. Полный список опций можно посмотреть по команде ./configure —help

Соответственно, для такой сборки должен быть установлен пакет g++-mingw-w64-x86-64, содержащий в себе x86_64-w64-mingw32-g++ (в убунту пакет надо ставить отдельно).

Далее make && sudo make install. На первом этапе компиляции используется родной системный компилятор, он собирает необходимые утилиты для linux, которые будут использоваться для сборки уже windows-бинарников.
После установки у меня в /usr/local/qt4win64/bin лежат PE32+ DLL и несколько ELF 64-bit LSB executable, в том числе: qmake, uic, moc, rcc. Вот они то и пригодятся для QtCreator!

После установки не удаляйте распакованную директорию — она используется.

Кросс-компиляция для Windows 32

Аналогична компиляции для Win64. За исключением того, что есть официальная сборка, и саму библиотеку компилировать не нужно! Достаточно собрать qmake, uic, moc, rcc.

Кросс-компиляция для Mac OS X

Кросс-компиляция для мака тоже очень похожа, за исключением того, что надо будет собрать и компилятор. Я собирал по этой инструкции. Это отняло полный день времени и кучу нервов. В процессе будет нужна рабочая Mac OS X (как минимум на виртуальной машине) с установленным XCode, чтобы взять оттуда необходимые файлы. При компилировании своих Qt-приложений запущенная Mac OS X не нужна.

Помните, в Mac OS X для линковки с библиотекой .a-файлы не нужны.

Настройка QtCreator

Сначала нужно добавить в список все установленные компиляторы. Инструменты — Параметры — Сборка и запуск — Инструментарии:

QtCreator обычно нормально определяет ABI, но лучше перепроверить. Так же можно заметить, что системный x64 GCC в linux умеет генерировать и 32-битные приложения. Однако это не отменяет того, что также необходимы 32-битные версии библиотек.

После компиляторов можно добавить профили Qt:

Вот при добавлении профиля и пригодятся собранные ранее qmake, uic, moc, rcc, ведь нужно выбрать директорию с qmake. Жёлтый значок с восклицательным знаком слева от профиля означает warning, но QtCreator может использовать такой профиль Qt. А вот если значок красный, то профиль нерабочий. Такое может случиться при неправильной структуре каталогов. Или если удалить директорию, в которой компилировали Qt.

Следующие настройки нужно делать в каждом создаваемом проекте.
Для добавления конкретного профиля Qt надо при активном проекте зайти на вкладку «Проекты» (Ctrl+5):

По умолчанию в списке «Изменить конфигурацию сборки» есть только системный профиль Qt. Зато в списке кнопки «Добавить» есть все профили Qt, добавленные в параметры сборки.

В основных настройках сборки необходимо проверить пару библиотека-компилятор. Чтоб и то и другое было от одной и той же операционной системы.

Этапы сборки «qmake» и «Сборка» QtCreator ставит по умолчанию. А вот особые этапы «upx» и «dmgbuild» я добавил вручную для своего проекта. Этап «upx» выполняется каждый раз при нажатии на кнопку «Собрать проект». Однако если исполняемый файл не был изменён, то upx вернёт ошибку, что файл им уже обработан. В случае ошибки следующий этап не вызывается, т.е. dmg-файл обновится только если upx отработал успешно.

Для работы этапа upx он должен быть установлен в системе. Однако даже работая в linux-окружении и поставленный из пакетного менеджера upx умеет ужимать приложения: linux32/64, win32, macos32/64. Далеко не для всех проектов upx-сжатие реально нужно, этап показан скорее для примера.

Для этапа «dmgbuild» я воспользовался скриптом make_dmg. Ему нужны права root, поэтому добавил скрипт в файл /etc/sudoers

Изменения в проектном файле и использование сторонних библиотек

В моём проекте используется libusb, а это далеко не часть Qt. Также необходимо было включить платформенно-зависимую реализацию HID. В проектный файл были добавлены строки:

В Mac OS X и Linux линкуемся с системной libusb, в Windows в зависимости от разрядности линкуемся с libusb-1.0-32.dll.a или libusb-1.0-64.dll.a. Помним, что .a-файл может быть переименован, но зависеть приложение всё-равно будет от libusb-1.0.dll. В Linux параметры для libusb берём через системную утилиту pkgconfig. Кроме libusb подключаем для каждой операционной системы необходимые системные библиотеки и иконки.

Удобно разнести итоговые файлы для разных операционных систем по директориям. Сделать это можно так:

Цель win64-x-g++ относится к win32, однако в проектном файле идёт последней и переписывает настройки.

Источник

Cross-compiler for Linux on Mac OS X?

I’ve been reading lots of documents on the internet about creating a cross compiler for linux on mac os x but can’t seam to get any to work.

It seams as if no one can help me with the question: Getting GMP to work with GCC 4.5.2

Is there any easy’er way to create a cross compiler?

2 Answers 2

1. install the xcode base build tools
2. install the optional xcode command line tools
3. install homebrew
4. install the homebrew build tools
   4.1 brew install crosstool-ng mpfr gmp grep
   4.2 brew tap homebrew/dupes
5. create a case sensitive volume using «disk utility»
6. use this volume to build the tool chain itself
   6.1 generate a base configuration (for me this is an arm cortex a8)
   6.1.1 ct-ng arm-cortex_a8-linux-gnueabi
   6.2 use menuconfig (ct-ng menuconfig) to tweak the configuration
   6.2.1. disable fortran and java (c compiler)
   6.2.2. turn off static linking (c compiler)
   6.2.3. change the paths to be on the volume you created above (paths and misc options)
   6.2.4. remove dmalloc (debug facilities)
   6.3 invoke the build:
   6.3.1 ulimit -n 1024
   6.3.2 ct-ng build

with much thanks to the crosstools-ng list.

Источник

Cross Platform Desktop Application — Windows+Mac+Linux [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 10 months ago .

I’m building an application for multiple desktop platforms: Windows, Mac, and maybe later for Linux.

I was wondering which programming language and IDE combination would be the best for me:

1. Programming language need to be whether C# (preferred) or Java.
2. Core libraries must be shared between all platforms, means all platforms must link to a single core library (by library I mean a list of classes and functions).
3. Windows and Mac are in priority, Linux app is for future plannings.
4. Design of the app is completely custom, it doesn’t follow any guidelines of each platforms.

I’m stuck between these three solutions:

1. Use Xamarin.Mac + Visual Studio for Windows and link the core classes between them.
2. Use GTK# for the whole project and compile multiple builds for each platforms.
3. Use Java for the whole project and compile multiple builds for each platforms.

For #2 and #3, I need an advice that which language is more suitable for me, considering the design of my application. I mean, which one has a better GUI building ability for my goal?

BTW GTK# uses different libraries for each platforms, so that should be an clutter for my core architecture, or not?!

7 Answers 7

Three years later and Javascript is now also a strong contender in this debate.

There are multiple options within the space.

Even Microsoft has shipped Visual Studio Code, the cross platform version of their development environment, which is written in Javascript.

The benefits include utilizing the many available web libraries, and building/using your web development skills.

This sounds like a job for Xojo or something similar: http://www.xojo.com

Mac, Windows, Linux builds with easy GUI design and native apps. Custom UI easily done also, and you’d then have one code base for all three platforms. You can download and use the software for free to develop and test, only requires a license once you decide to build your app.

You can also conside Livecode

Livecode: http://livecode.com For any platform except web, it is opensource and it includes mobile targets as well, if your code is flexible enough to not being C# or Java.

An option is to build the core logic in a compiled library using C# and GUI independence and then plug it to livecode, leaving the UI work for that tool.

«GTK# uses different libraries for each platforms», do you mean different rendering back ends (such as X11, Cairo)?

You only need to build your GTK# app once. However, you do have to bundle the GTK# runtime (which is different for Windows and Mac) with your app. Banshee is a good example you can follow.

Probably your best bet is to use Nevron Open Vision. It is a cross-platform, C# based User Interface Platform, that implements most of the controls you need to build enterprise-ready applications. It is the framework behind MyDraw (www.mydraw.com) — a professional drawing program similar to Visio. MyDraw is built completely with Nevron Open Vision and does not require any other third-party libraries. We mainly develop it under Windows and just compile it to Mac. Soon we are going to add support for Linux and WebAssembly hosts.

Microsoft just launched .NET MAUI, a cross-platform GUI framework that builds on Xamarian.forms.

As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately call .NET MAUI.

This seems to meet all of your requirements. They do not explicitly mention Linux in their article, but claim to support it in the description on the Github Repo.

It depends on the audience of the app: Consumer mass market or business/IT

If its mass market consumer facing

Electron or native UI, perhaps with shared non-UI code. Visual Studio Code was made with Electron, for example (last I checked). Google Flutter is a new entrant worth evaluating. Dropbox is Python (or used to be). It is a lot of work (a) getting Python packaged properly for smooth x-platform install, and (b) GUI work will take a long time. Sadly, for mass market consumer apps (not utilities for IT people but beautiful designs for the masses like Dropbox, Skype) you will be spending a ton of time getting the installation system to work and getting the app to look and feel appropriate. This is an extremely time consuming endeavour no matter what path you take.

• Consumer: Java? I don’t think Java is a great fit for consumer desktop although I could be wrong. There are some Java packaging systems that are leaner/all bundled in. I’d also say JVM software companies tend to go under (more on this later). FreeMind the free mind mapper, is a good example of what can be achieved in Java.
• Consumer: .NET? Yes, for the Windows side. Then use something native for Mac and shared libraries for non-GUI code. There is «.NET Core» aka Mono but its not fully matured at this time for Mac. Mono has been around for over half a decade and I haven’t seen it mature for a consumer app. Ask: How many .NET Core apps are in the Mac app store? I hope it gets better but as of this writing (2020) there’s very few notable ones.

Business app or IT tool

If its a basic business app or utility where a basic UI is okay, I’d evaluate Xojo and/or LiveCode mainly for comparison sake. Xojo is fairly close to .NET. Google Flutter as well since it’s up and coming. By the time you read this, Flutter may be the best choice.

B2B: Java? This is a pretty tried, tested and true solution for «heavy» enterprise apps. You might not have end-users love you given Java apps tend to eat up memory. But for enterprisey apps the main concern is that the very intense business logic will work. For IT tools, it depends. If it’s a 3-screen utility program, avoid Java. If it’s a complex ERP then Java is good. Remember to look around for different packaging tools to avoid consumer headaches with the JVM. Again, one Java desktop app I like is Freemind. It’s a great example of making a reasonable desktop app in Java. I have used it in both Windows and Mac and it’s great. You can also look at Kotlin or Groovy (for test cases) which compile to Java byte code.

B2B .NET? There is so much to unpack here. The key is, in my biased view, .NET Windows desktop development is about 2X-4X faster development time than Windows Java desktop development. From making the GUI, to better code completion, to faster compile times, to less packaging and install snags. That said, at the time of this writing the «.NET Core» or Mono are pretty thin for MacOS. I really, really hope this changes. But I’ve been waiting years for Mono or .NET Core to provide a full suite for MacOS without the limitations and it hasn’t yet happened. If it’s an enterprise app, you might be able to get away with using .NET Core for Mac. But please first build a basic .NET Core «hello world» app with all the control/libraries you want to use. Then try building an installer for it on MacOS, and find someone random with a Mac to see if it actually installs and runs. You may find you’re struggling in this area today (although I hope it gets better, it hasn’t for years).

Overall Notes on Cross Platform

If this is a smaller app which doesn’t need a fantastic UX and super-deep OS integration, then I’d consider Xojo or LiveCode, perhaps for the UX elements. Like @merlucin said, you can write the core logic in something shared- perhaps C#, python, etc.

Here’s why- Xojo and LiveCode have been around for 10 years now. They are more about keeping things consistent. Whereas I find .NET and QT changes all the time. You have a lot of costs of keeping up with the Joneses and maintaining installers. So for a small app or utility- an XML editor, IT helper tool, Xojo or perhaps LiveCode will help you get there sooner.

When you hit the build button on Xojo, for example, it literally makes 3 executable files for Windows, Mac and Linux. Compare that to the madness of packaging a cross platform Python app, or even packaging a .NET app for Windows, to be honest.

The tradeoff is these tools- Xojo and LiveCode often end to be missing a few critical things you need, requiring a bit of a hack. You can read around their forums. Xojo is a bit like .NET although LiveCode is a different programming paradigm entirely based on «stacks».

Keep in mind developer happiness too. Many developers wont want to code in Xojo or LiveCode because they are lesser known languages. So ensure you get buy-in. What happens if you get laid off and have 5 years of experience in Xojo? Hmm.

In your evaluation, no matter what you choose— you must compile a basic GUI app in the platform you’re evaluating and get 3 people to install it correctly on a Mac. You’ll be shocked at the libraries and madness needed. Especially if you’re a web developer, you’d see that just maintaining installers is a ton of work across 3 platforms. Never mind GUI consistency.

Источник