Удивительное рядом (о совместимости ABI компиляторов)
Волею судеб тут пришлось делать следующие упражнения:
- Собрать некую библиотеку (C++) с помощью Visual Studio 2013 тулсетом для XP (Platform toolset: v120_xp) и использовать ее потом из Visual Studio 2010.
- Собрать некую библиотеку (C++) с помощью Clang (clang-cl, версия 4.0.1) и использовать (вызывать) ее потом из кода, собираемого Visual Studio (в данном случае 2015, но думаю проделать то же с 2010 и 2013). А из clang-собранной библиотеки зовется еще одна, собранная 2015-й студией.
Причина была одна и та же, первая "некая библиотека" не собирается 2010й студией, ибо используемый C++ новее, аналогично и со второй (сходу только Clang/gcc, под MSVC надо править, но очень уж не хотелось).
На удивление, оба варианта проканали вообще без каких-то проблем (я опасался, что придется тянуть всякие чужие C/C++ рантаймы, но нет). Про Clang известно, что над совместимостью по name mangling и подобному там все еще ведутся улучшения, но базовые вещи работают уже.
Еще более на удивление, с clang-cl работают базовые вещи у отладчика VisualStudio (небазовые не пробовал).
Итого: вот просто берешь и используешь (в случае Clang - запускаешь еще батник для интеграции с VS).
Вот что не работает с раздачи, так это cmake, которому указано что используется clang-овский toolset. Оно каким-то чудом узнает, что вот работает clang (хоть и -cl) и пытается совать туда clang-овские же свитчи командной строки, а clang-cl их не понимает. Надо править бы, но я этот ad-hoc язык не знаю и очень не хочу узнавать.
Comments
cmake сотоваришчи
"а про то мы не знаем // и не жаждем узнать" (c)
на самом деле, очень понимаю, и как и что выбирать нонеча для кросс-компиляции в не самых прямолинейных случаях -- вот аааще непонятно, ОБА ХУЖЕ!!!
autoconf, пожалуй, еще похуже
autoconf, пожалуй, еще похуже будет.
Я использую qmake как мета-описатель процесса сборки, но
а) тоже не подарок
б) это никоим образом не замена cmake/autoconf, автоконфигурации там вовсе нет (но мне и не надо, наоборот!)
А интерфейс у библиотек при
А интерфейс у библиотек при этом - C++ с использованием STL, или чистый C? Во втором случае - чего бы ему не работать? А вот в первом - вроде бы не должно быть совместимости.
Плюсовый интерфейс. Включая
Плюсовый интерфейс. Включая std::*stream, то есть в ваших терминах "STL"
Но и с чисто сишным
Но и с чисто сишным интерфейсом снаружи (но ++ внутри) вот я бы боялся, что clang-овский тулсет захочет clang-овского же рантайма для всех этих std:: (и аналогично v120_xp не совместим в этом месте v100)
Рантайм определяется списком
Рантайм определяется списком библиотек, с которыми мы линкуемся (а они, в свою очередь, определяются ключами командной строки, использованными при компиляции: /MT или /MD). Если линковаться с msvcrt.lib/msvcprt.lib, то результат потребует того рантайма, который прописан в этих библиотеках. Если линковаться с libcmt.lib/libcpmt.lib, то рантайм вообще не потребуется. В обоих случаях успешность линковки и работоспособность результата не гарантированы, особенно если используется C++ (см. https://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_libsdlls_be_li...). Да, в MSVC2015 названия библиотек изменились, а 2017 вроде бы совместим по ABI с 2015.
Что касается clang'а - см. https://clang.llvm.org/docs/MSVCCompatibility.html: "First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code should be able to link against MSVC-compiled code successfully. However, ...".
Вот по первой ссылке пишут:
Вот по первой ссылке пишут: We added linker checks, so that mismatching VS 2010+ major versions will trigger hard errors at link time,
Вот что я могу сказать: v120_xp + v100 (смешаны именно "библиотеки", т.е. .obj) - полет нормальный.
Недавно делал такой костыль
Недавно делал такой костыль через memory-mapped файлы, что решает подобные проблемы полностью ))
Я, честно говоря, не понял.
Я, честно говоря, не понял.
Какие проблемы можно решить через mmap (пост, вообще-то, про ABI компиляторов...)?