MacOS ‘dll эквивалент
Итак, DLL похожа на папку, но она позволяет нескольким программам / исполняемым файлам получать к ней доступ одновременно, тем самым сохраняя память (я думаю).
Что является эквивалентом DLL для Mac? Я просматривал папки Google Chrome внутри
/Library/Application Support , и вместо обычного Windows Default.dll была просто папка «Default» в виде обычного файла, содержание которого, я полагаю, будет регулярно находиться внутри DLL.
Эквивалент Mac обеспечивает ту же функцию?
Эквивалентами Windows DLL на OS X являются Frameworks (Какао) или dylibs (BSD). Система поставляется в /usr/lib и /System/Library/Frameworks соответственно.
Папка, которую вы упоминаете, Library/Application Support похожа на Application Data (или AppRoaming сейчас?) Папки в Windows, содержащие личные настройки ваших приложений.
Хотя я не знаю, что такое эквивалент для Chrome default.dll на OS X, пакет приложений содержит следующее:
Судя по размеру, похоже, что Google Chrome Framework это важно (папка Frameworks чуть выше не представляет особого интереса)
В этом отношении нет реальных библиотек в OS X, Linux или POSIX. Они не делают различия.
С одной стороны, многие вещи Mac самодостаточны (в конце концов .app — это просто папки).
Двоичные файлы в Mac OS X (и Linux и других * Nixes) используют ELF (что означает «Исполняемый файл» и «Формат библиотеки») как для библиотек, так и для исполняемых файлов.
Файл по умолчанию, который вы там нашли, был, вероятно, двоичным файлом ELF.
Обновление : dmckee указывает, что .dylibs в формате Mach-O , эксклюзивно для Mac. Однако трудно различить их по виду, потому что ни один из них на самом деле не требует расширения.
Источник
Cmake — собираем переносимые приложения для Mac Os X и Windows
Рано или поздно наступает тот момент, когда приложения из наших лабораторий, полных чудес, вкусных библиотек и красивых фреймворков начинают проситься в большой мир, на компьютеры простых людей, не искушённых в магии. На их компьютерах не то, что не стоят наши новомодные фреймворки и средства разработки, там даже простого компилятора днём с огнем не сыщешь. Не может наше приложение жить без библиотек, которые так редко встречаются в дикой природе, зачахнет оно без них, никогда не видать ему белого света…
Но не всё так печально.
Обычно в таких случаях разработчики создают так называемые бандлы, которые содержат в себе все необходимые библиотеки и плагины для запуска приложения. Чаще всего их создают или при помощи скриптов или зависимых от IDE инструментов или вовсе руками.
Если вы никогда не вылезали за пределы Visual Studio, то вам для счастья особенно многого и не надо, все рецепты создания инсталляторов уже давно известны и обкатаны. Но если вы приверженец кроссплатформенного ПО, то тут начинаются сложности. Зачастую это все приводит к появлению небольшой рощицы из костылей для создания готовых к распространению бандлов без каких-либо намеков на универсальность. Но есть способы этого избежать.
Уже много лет самым популярным способом сборки для кроссплатформенных приложений является cmake, который имеет поддержку кучи платформ и компиляторов, умеет Qt, умеет создавать инсталляторы и dmg’шки и многое другое. Как раз о кроссплатформенном создании бандлов я и хочу рассказать. Для этого в cmake 2.8 появилась прекрасная утилита fixup_bundle
Описание утилиты
Утилита fixup_bundle опрашивает приложение и дополнительный список библиотек(чаще всего плагинов) на предмет наличия внешних зависимостей, после чего она ищет их в списке директорий, который мы заранее приготовили и копирует библиотеки и устанавливает значение RUNPATH, где это необходимо, чтобы приложение и плагины смогли ими воспользоваться. На заключительном этапе утилита проверяет получившийся бандл на наличие внешних зависимостей, если всё плохо, то она сообщает об ошибке.
Подготовка проекта
Проще всего работать с результатом выполнения команды make install. В этом случае, при правильном создании целей установки, получится хорошо структурированный каталог, на который уже будет легко натравливать fixup_bundle.
Ниже приведен мой вариант путей установки для различных типов целей.
if(WIN32)
set(BUNDLE_NAME $<_name>.exe)
set(BINDIR bin)
set(BUNDLE_PATH «$
set(LIBDIR lib$
set(SHAREDIR share)
set(PLUGINSDIR bin)
set(IMPORTSDIR $
set(RLIBDIR $
elseif(APPLE)
set(BUNDLE_NAME $<_name>.app)
set(BUNDLE_PATH «$
set(BINDIR $
set(LIBDIR $
set(RLIBDIR $
set(SHAREDIR $
set(PLUGINSDIR $
set(IMPORTSDIR $
else()
set(BUNDLE_NAME $<_name>)
set(BINDIR bin)
set(BUNDLE_PATH «$
set(LIBDIR lib$
set(RLIBDIR $
set(SHAREDIR share/apps/$<_name>)
set(PLUGINSDIR $
set(IMPORTSDIR $
endif()
Пример использования
install(TARGETS client
RUNTIME DESTINATION $
LIBRARY DESTINATION $
ARCHIVE DESTINATION $
BUNDLE DESTINATION .
)
Аналогичным образом нужно завернуть все устанавливаемые файлы и цели, дабы можно было менять пути для новых платформ простым образом. Это очень облегчает создание бандлов, инкапсулируя все особенности платформ.
Установка плагинов
Все зависимости для библиотек и бинарников будут найдены и прописаны автоматически, при условии, что они есть в путях поиска. Но раз нам удалось собрать приложение, то логично предположить, что все эти пути у нас на руках есть! Сложнее с плагинами и библиотеками, которые подгружаются динамически. Пока не запустишь программу никогда не будешь уверен, что же ей ещё нужно для корректной работы. К сожалению, это не самый лучший вариант. Но мы же разработчики приложения и знаем какие же плагины использует наше пока ещё не вышедшее в свет приложение, поэтому мы можем написать код для их поиска и добавления в цели установки примерно таким образом:
macro(DEPLOY_QT_PLUGIN _path)
get_filename_component(_dir $ <_path>PATH)
get_filename_component(name $ <_path>NAME_WE)
string(TOUPPER $
if($ <_type>STREQUAL «DEBUG»)
set(name «$
endif()
#message($
if(EXISTS $
message(STATUS «Deployng $ <_path>plugin»)
install(FILES $
else()
message(STATUS «Could not deploy $ <_path>plugin»)
endif()
endmacro()
После чего можно будет просто перечислить те Qt плагины, которые реально нужны. И по make install’у они окажутся все в нужном нам месте.
list(APPEND QT_PLUGINS
bearer/qgenericbearer
.
imageformats/qtiff
iconengines/qsvgicon
)
По хорошему, для распространения софта через менеджеры пакетов нужно, чтобы при обычной работе make install’а все внешние библиотеки не трогались, поэтому лучше всего включать режим сборки бандла отдельной опцией в конфигураторе.
option(CREATE_BUNDLE «Create application bundle then install» ON)
Запуск fixup_bundle
Из приведенного куска кода вполне очевидно, как работает fixup_bundle. В конечном итоге для получения бандла достаточно команды make install. А инсталляторы на основе cpack’а уже станут делом техники, но это тема отдельного разговора.
Ну и небольшой пример в виде индикатора прогресса для qml. В приложении используются QtComponents Desktop. Кому интересно, можете попробовать его запустить на Windows или Mac Os X Lion. 
Код примера на github’е, там же набор макросов для cmake’а, который делает создание бандлов крайне простым и удобным.
Источник
Question: Q: How to open .dll files?
I’m not sure I have the correct forum, but I thought I’d try here.
I have .dll files I want to look at. I am unable to open them in any type of readable format. When I double click on them they open in Text Edit and jumbled up. I tried to open them in Preview and that didn’t work either.
Can someone guide me on how to open these files? OR if this is the wrong board, let me know and I’ll post some place else.
iMac, MacBook Pro, Mac OS X (10.6.4), iPhone OS 4, iPad
Posted on Jul 29, 2010 11:42 AM
All replies
Loading page content
Page content loaded
Jul 29, 2010 11:55 AM
I think I’m over my head! Crumb, I was wondering if I found someone with a PC if they’d be able to open them?
On the cd it says «PC AutoPlay DICOM Viewer» then on the next line it says «Exit view before removing disk»
Does that help at all?
Thanks much-
Ginger
Jul 29, 2010 12:30 PM
Jul 29, 2010 1:04 PM
No. A Windows DLL file is a library of machine code meant to be loaded by a piece of software. It’s unreadable by humans. An experienced developer may be able to decompile the library into x86 assembly language.
DICOM is an image format used for storing medical image data (such as MRIs, CAT scans, etc.). Many packages that work with DICOM packages have an «export to CD» function that will burn a CD with a directory of DICOM images, optionally with a copy of a program for displaying the images. It sounds like you have one of those CDs that’s been burned with a copy of a Windows DICOM viewer. You won’t be able to use that without a copy of Windows installed.
Источник
How to use a Windows DLL with Java in Mac OS X?
I have seen some Java projects using taucs.dll , TAUCS—a C library of sparse linear solvers, through JNI in Windows. I guess I can achieve the same in Mac OS X by compiling TAUCS into something like libTaucs.jnilib . I have access to the library’s code but no idea how to compile it into a DLL, let alone a JNI library. So far I can compile only to a static library.
Is there a way to convert a DLL to a JNI library for Mac? If I have to compile the code, how to do so? Will wrapping a static library in a dynamic library work with JNI, especially for TAUCS if anyone has an experience?
2 Answers 2
Finally Microsoft released .NET Core which is completely platform independent. When you build a DLL using .NET Core framework you can run the file with following command.
Also, now .NET applications can be developed on Mac or Linux machine using the lightweight IDE Visual Studio Code and Visual Studio for Mac IDE has been released where Mono on MacOS X is integrated.
Many operating systems have the concept of shared libraries, but ofcourse the format etc. of such libraries is different on different operating systems.
DLLs (Dynamically Linked Libraries) are the Windows version of shared libraries. You cannot just use a DLL from a Windows machine on Mac OS, exactly like you cannot run a Windows application on Mac OS (or any other operating system).
Instead of trying to use a Windows DLL on Mac OS, you need to find a Mac OS-specific version of the native library that you are trying to use. Or if you have the source code, compile it into a Mac OS-native shared library. Shared libraries on Mac OS X have the extension .so (instead of .dll), which stands for «shared object».
Loading them using just Java is not possible.
Источник
Эквивалент DLL от MacOS
Поэтому DLL похожа на папку, но позволяет нескольким программам / исполняемым файлам получить к ней доступ сразу, тем самым сохраняя память (я думаю).
Что такое эквивалент Mac для DLL? Я просматривал папки Google Chrome внутри
/Library/Application Support , а вместо обычного Windows Default.dll была только папка «Default» в качестве обычного файла, содержимое которой, я полагаю, будет регулярно находиться внутри DLL.
Соответствует ли эквивалент Mac той же функции?
Эквивалентами для Windows DLL в OS X являются Frameworks (Cocoa) или dylibs (BSD). Система поставляется в /usr/lib и /System/Library/Frameworks соответственно.
Папка, о которой вы упоминаете, Library/Application Support аналогична папкам Application Data (или AppRoaming now?) В Windows, содержащим личные настройки ваших приложений.
Хотя я не знаю, что эквивалентно для Chrome’s default.dll на OS X, пакет приложений содержит следующее:
Предполагая, что размер файла Google Chrome Framework очень важен (папка Frameworks чуть выше не содержит большого интереса)
В ОС X, Linux или любой POSIX нет реальных библиотек DLL. Они не делают дифференциации.
Многие вещи для Mac, например, являются автономными (в любом случае, они действительно являются папками).
Бинарные файлы в Mac OS X (и Linux и другие * Nixes) используют ELF (который обозначает исполняемый и библиотечный формат) для библиотек и исполняемых файлов.
Файл по умолчанию, который вы нашли в нем, вероятно, был двоичным.
Обновление : dmckee указывает, что .dylibs находятся в формате Mach-O , исключительно для Mac. Тем не менее, трудно отличить их от взгляда, потому что ни один из них не требует какого-либо расширения.
Ближайшие эквиваленты linux и Mac называются «общими объектными файлами» (обычно с расширением .so) и динамическими библиотеками (как правило, с расширением .dylib) соответственно.
Общие объекты широко используются в типичных Linux-системах, динамические библиотеки не так повсеместны, потому что формат .app позволяет очень безопасный механизм распространения для поддержки нескольких архитектур за счет более крупных «файлов» exectuatble.
Источник
