Как запустить приложение (*.exe) без установки Run-Time

[toshas]

Похоже рано радовался.

При попытке создать приложение без GUI (для запуска на Ubuntu Server) по инструкции
https://knowledge.ni.com/KnowledgeArtic ... 0019RYlSAM
Running a LabVIEW Application on Linux Without a Graphical User Interface
Приложение работает через другой lvrt - lvrtdark.

Сначала были проблемы с отсутствием liblvrtdark.so.14.0
Программа не видит его рядом с собой, пришлось сделать ссылку.
Потом докинул рядом libniCPULib.so
А вот что делать этим непонятно:

Error Message =Internal Warning 0x08B1734C : "lvinit.cpp", line 2149
LabVIEW version 14.0
For assistance in resolving this problem, please contact National Instruments Support.


user@ubuntu:~/Desktop/My Shared Library$ ./TEST
./TEST: error while loading shared libraries: liblvrtdark.so.14.0: cannot open shared object file: No such file or directory
user@ubuntu:~/Desktop/My Shared Library$ sudo ln -s /home/user/Desktop/My\ Shared\ Library/liblvrtdark.so.14.0.0 /usr/lib/liblvrtdark.so.14.0
user@ubuntu:~/Desktop/My Shared Library$ ./TEST
Unable to load libniCPULib.so from /home/user/Desktop/My Shared Library/libniCPULib.soAborted (core dumped)
user@ubuntu:~/Desktop/My Shared Library$ ./TEST
Error Message =Internal Warning 0x08B1734C : "lvinit.cpp", line 2149
LabVIEW version 14.0
For assistance in resolving this problem, please contact National Instruments Support.
Aborted (core dumped)
user@ubuntu:~/Desktop/My Shared Library$

[dadreamer]

Толком, к сожалению, нет времени посмотреть, в чём беда, т.к. Linux у меня только дома на виртуалке. Кстати, я даже не в курсе был, что такое возможно. Век живи, век учись, дураком помрёшь.
Сегодня успел только скомпилить согласно мануалу. Надо сносить LVRT, чтобы протестировать, или делать новый снапшот системы. Может быть, этот тред поможет: https://unix.stackexchange.com/question ... s-when-run
ldd показывает стандартные либы, но через /proc/<pid>/maps уже поинтереснее:
/lib/x86_64-linux-gnu/ld-2.30.so
/lib/x86_64-linux-gnu/libc-2.30.so
/lib/x86_64-linux-gnu/libdl-2.30.so
/lib/x86_64-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libm-2.30.so
/lib/x86_64-linux-gnu/libnsl-2.30.so
/lib/x86_64-linux-gnu/libnss_compat-2.30.so
/lib/x86_64-linux-gnu/libnss_files-2.30.so
/lib/x86_64-linux-gnu/libnss_nis-2.30.so
/lib/x86_64-linux-gnu/libpthread-2.30.so
/lib/x86_64-linux-gnu/librt-2.30.so
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
/usr/local/lib64/LabVIEW-2018-64/liblkdynam.so.5.10.0
/usr/local/lib64/LabVIEW-2018-64/liblksec.so.5.10.0
/usr/local/lib64/LabVIEW-2018-64/liblksock.so.5.10.0
/usr/local/lib64/LabVIEW-2018-64/liblvrtdark.so.18.0.0
/usr/local/lib64/LabVIEW-2018-64/libniCPULib.so.18.0.0
/usr/local/lib64/LabVIEW-2018-64/libNILVRuntimeManager.so.18.0.0
Попробуйте положить рядом с программой указанные библиотеки , для LV 2014 имена будут несколько отличаться.

[ujin]

user@ubuntu:

Согласно описанию Labview Linux встает только на ветку Red Hat. Из бесплатного это Centos (пробовал на 7).
По ссылке не указаны некоторые важные вещи. Например что нужно заголовочные файлы из cintools добавить в проект. Так же какой-то из заголовков у меня был поломаный. В NetBeans нашел и исправил.
Cintools на машину без иксов не ставится. Надо на develop машине искать.
Вы рекомендованный путь в виде ./INSTALL и рекомендованный линукс пробовали? Около 110 МБ полный runtime устанавливается.
Минимальный размер NAND FLASH на пром компьютерах с процессором Vortex86DX - 8 Гб (там проц 586. Встает только Centos 5 и Labview 10). Остальные больше.
Консольный Centos 7 около 600 МБ.
Получите личное удовлетворение от проделанной работы и не более.

