Удивительное рядом (о совместимости 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

"а про то мы не знаем // и не жаждем узнать" (c)

на самом деле, очень понимаю, и как и что выбирать нонеча для кросс-компиляции в не самых прямолинейных случаях -- вот аааще непонятно, ОБА ХУЖЕ!!!

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 компиляторов...)?

Add new comment