Позвольте мне объяснить сценарий. У нас есть устаревшая библиотека C ++ .so. Функции в этой библиотеке объявлены с extern "c" {}, поэтому библиотека может использоваться как программой на C, так и C ++, плюс, по некоторым причинам, она была создана с опцией --static-libgcc.
Эта старая библиотека очень старая и ее сложно поддерживать. Теперь нам удалось написать его замену, но на языке Си. Допустим, старая библиотека называется libfoo.so (старая), а новая - libfoo.so (новая). Для данного bar.o его можно связать со старым или новым libfoo.so, чтобы создать исполняемый файл, скажем, bar.exe. Но bar.exe может работать только с той же библиотекой .so, с которой он связан, другими словами, эти две библиотеки не взаимозаменяемы.
РЕДАКТИРОВАТЬ # 1 : я сделал символическую ссылку с именем libfoo.so, чтобы указать на libfoo.so (старый) или libfoo.so (новый). Эта символическая ссылка libfoo.so находится в LD_LIBRARY_PATH во время выполнения.
РЕДАКТИРОВАТЬ # 2 : Когда я связал bar.o со старым libfoo.so и сгенерировал bar.exe, если я запустил этот bar.exe с новым libfoo.so, он сообщил об ошибке undefined symbols , По nm этим двум libfoo.so я могу найти эти символы в старом, но не в новом. Символы похожи на _ZSt4cerr, которое является искаженным именем в C ++ lib (хотя оно и было введено --static-libgcc), и, конечно, новый libfoo.so не содержит таких символов.
РЕДАКТИРОВАТЬ # 3 : Если я просто скомпилирую и свяжу код C с g ++ вместо gcc, имеет ли смысл?
Как мне это реализовать?
EDIT # 4 : Сегодня мне удалось скомпилировать / связать новый запрограммированный на C libfoo с g ++ (со статическим libgcc, статическим libstdc ++), это может привести к тому, что все символы c ++ будут содержаться в libfoo.so , Это может заставить все работать гладко, но не то, что я действительно хочу.