[toshas]

Получилось победить.
В итоге рядом с программой надо положить:
liblvrtdark.so.14.0
libniCPULib.so
tdtable.tdr
rtapp.rsc

Как раз отсутствие последнего приводило к ошибке
Error Message =Internal Warning 0x08B1734C : "lvinit.cpp", line 2149
LabVIEW version 14.0
For assistance in resolving this problem, please contact National Instruments Support.

Неясно только почему программа по умолчанию лезет в /usr/lib и не видит что вокруг.
приходится создавать символическую ссылку на liblvrtdark.so.14.0 указывающую на него в папке программы.
Остальные файлы программа подтягивает уже по пути где нашелся liblvrtdark.so.14.0

И еще непонятно если бы на машине использовались и x32 и x64 программы, то как с поступать в этом случае, ссылка то общая будет

[toshas]

Например что нужно заголовочные файлы из cintools добавить в проект.

Этого действительно в описании они не привели, похоже забыли.
Решается галкой "Include additional LabVIEW header files" в advanced настройках build specifications

Вообще эту инструкцию сделали в 2018, хотя на форуме NI способ известен с 2007 оказывается!
https://forums.ni.com/t5/LabVIEW/Runnin ... d-p/592242

Кстати существует еще вариант с виртуальным дисплеем на базе Xvnc
https://forums.ni.com/t5/LabVIEW/headle ... d-p/109696

[ujin]

Решается галкой "Include additional LabVIEW header files" в advanced настройках build specifications

Спасибо. Так должно быть проще.
Еще с обработкой ошибок были вопросы. Если звук используется так же нужно добавлять библиотеки.
У меня не заработала VISA. Как выяснил на форумах работает только в определенной версии ядра в определенной сборке.
При обновлении ядра работать перестает.
Нужно большое приложение пробовать. Оно еще библиотеки потянет.

[dadreamer]

Дошли наконец руки проверить этот "тёмный" RTE. Ubuntu 19.10 чистая, только "из коробки". Бинарник, скомпиленный в 2018 64-bit, попросил следующие файлы:
liblvrtdark.so.18.0
libniCPULib.so
libNILVRuntimeManager.so
rtapp.rsc
tdtable.tdr
Никаких символических ссылок я, естественно, не создавал. Просто положил запрашиваемые файлы рядом с приложением, переименовав их так, как просили (при запуске в терминале выводится инфа о том, какой библиотеки не хватает с указанием её имени). Если более подробно расписывать, то:
- Взял liblvrtdark.so.18.0.0 из \usr\local\natinst\LabVIEW-2018-64\AppLibs, положил в папку с приложением, переименовал в liblvrtdark.so.18.0;
- Взял libniCPULib.so.18.0.0 из \usr\local\natinst\LabVIEW-2018-64\resource, положил в папку с приложением, переименовал в libniCPULib.so;
- Взял libNILVRuntimeManager.so.18.0.0 из \usr\local\natinst\LabVIEW-2018-64\AppLibs, положил в папку с приложением, переименовал в libNILVRuntimeManager.so;
- Взял rtapp.rsc из \usr\local\natinst\LabVIEW-2018-64\AppLibs, положил в папку с приложением;
- Взял tdtable.tdr из \usr\local\natinst\LabVIEW-2018-64\resource, положил в папку с приложением.

>> И еще непонятно если бы на машине использовались и x32 и x64 программы, то как с поступать в этом случае, ссылка то общая будет
Если не создавать ссылку, то не должно быть никаких проблем: библиотеки нужной разрядности кладёте рядом с программой и всё будет работать.

