Delphi скомпилировать под linux

Linux Application Development

RAD Studio allows you to develop applications for the target Linux platform. Using RAD Studio installed on Windows machine, you can create a 64-bit Linux application and deploy it to the Linux machine. Developing Linux applications is similar to creating Android apps in RAD Studio. However, for Linux, you cannot create the visual VCL and FireMonkey applications. Here is the list of apps that are available for the Linux platform:

• Console Application
• EMS Package (RAD Server)
• DataSnap
• DataSnap WebBroker
• WebBroker
• Dynamic-link Libraries
• DUnitX Project

Contents

Prerequisites

To develop Linux applications, you need to have the RAD Studio installed on the Windows PC as well as a machine with the Linux platform (can be a virtual machine).

Preparing Your Linux Development Environment

To prepare your development system (PC) and Linux machine for application development with RAD Studio:

Installing Development Packages

To install the development packages on Ubuntu:

1. Right-click your desktop and select Open Terminal.
2. To upgrade the packages you have already installed , type sudo apt update && sudo apt upgrade && sudo apt dist-upgrade in the terminal.
3. Type your user password and press Enter
4. Wait until prompted to agree to the package upgrade operation. Type Y and press Enter
5. Wait until the package upgrade operation is complete. It may take a few minutes to complete.
6. To add the development packages, type sudo apt install joe wget p7zip-full curl openssh-server build-essential zlib1g-dev libcurl4-gnutls-dev libncurses5 in the terminal.
7. Type your user password and press Enter
8. Wait until prompted to agree to the package installation operation. Type Y and press Enter
9. Wait until the pacjage installation operation is complete. It may take a few minutes to complete.

To install the development packages on Red Hat:

1. Right-click your desktop and select Open Terminal.
2. Type yum groupinstall ‘Development Tools’ in the terminal.
3. Press Enter and wait until the package installation operation is complete. It may take a few minutes to complete.

Preparing Your Linux Machine

To create Linux applications, you need to add a virtual machine PAServer:

1. Find the LinuxPAServer21.0.tar.gz file in the following location: C:\Program Files (x86)\Embarcadero\Studio\21.0\PAServer\LinuxPAServer21.0.tar.gz 2. Unpack the LinuxPAServer21.0.tar.gz file.

To use the System.zLib unit on Red Hat:

1. Install the zLib-devel library to your RHEL machine with the following command: sudo yum install zlib-devel 2. Update the local SDK cache.

To use the System.zLib unit on Ubuntu:

1. Install the zLib-devel library to your Ubuntu machine with the following command: sudo apt-get install zlib1g-dev 2. Update the local SDK cache.

Creating a Connection Profile

1. Right-click the folder where you have unpacked the LinuxPAServer21.0.tar.gz file, and then click Open in Terminal.
2. Enter ./paserver in terminal. Then, press Enter.
3. On the Tools > Options > Environment Options > Connection Profile Manager page, click the Add button. The Create a Connection Profile wizard opens.
4. On the Profile information page, enter the following:
   • In the Profile name field, enter the needed name.
   • In the Platform field, click the 64-bit Linux platform.
   • Click Next.
5. On the Remote machine information page, enter the following:
   • In the Remote machine field, enter the IP address or Machine name.
   • Click Test Connection to check if the values are valid.
6. Click Finish.

Adding the Installed SDK to RAD Studio

1. On the Tools > Options > Environment Options > SDK Manager page, click the Add button.
2. In the Add a New SDK dialog, enter the following:
   • In the Select a platform field, click 64-bit Linux.
   • In the Select a profile to connect, select a created profile from the drop-down list.
   • In the Select an SDK version field, the name of the SDK that you just installed will automatically appear. If you have not installed SDK previously, you can do it on this step. If you have already installed SDK, move on to the next step.

Running PAServer on Linux machine

To run the PAServer on your Linux machine:

• Open the terminal, and then run PAServer in the terminal.

Источник

Get started writing Linux apps with Delphi 10.3 and 10.4

