2012-05-23 2 views
1

Я хочу скомпилировать libmono как статическую библиотеку в Windows.Compilling mono as static library

Целевая платформа - это Windows x86. Среда сборки: Windows 7 64-бит, VC++ Express 2010

Что я уже сделал.

1) Скачан mono 2.10.8 sources.
2) Открыт файл mono.sln из папки msvc и гарантирует, что все выполняется.
3) Тогда я сделал некоторые изменения:
3,1) Общие-> Project Defaults-> Тип конфигурации: статическая библиотека (.lib)
3,2) Общие-> Проект Defaults-> Использование MFC: Использование стандартных окон Библиотеки
3,3) C/C++ -> Code Generation-> Runtime Library: Многопоточная (/ MT)
4) Встраиваемая это и VC++ 2010 успешно создали моно-2.0.lib
5) Добавлен его в компоновщик входы мой собственный проект (который я хочу встроить в моно) с:
5.1) General-> Project Defaults-> Тип конфигурации: Приложение (.exe)
5.2) General-> Project Defaults-> Использование MFC: используйте M FC в Ststic Library
5.3) C/C++ -> Code Generation-> Runtime Library: Многопоточная (/ MT)

Это, кажется, работает почти идеально, но с некоторыми страшными вопросами: Mysterious behavior of Dictionary<TKey, TSource>

ли все сделано правильно? Должен ли я указывать любые другие параметры компилятора или директивы препроцессора?

PS: libmono командной строки:

/I"..\libgc\include "/ I" .. \ "/ I" .. \ моно \ "/ I" .. \ mono \ jit " /I"..\mono\eglib\src" /I"....\mono\eglib\src "/I"..\eglib\src"/Zi /nologo/W1/WX-/О1/OB1/OI/Oy-/Д "NDEBUG"/D "i386"/D "TARGET_X86"/D "i386"/D "WIN32"/D "_WIN32"/D "WIN32 "/ D " _WINDOWS "/ D" WINDOWS "/ D" HOST_WIN32 "/ D" TARGET_WIN32 "/ D " _CRT_SECURE_NO_DE PRECATE "/ D" GC_NOT_DLL "/ D" HAVE_CONFIG_H "/ ​​D " WINVER = 0x0500 "/ D" _WIN32_WINNT = 0x0500 "/ D" _WIN32_IE = 0x0501 "/ D " WIN32_THREADS "/ D" FD_SETSIZE = 1024 "/ D" default_codegen "/ D "MONO_ASSEMBLIES = 0"/ D "_UNICODE"/ D "UNICODE"/ GF/GM-/EHsc/MT/GS /Гр/FP: точная/Zc: wchar_t/Zc: forScope/Рр ". \ Release/libmono.pch" /Fa "Win32 \ obj \ libmono \"/Fo "Win32 \ obj \ libmono \" /Fd"Win32\obj\libmono\vc100.pdb "/ Gd/TC/анализ -/errorReport: очереди

UPD:

Я нашел это обсуждение, которое связано с моим вопросом http://mono.1490590.n4.nabble.com/Mono-static-library-td3546774.html

Действительно ли это актуально? Могу ли я использовать SGen вместо Boehm? Если да, любой совет очень ценится. И если да, могу ли я использовать моно как статическую библиотеку с использованием sgen?

+1

Это странный вопрос, принимая во внимание что ваш предыдущий вопрос показал, как вы застрелили вашу ногу, запустив моно-статически связанную. http://stackoverflow.com/questions/10717406/mysterious-behavior-of-dictionarytkey-tsource –

ответ

2

Все теперь ясно для меня.

Hans Passant дал ответ Mysterious behavior of Dictionary<TKey, TSource>, который показывает, что статическое соединение не будет работать.

Ответ на этот вопрос показывает, что нет возможности выбрать другой GC еще: Compiling Mono from Visual Studio with sgen support

Подводя итог, он понял, что Nowdays единственное решение, на окнах динамического связывания

+0

Странно. Я бы сделал это как не-ответ. Но, поскольку OP вы «как-то», имеете право согнуть правила и изменить свой собственный вопрос. Хорошо, тогда. – sehe

+0

Это ваше право, но я думаю, что он отвечает на все вопросы. 1) вечное, что было сделано правильно; 2) Я не должен добавлять никаких других флагов, поскольку все правильно; 3) Ситуация, в которой Бем использует DllMain, по-прежнему актуальна; 4) Я не могу использовать SGen вместо Boehm на Windows.На каждый вопрос отвечает, и ответы здесь содержатся. Разумеется, в моем оппионе. – ILya