>> Решается галкой "Include additional LabVIEW header files" в advanced настройках build specifications
Я даже эту галку не ставил. В хэдере SharedLib.h поправил путь к cintools:
#include "/usr/local/natinst/LabVIEW-2018-64/cintools/extcode.h"
Всё закомпилировалось.
Если я правильно понял, результирующий бинарник играет роль враппера исходной либы, более он ничего не делает. Аналогичный starter можно в любой среде написать, даже не обязательно акцентироваться на gcc. Вероятно, линковка к liblvrtdark.so даже не является обязательной, скорее рекомендуемой (не проверял пока). Если прилинковать к обычному LVRTE, то получим зависимость от иксов (X11), однако при обращении к скомпиленным в DLL'кам никакие окна и так не появляются. Скорее, здесь вопрос надо ставить так: будут ли иксы на целевой платформе или нет.

If it is the second, then it will depend upon if you have the X11 environment running on the target. LabVIEW built applications and DLLs (SOs) use the LabVIEW Run-Time Engine (RTE). The RTE requires the X11 libraries to be loaded to run. LabVIEW for Linux also has something called the "Dark RTE." The RTE has many of the features of the regular RTE, but there is no GUI and no need for X11 libraries. However, many property nodes that use features of the front panels will not work because the front panels will not be around in memory in the Dark RTE. To build something against the Dark RTE, you will need to build your application as a LabVIEW Built DLL and then write a small C wrapper file that calls into this DLL. You could then run a LabVIEW application as a command line program without the need for X11.
( https://forums.ni.com/t5/Linux-Users/ru ... 4429#M1832 )

>> У меня не заработала VISA. Как выяснил на форумах работает только в определенной версии ядра в определенной сборке.
Если работать только с Serial девайсами, то есть альтернативы для Linux, они также потянут одну или несколько библиотек, но проще в установке.
serpdrv - старая обёртка для работы с последовательным протоколом (только для 32-bit): http://labviewportal.org/viewtopic.php?p=65851#p65851
libserialport из sigrok - более современная библиотека под 32/64 бита: http://labviewportal.org/viewtopic.php?p=82147#p82147

[dadreamer]

На Маке пока не пробовал, если будет время, постараюсь проверить.

Об этом я не забыл. Почти сразу же я проверил, но сколько ни пытался, не заработало. Спустя N месяцев (или лет?) попробовал снова и опять не получилось. Сейчас, когда появилось свободное время, решил добить эту затею до конца. Прикол в том, что на Маке, в отличие от Винды и Линукса, приложение представляет из себя Bundle, т.е. папку с определённой структурой, куда помещается бинарник и связанные с ним файлы (картинки, аудио и прочее). Система видит Bundle как самостоятельное приложение, запускает по дабл-клику и вообще это вроде как один файл, если его глубоко не копать. Бесполезно ложить рядом ран-тайм, который кстати представляет из себя набор фреймворков (папок с разделяемыми библиотеками). Интересно также работает загрузчик на macOS. Если на Windows он рыскает по путям из PATH и подбирает попавшиеся либы, то тут он сразу ломится по жёстко заданным адресам, и если там ничего нет, то программа не запускается. Сам RTE грузится бинарником динамически, но пути все абсолютные (/Library/Frameworks и /System/Library/Frameworks). Дошёл до патча исполняемого файла и даже получил частичный успех. Но позднее нашёл вот такой чудесный скрипт: Standalone LabVIEW-built Mac Application with Post-Build Action. Здесь есть описание его работы. Соль в том, чтобы положить основной фреймворк RTE (т.е., LabVIEW XX.X Runtime.framework) в папку Support внутри Bundle, тогда он подтягивается автоматом. Кроме прочего, скрипт выкидывает лишние по его мнению фреймворки из RTE, так что финальная программа становится легче. Пример: LabVIEW 19.0 Runtime.framework весит больше 160 МБ, после обработки скриптом приложение заняло около 50 МБ. При желании можно ещё вручную поудалять ненужное. Список удаляемых фреймворков захардкоден на БД , можно легко его отредактировать. Скорее всего, для более сложных приложений эти фокусы не сработают, т.к. будет больше разнообразных зависимостей. Хотя это справедливо для любой системы. Короче говоря, на 2019 описанный метод нормально отработал, а результирующее приложение запустилось без инсталляции RTE.

[IvanLis]

temp

[dadreamer]

Оказывается, с помощью тулкита LabVIEW C Generator 2017 можно компилить стандартные виндовые DLL'ки без привязки к ран-тайму. Другими словами, из можно получить библиотеку, для которой не надо потом будет ставить LV RTE. Далеко не все функции поддерживаются, но обычно внутрь DLL помещают математику или работу с железом, так что остальное по большей части не нужно (File I/O и Instrument I/O не были бы лишними). Сам тулкит уже считается устаревшим и похоже, что новых версий уже не будет. Однако это не помешает его иногда заюзать для простых библиотек. 2017-я версия официально ставится только на 2017 32 бита, однако применив некоторые танцы с бубнами, можно поставить её на LV 2018 и 2019. Модуль обязательно надо лицензировать, хотя бы триалом, иначе ничего не заработает. Далее, надо иметь на компе Microsoft Visual Studio (для компиляции С-шных исходников) и GNU Make утилиту (для сборки библиотеки). Новые версии make работают как-то странно, поэтому я использовал GNU Make 3.82.90 (там есть и 64-битная тоже). Также в MSVS надо активировать "X64 Compilers and Tools", если требуется компилить 64-битные библиотеки и x64-компилятор изначально отсутствует.

Когда C Generator установлен и лицензирован, необходимо скомпилировать либу lv_analysis.lib (библиотека мат. анализа), которая далее будет включаться в исходник. Идём в папку [LabVIEW]\CCodeGen\analysis, кладём туда make, запускаем Visual Studio Command Prompt (32- или 64-разрядную, по ситуации), переходим в тот же каталог и вводим "make". Готовая либа будет помещена в каталог [LabVIEW]\CCodeGen\lib\win. Теперь можно приступать к созданию простенькой -ки.

1. Создадим вот такой прибор, вычисляющий среднее арифметическое, СКО и дисперсию:

Терминалы на иконке я также подключил, они будут определять параметры генерируемой функции.

2. Здесь же создаём новый пустой проект и включаем в него наш .
Нажимаем ПКМ на Build Specifications -> New -> C Code Generation (*.c, *.h):

предложит сохранить проект - сохраняем.

3. В появившемся окне на вкладке Information выбираем папку, куда будут сохраняться C-исходники (Destination directory), на вкладке Source Files переносим из проекта в экспортируемые (стрелка ->), настраиваем прототип функции. Как видим, добавил в прототип ещё один параметр - длину массива.

В общем-то ничего менять не требуется, оставляем как есть.

4. На остальных вкладках можно также оставить всё по умолчанию и нажать ОК. В Build Specs добавляется файл генерации VI->C.

5. Можно для уверенности проверить синтаксис конвертируемого . Для этого нажимаем ПКМ на файле генерации -> Check Syntax. Обычно здесь всегда всё в норме.

6. Жмём ПКМ на файле генерации -> Build. Выполняется конвертация C кода из и в папку Destination directory помещаются исходники *.c, *.h и make-файлы.

7. Заходим в папку с исходниками. Если нужна 64-битная DLL'ка, открываем Makefile и исправляем строчку

LINKFLAGS = /nologo /dll /machine:I386

на

LINKFLAGS = /nologo /dll /machine:X64

Сохраняем, закрываем. Кладём в папку make.exe, запускаем Visual Studio Command Prompt (32- или 64-разрядную, по ситуации), переходим в тот же каталог и вводим "make". Компилируются объектные файлы *.obj, собирается библиотека.

8. DLL-ка готова! Можно подключать её в какой-либо другой среде. Проверим для простоты её в :

Всё работает.
Итоговая библиотека не зависит от RTE:

Отмечу, что в составе C Generator есть узел Inline C Node, с помощью которого можно прописывать код на C прямо на диаграмме. Интересно, что C Generator компилирует также и этот узел, встраивая пользовательский C код в итоговые исходники. Конечно, нет большого смысла набирать код на C на БД, чтобы потом получить С-шные исходники с этим же кодом. Проще сразу вписать код внутрь *.c или *.h (если, конечно, знаете, куда его вписывать). Однако такая возможность в есть и она работает (или работала, пока в LV2020 не сломали).