Firstly, you need an Ubuntu installation. If you don’t have a physical machine with Ubuntu, you may chose a suitable Virtual Machine, such as VMWare, VirtualBox or Hyper-Visor.

I chose Hyper-V since it is included with Windows 10.

To enable Hyper-V on your Windows installation, Open the “Windows Features” tool and check Hyper-V. If you alse use Visual Studio, you may want to add Windows Hypervisor Platform as well.

A word of advice with regards to storage: Place your VMs on an SSD disk.

Reboot your Windows installation if so instructed.

When ready, Start Hyper-V Manager, and chose Actions | Quick Create… | Ubuntu 18.04.3 LTS

A 1.6Gb download will pursue, so the time depends on your bandwidth.

Before firing up the VM, tweak the new VM config to f.x. 4 CPUs and 8192Mb RAM to give the VM some juice, then power up and go through the base installation.

To manually add the build tools for Ubuntu, open a terminal, and run

The first ensures your VM pull all relevant updates, and the second installs gcc and the suite of build tools for Linux.

Note that you can install PAServers for both Rio and Sydney. Just remember to edit the paserver.config and change the default port number for one of them.

Install it to a folder of your liking, as per the instructions in the link and start ./paserver and enter the (optional) password you want the PAServer to use.

To find the IP address of your local Ubuntu VM, open a terminal and run

The IP address we are looking for is in address 2 – in this case: 172.17.202.68

When you first try to compile a Linux app, start with something simple like a console application.

On the first ever compile, the IDE will prompt you for a connection profile.

Since we didn’t change the configuration, all we need is to fill in the IP address for the host name.
If you entered a password when starting the PAServer, that password is needed here. Remember to click on Test Connection to verify that the PAServer is reachable.

On the first connection, the IDE will download the SDK through the PAServer. This takes a little while and the progress is presented on a desktop-always-on-top progress dialog which is somewhat annoying if you want to do something else while waiting.

After it is complete, you will have a collection of files that allows the linker to find the right link targets for your Ubuntu host.

At this point, your simple console app should be ready to run. It will compile, link, and then upload it to the Ubuntu VM and start it through the PAServer.

By default, it seems that we won’t get to see the actual console where the app runs when run through PAServer, so if you want to run it manually – locate the uploaded file on your installation.
It will typically reside under a long path that reflects the name of your connection and your Windows username. The PAServer folder will be in the same folder where you installed the PAServer-20.0 (if you are using 10.3.3).

Under scratch-dir, you find the folders for your winuser-connection combos.

Under there again, you will find a folder that matches your Delphi project name, and in that folder your executable which you can start with “./exename”.

At this point, you should be able to do the same.

The next step is to download FMX for Linux via GetIt.
Then you can get started on something beautiful like this 😎
File | New | Multi-device application – change target to Linux 64-bit and run!

Lars Fosdal, August 26th, 2020

Postscript:
I have also done this on VirtualBox, but when comparing Hyper-V and VirtualBox it is clear that Hyper-V is much better at managing HW resources – preventing the constant buzz of the CPU cooling fan which was quite annoying when using VirtualBox.

Источник

Особенности портирования сложного модульного ПО написанного на Delphi под ОС Linux

Данное повествование не предназначено для разработчиков, которые не знают что такое Delphi и не умеют на нём программировать. Просьба людей, не имеющих дела с данными средствами разработки, не комментировать статью и не травмировать и без того расшатанные нервы дедушек, упорно продолжающих поддерживать многолетние разработки, написанные с применением данных средств разработки. Предложения переписать всё с нуля на что-то более модное не приветствуются.

Введение

Меня зовут Тимофеев Константин, мне 40 лет и я являюсь ведущим программистом компании 3В Сервис в подразделении, занимающемся системами автоматизации динамических расчётов (САДР). Нашим основными программным продуктом является среда моделирования динамических систем SimInTech (в девичестве ПК Моделирование В Технических Устройствах – 4, сокращённо ПК «МВТУ»).