+0

Ну, кроме, может быть, что заголовок вопроса «Компиляция моно как статическая библиотека». Я смиренно предлагаю, что «единственное решение для Windows - динамическое связывание» не может считаться реальным ответом. В любом случае, не нужно защищаться, [я защищал вас в своем первом комментарии] (http://stackoverflow.com/questions/10719828/compilling-mono-as-static-library/10721707#comment13931419_10721707) :) – sehe

3

Я собираюсь пропустить детали вашего вопроса, потому что подозреваю XY problem.

Если вы хотите создать приложение, которое статически связан с моно выполнения, просто использовать mkbundle.exe:

mcs Main.cs 
mkbundle --static --deps -z Main.exe -o Main 
ldd Main 

приводит

[email protected]:~/Projects/SODemo/SODemo$ mkbundle --static --deps -z Main.exe -o Main 
OS is: Linux 
Note that statically linking the LGPL Mono runtime has more licensing restrictions than dynamically linking. 
See http://www.mono-project.com/Licensing for details on licensing. 
Sources: 1 Auto-dependencies: True 
    embedding: /home/sehe/Projects/SODemo/SODemo/Main.exe 
    compression ratio: 44,62% 
    embedding: /usr/lib/mono/4.0/mscorlib.dll 
    compression ratio: 34,99% 
    embedding: /usr/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll 
    compression ratio: 37,49% 
    embedding: /usr/lib/mono/gac/Mono.Security/4.0.0.0__0738eb9f132ed756/Mono.Security.dll 
    compression ratio: 40,12% 
    embedding: /usr/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll 
    compression ratio: 40,12% 
    embedding: /usr/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll 
    compression ratio: 34,06% 
    embedding: /usr/lib/mono/gac/System.Security/4.0.0.0__b03f5f7f11d50a3a/System.Security.dll 
    compression ratio: 39,32% 
    embedding: /usr/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll 
    compression ratio: 34,16% 
    embedding: /usr/lib/mono/gac/Mono.Posix/4.0.0.0__0738eb9f132ed756/Mono.Posix.dll 
    compression ratio: 40,01% 
Compiling: 
as -o temp.o temp.s 
cc -o Main -Wall `pkg-config --cflags mono-2` temp.c -lz `pkg-config --libs-only-L mono-2` -Wl,-Bstatic -lmono-2.0 -Wl,-Bdynamic `pkg-config --libs-only-l mono-2 | sed -e "s/\-lmono-2.0 //"` temp.o 
Done 
[email protected]:~/Projects/SODemo/SODemo$ ldd Main 
    linux-vdso.so.1 => (0x00007fff7b1ff000) 
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ffe95d0f000) 
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffe95a8b000) 
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffe95882000) 
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffe9567e000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffe95461000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffe950bf000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007ffe95f52000) 

Примечание полученный исполняемый файл размером: 5,8 Мб для тривиальной программы. Но это является полностью независимым.

Смотрите также

+0

Благодарим вас за эту экскурсию в пучки, но она полностью отличается от того, что мне нужно, и того, что в моем вопросе. Почему вы называете это проблемой XY? Я сделал попытку. Это не сработало для меня. Поэтому я попросил исправления, описывающие предпринятые шаги. Мне не нужно связывать управляемые сборки в моем исполняемом файле. Мне нужно статическое соединение с libmono. Я согласен изменить свой вопрос, если это неясно, но теперь я этого не вижу. – ILya

+0

@ILya ваш вопрос ясно. Цель - нет. Обратите внимание, что полученный исполняемый файл ** ** статически связан с libmono. Обратите также внимание на то, что вы можете повторить упражнение ** без ** '--deps', чтобы скомпилировать одну сборку до собственной библиотеки вместо полного exe. Это помогает? – sehe

+0

Мне не нужно компилировать какую-либо сборку =) Позволяет сказать, что я хочу mono.exe, но выигрываю дополнительные функции и без отдельного файла mono-2.0.dll, то есть однофайлового исполняемого файла, который я могу использовать способом «C: \ myapp \ mymono .exe D: \ dot-net-assembly.exe ". И у меня уже есть тот, который работает, кроме классов словаря <,>, используемых в dot-net-assembly.exe случайным образом перебрасывает странные исключения. Это вызвано проблемами ГК. Если вам интересно, посмотрите на мой собственный ответ. – ILya

Смежные вопросы