Исторически данный программный продукт начал развиваться на кафедре «Ядерные реакторы и энергетические установки» (Э7) МГТУ им. Баумана. Первые версии ПК «МВТУ» были разработаны на кафедре под руководством к.т.н. Козлова Олега Степановича. Программный комплекс предназначался для структурного моделирования динамики ядерных энергоустановок. Функционал ПК «МВТУ» заключался в составлении модели системы в виде блок-схемы с последующим автоматическим формированием системы дифференциальных уравнений динамики системы и их численном решении и выводе результатов расчёта на графики. В дальнейшем развитии этой темы к разработке в 2003 году подключился я и на базе ПК «МВТУ-3» мы начали создавать промышленную версию программного комплекса – ПК «МВТУ-4», получившую в дальнейшем название SimInTech. Разработка нового варианта программы потребовала очень серьёзной переработки архитектуры программы и позволила создать комплекс, позволяющий строить полномасштабные модели динамики ядерных энергоустановок, а также систем в других отраслях промышленности, и являющийся достойным конкурентом систем Simulink, AmeSim, VisSim.

В качестве среды разработки для ПК «МВТУ-3» мы использовали Delphi, начиная с версий 3 (и заканчивая версией 5). Выбор данного средства разработки был обусловлен простотой создания графического интерфейса программы и большим количеством компонентов, скоростью разработки по сравнению с разработкой системы на других средствах того времени. Применение этой среды позволило создать достаточно большой по объёму пакет в очень сжатые сроки командой включавшей в себя трёх разработчиков (из которых по факту основным был один).

При разработке следующей версии программы в 2003 году, учитывая достаточно серьёзный объём ранее разработанного кода я также использовал в качестве средства разработки Delphi версии 6. В настоящее время мы используем как основное средство разработки под ОС Windows Delphi 10.3.3. Также надо понимать что хоть основная часть кода написана на Delphi, также в составе комплекса присутствуют модули и на С\С++ , а также на FORTRAN. При этом сам наш программный продукт с тех пор значительно усложнился, оброс большим количеством библиотек и модулей и прошёл значительную эволюцию под влиянием его применения на предприятиях атомной отрасли.

Глава 1: Что мы имеем – архитектура и особенности программного комплекса

Главной составной частью ПК SimInTech является графическая оболочка. Графическая оболочка предназначена для того, чтобы пользователи могли визуально составлять блок-схемы технологических систем моделируемых объектов. В её основе лежит система векторной графики собственной разработки, которая включает в себя набор объектов – базовых графических примитивов как то: линии, полигоны, эллипсы, текстовые вставки, блоки, группы примитивов, линии связи, системные контролы (чекбокс, комбо-бокс, однострочный текстовый редактор). Поверх объектов-примитивов лежат групповые объекты – контейнеры графических примитивов (страницы). Контейнер – это то, что обеспечивает отрисовку схемы целиком и её редактирование – т.е. передачу примитивам событий клавиатуры и мыши). Также каждый контейнер включает в себя и объект – скриптовую машину для обеспечения динамизации изображения (изменения цвета положения, текста в зависимости от расчётных параметров схемы). Встроенная скриптовая машина позволяет делать как техническую анимацию, так и проводить расчёты, по сути она представляет собой встроенный язык программирования общего назначения.

Графическая оболочка предоставляет пользователю следующие сервисы:

— составление схемы из блоков, создание видеокадров из примитивов.

— работу с библиотеками блоков.

— вывод параметров расчёта на графики, в текстовые таблицы, в файл, в OPC, в shared memory.

— синхронизация различных моделей и совместный расчёт.

— загрузка плагинов для блоков\схем\слоёв.

— работа со звуком.

— редактирование текстов скриптов с подсветкой кода.

— внешнее управление программой через встроенный COM-сервер (это использовалось для автоматизации расчётов в связке с другими программами).

Оболочка является наиболее сложной частью системы в точки зрения пользовательского интерфейса и объёма кода. Оболочка была написана на Delphi с применением достаточно разнообразных компонентов, из которых кроме стандартных контролов (кнопок полей ввода, комбо и чекбоксов) необходимо выделить следующие:

— для вывода рассчитанных значений на графики – Tee Chart Pro.

— для редактирования текстов с подсветкой – первоначально SynEdit, впоследствии TBCEditor.

— для работы со звуком – DSPack.

— для вывода деревьев и построения редакторов списков сигналов\объектов\свойств блоков\параметров расчёта\дерева библиотеки\дерева структуры проекта – VirtualTreeView.

— для работы с базами данных для отдельных модулей системы – zeosdbo.

— для трехмерной технической анимации – GLScenes.

— для разного – JEDI VCL + JCL -отдельные контролы, некоторые библиотеки например расчёт хешей и контрольных сумм.

Кроме того, в программе как DLL подключается несколько библиотек на C и FORTRAN, например модуль шифрования RSA и расчёта MD5 хеша. Для рендеринга графики схем в данный момент в Windows-версии программы используется Direct2D, который позволяет сделать достаточно плавную и производительную техническую анимацию (в том числе и с большими по размеру растровыми текстурами).

К графической оболочке могут подключаться модули – плагины, которые обеспечивают расширение функций программы на разных уровнях. Например для каждого блока на схеме мы можем указать какой плагин его обслуживает.

Система плагинов построена на основе наследования их от виртуальных базовых классов. То есть есть общий модуль где описываются базовые классы. В оболочке от него ничего не наследуется, а в подгружаемых DLL от базовых классов наследуются те или иные блоки расширения, в которых мы делаем override базовым методам. Для создания плагинов в каждой из библиотек реализована фабрика классов, которая по заданному имени внутри модуля создаёт заданный объект расширения. Такой подход позволяет сделать очень гибкую структуру плагинов и иметь там не только методы (как в классических интерфейсах) но и объекты\ссылки на системные структуры\и так далее. Минусом является то, что ограничивается возможность использования других компиляторов – т.е. при реализации плагина должен использоваться тот же компилятор что и оболочки (ну или совместимый по генерируемому коду). Кроме того, внутри плагинов могут находится и окошки – т.е. вспомогательный интерфейс.

Соответственно, для полноценной реализации расширений графической оболочки в программе строго необходим общий менеджер памяти как для плагинов, так и для библиотек, в качестве какового в данный момент используется fastmm5, прописанный первым модулем как в коде оболочки так и в коде плагинов. Это позволило обеспечить прозрачную для всех модулей работу со строками и выделение памяти для массивов и объектов, критически необходимо это в первую очередь для работы со строками, когда строка возвращается как результат функции из плагина например.

Общий объем исходного кода только графической оболочки составляет приблизительно 215073 строк кода (это чистый код самого проекта, без компонентов и без файлов конфигурации форм dfm). С плагинами объем исходного кода на Delphi в проекте составляет 2858375 строк кода, что уже является весьма серьёзным числом.

Общая архитектура комплекса приведена на рисунке ниже.

Глава 2: Импортозамещение или заказчики захотели извращений

В общем жили мы жили, не тужили и баблос рубили спокойно делая программу под ОС Windows, и тут раз и вторая смена (с). Первые звонки с тем, что недурно бы поддержать и другие операционные системы начались не с отечественного заказчика как ни странно, а с немецкого института GRS для которого мы сделали систему проектирования моделей для их кода на нашей платформе. Немцы предложили нам BDSM – а хорошо бы нам для отчёта перед нашим посконным немецким начальством поддержать отечественную (ну в смысле исконно немецкую) операционную систему Suse Linux, а то непатриотично мол как-то, да и денег платить за неё заставляют. Прельстившись шуршанием не очень большого количества евровалюты, мы начали думать, как таки заставить программу на этом поделии светлого и благородного сумрачного немецко-финского гения. Первое что пришло при этом в голову – завести программу под Wine и таки действительно СТАРАЯ версия нашего софта под ним пошла, но только 32 битная и без Direct2D рендера, ну и соответственно без красивостей в виде прозрачностей и быстрых градиентов. Ну и кроме того, это было весьма скромно по производительности, особенно в многопоточном режиме. Возможно, после утечек исходного кода от майкрософта этот слой API в линуксе будет доведён до работающего состояния пригодного для полноценной работы нашего софта, но пока это не всегда так. Но захотелось иметь что-то чуть более приличное и по скорости и максимально реализующее функционал Windows-версии.

Java мы отмели сразу, ибо проблемы со стыковкой к ней библиотек на FORTRAN и откровенно отстойная скорость работы с более-менее сложными скриптами и графикой показались недостаточным аргументом для переписывания всего объёма кода на неё. Кроме того, она дико многословная по сравнению с Delphi да и нам нужен был именно нативный код, в первую очередь из-за необходимости стыковки с некоторым количеством стороннего расчётного софта (как немецкого так и нашего). Поэтому Java пошла в топку (на моей прошлой работе часть системы на ней всё-таки переписали, из опыта эксплуатации получилось очень сильно хуже исходной версии), наступать на старые грабли не очень хотелось. Туда же пошёл и C#, из-за плохой поддержки разработки на нём GUI именно в Linux и ненативного кода с проблемами стыковки со сторонними расчётными библиотеками.

Из вариантов сделать кроссплатформенный GUI остались 2:

1. Qt и C++ — это замечательный путь, но переписывание всего кода системы не впечатлило, кроме того под основную систему это на самом деле скорее всего означало было ухудшение отзывчивости и качества пользовательского интерфейса – VCL контролы использует родные системные всё таки. Далее встал вопрос наличия необходимой для формирования достаточно сложного пользовательского интерфейса базы компонентов, которые были перечислены выше. Посмотрев некоторые программы, выполненные при помощи Qt (qucs например как достаточно близкий по функциям) я осознал, что этот путь всё таки будет погибелен скорее всего.

2. Free Pascal + Lazarus. Самый большой плюс этой среды разработки и компилятора был в практически полной (но не совсем) переносимости текста исходной программы, что позволяло дословно сохранить логику работы. Но были большие сомнения в том, что те компоненты и особенности которые были в коде программы корректно переварятся этим компилятором.

Итак в силу ограничений в человеческих ресурсах было решено попробовать максимально использовать имеющуюся кодовую базу, оставив её на Delphi и дополнив код IFDEF-ами для сборки программы под другую ОС в среде разработке Lazarus. Немалую роль также сыграло то, что это позволяло не прерывать работу над основной версией SimInTech для Windows и параллельно вносить изменения сразу в 2 варианта сборки. Ибо срок работы был небольшой, а перенести надо было много и ещё так чтобы оно заработало.

Анализ встроенных в Lazarus штатно компонентов показал, что маловато будет, и было решено поискать что-то, в чём этого добра насыпано поболее, особенно в части отрисовки 2D-графики. Сначала был попробован рендер AggPas в штатном Lazarus-е, но он показался сильно медленным и не устраивающим по некоторым особенностям совместимости кода с Direct2D библиотекой. Поэтому было принято искать решение поинтереснее. Поиск по интернету вывел меня на нестандартную сборку Lazarus-а под названием CodeTyphon Studio и первые эксперименты с этой средой привели к выводу что вот это в принципе то, что позволит собирать программу на Linux с максимальным использованием существующего кода. Свою роль сыграло то что:

1 – там много компонентов по умолчанию, функционально и по использованию совместимых с теми, которые я использовал в Delphi-версии. То есть требовалась фактически минимальная переработка кода. Из всего что мне было нужно отсутствовали BCEditor (но был SynEdit, который у меня использовался в редакторе скриптов в более старой версии), DSPack (но были аналоги, и на самом деле наличие звука пока было не критично), TeeChart Pro (но штатно был аналог TAChart, а вот построение графиков как раз было очень критично).

2 – в наличии оказался неплохой компонент для рендеринга графики – ORCA 2D, структура которого была очень похожа на вызовы Direct2D и который был принципиально пригоден к использованию для отрисовки сложных изображений моделей и видеокадров.

Глава 3: Начинаем портировать

Первое с чего начался процесс портирования – это проверка размера катастрофы, т.к. среда разработки и компилятор, на который это всё должно было натянуться должен был позволять мне реализовать несколько базовых вещей, без которых программу пришлось бы крайне нехорошим образом менять:

1 – необходимо было иметь общий менеджер памяти для головного модуля и плагинов, выполненных в виде динамических shared object – библиотек.

2 – должна была быть возможность загрузки сторонних динамических библиотек на C и FORTRAN.

3 – было необходимо, чтобы некоторые формы находились в динамически загружаемых библиотеках, т.к. за счёт них выполнялось расширение интерфейса.

4 – должны быть аналоги большинства компонентов с идентичным или похожим пользовательским и программным интерфейсом.

5 – файлы форм dfm должны без лишних проблем конвертироваться (дальше как показала практика целесообразно иметь 2 раздельных набора файлов описания форм для Windows и Linux из за некоторой разницы в дизайне системных виджетов.

Самые большие сомнения на этот счёт были касательно пунктов 1 и 3, потому что используемая в Lazarus библиотека LCL хоть и является практически точным клоном VCL, но различается по ряду особенностей.

Первым делом была развернута виртуальная машина под VirtualBox с доступом к нашему репозиторию, где мы ведём разработку. В качестве операционной системы на тот момент была выбрана Open Suse, немножко позднее была сделана виртуальная машина на Alt Linux 8.3 и потом Alt Linux 9. Далее с сайта https://pilotlogic.com/ был выкачан архив с дистрибутивом среды разработки. Развертывание среды разработки было произведено по инструкции к ней – распаковать архив и выполнить su ./install.sh , но в процессе развертывания на Alt Linux встала проблема, что этой ОС в установочном скрипте в списке не было – пришлось добавить самому и написать письмо разработчику чтобы включил в код, сейчас эта разновидность линукса поддерживается. Если что не так – то в дистрибутиве можно дополнить файлик CodeTyphonIns\installbin\ScriptsLin\ln_All_Functions.sh вписав в него особенности установки.

Для Alt Linux туда была добавлен текст, рядом с тем местом, где определяется установка для Ubuntu:

В AstraLinux среда разработки ставится без лишних телодвижений на данный момент (с sudo). Бинарные файлы скомпилированные под AltLinux 9 запускаются и под Astra Linux Orel.

У Astra Linux на данный момент есть одна проблема, не связанная непосредственно с данной разработкой – штатно на нём стоит в настройках стабильный репозиторий в котором git версии 2.11, а для последнего SmartGIT-а нужно не ниже 2.16. Проблема решается путём переключения на экспериментальный репозиторий и обновления пакета git из него.

В итоге среда разработки была успешно установлена на тестовую виртуальную машину с Linux.

Дальше настала череда тестирования указанного выше базового функционала, который был необходим для успешной компиляции всего комплекса. Для начала было сделано минимальное приложение, загружающее DLL внутри которой создавалась форма и которое в свою очередь передавало в вызывающую программу строчку.

Анализ кода, поставляемого с компилятором Free Pascal, показал, что в составе RTL-библиотек имеется модуль cmem, который позволяет использовать менеджер памяти из libc. Он также как и для Delphi ставится первым модулем в dpr-файле и подключает внешний менеджер памяти (в Delphi для этого есть SimpleShareMem ну или fastmm4 \ fastmm5 ). На этом пункте можно было с уверенностью поставить галочку. Но при дальнейшем тестировании было выяснено что производительность этого менеджера памяти достаточно отстойная, поэтому поиски были продолжены и в результате был найден неплохой менеджер памяти fpcx64mm из пакета Synopse mORMot framework 2. Но он был не распределённый, поэтому для того, чтобы его использовать он был подключен через небольшой промежуточный модуль simmm.pas следующего содержания:

Как видно из данного кода ключ DCAD определяется только в головном модуле, при этом мы в нём определяем как экспортируемую функцию GetMemoryManager. А в dll\so мы получаем адрес этой функции путём вызова dlopen(nil, RTLD_LAZY) – если эта функция вызывается с нулевым первым аргументом, она возвращает хендл на главный исполняемый файл и дальше мы получаем оттуда адрес функции для получения центрального менеджера памяти и используем в плагинах его. Соответственно во всех плагинах первым модулем мы прописываем simmm для обеспечения общего выделения памяти.

Вторая проблема – это вызов форм, находящихся внутри dll\so модулей. В Delphi по факту эта проблем не возникала. Т.е. если мы делаем там TForm.Create, то форма создается нормально. В Lazarus на линуксе оказалось всё несколько интереснее, т.к. для того, чтобы форма создалась, необходимо в so-библиотеке прописать в списке модулей:

и определить инициализацию Application в секции initialization и завершение в finalization:

Выполнив такие операции, мы в дальнейшем можем спокойно создавать формы внутри so.

Наше приложение является многопоточным, поэтому сразу возник также вопрос с тем как это будет поддерживаться в Lazarus. В результате чтения документации и экспериментов было выяснено, что на UNIX-системах чтобы внутри программы или so создавать поток, в списке модулей проекта должен быть прописан модуль cthreads:

Таким образом все dpr-файлы были модифицированы типовым образом для того, чтобы в них заработал нужный нам функционал, в качестве примера привожу исходник dpr‑файла для плагина расчёта систем управления:

Таким образом 2 базовые для текущей архитектуры программного комплекса проблемы получили своё решение и на Linux. Дальше оставалось проанализировать насколько корректно будут передаваться в DLL строки и ссылки на объекты – с этим при подключении общего менеджера памяти всё оказалось в порядке. С загрузкой сишных и фотрановских .so также всё оказалось хорошо, но необходимо помнить, что intel fortran и gfortran по умолчанию по разному передают в функции аргументы, поэтому там где это было нужно, пришлось видоизменить декларацию вызова некоторых подпрограмм из сторонних DLL\SO. Как пример можно привести следующий фрагмент кода, подключающего процедуру на FORTRANе:

Вариант для Windows — INTEL FORTRAN, конвенция stdcall:

Вариант для Linux gfortran с конвенцией cdecl:

Из приведённого кода видно, что в Intel FORTRAN целочисленные параметры функции по умолчанию передаются в стек напрямую, а массивы и вещественные числа передаются через указатели, а в gfortran все параметры передаются через указатели. При этом по умолчанию конвенция вызовов в Intel FORRAN для Windows – stdcall, в gfortran, что для Windows что для Linux – cdecl.

Кроме этого также следует обратить внимание на именование экспортируемых функций при загрузке их из DLL: если в Intel Fortran для Windows имя экспортируемой функции остаётся неизменным и соответствует имени функции, то в gfortran добавляется суффикс _ :

<$IFDEF Windows>‘wwww’<$ELSE>‘wwww_’

Некоторые части программы были написаны на языке Си и подключены как динамически загружаемые библиотеки. Компиляция этих библиотек производилась компилятором gcc. Пример скрипта компиляции so-файла одной из них приведён ниже:

gcc -shared -fPIC -o ../../bin/libcommonclibs.so -s nn.c prime.c r_keygen.c rc4c.c rsa.c md5c.c -fpack-struct=1 -Wconversion

При компиляции модулей на Си следует обратить внимание на выравнивание структур, для того, чтобы таковое совпадало с кодом на Pascal.

Далее был предпринят анализ используемых компонентов и поиск их аналогов в CodeTyphon Studio, чтобы понять, насколько будет модифицироваться код программы. Ниже приведена таблица, показывающая что где есть.

Источник