Я полагаю, что вы неправильно прочитали документацию по указанной вами ссылке. В частности, вы неправильно поняли его назначение - этот раздел называется «Цели» и описывает ряд гипотетических проектов для библиотеки отладки C ++ и последствия этих проектов для объяснения фактического выбора дизайна, который был сделан. Куски текста, которые следуют за цитируемыми вами строками, описывают хаос, который мог возникнуть в результате гипотетической реализации, которая имела отдельные конструкции для строк режима выпуска и режима отладки. Далее говорится:
По этой причине мы не можем легко предоставить безопасные итераторы для шаблона класса std :: basic_string, так как он присутствует во всей стандартной библиотеке C ++.
(Или, перефразируя это, предоставить специальную «отладочную» версию итераторов строк невозможно.)
...
С дизайном режима отладки libstdc ++ мы не можем эффективно скрывать различия между строками режима отладки и выпуска от пользователя. Неспособность скрыть различия может привести к непредсказуемому поведению, и по этой причине мы решили выполнять только изменения basic_string, которые не требуют изменений ABI. Ожидается, что влияние на пользователей будет минимальным, так как существуют простые альтернативы (например, __gnu_debug :: basic_string), а преимущество в удобстве использования, которое мы получаем от возможности смешивать отлаженные и отладочные блоки перевода, огромно.
Другими словами, проектирование режимов отладки и выпуска в GCC libstdc ++ отклонило эту гипотетическую реализацию с отдельными проектами для строк, особенно для того, чтобы разрешить перекрестную связь типа, которого вы беспокоитесь о том, как избежать .
Таким образом, у вас не должно возникнуть проблем с компиляцией вашей библиотеки один раз, без -D_GLIBCXX_DEBUG (или с ней, если по какой-то причине вы предпочитаете), и связыванием ее с любым режимом вашего приложения. Если у вас есть проблемы, это связано с ошибкой где-то. [Но см. Правку ниже! Это относится только к std::string, а не к другим контейнерам!]
Редактировать: После того, как этот ответ был принят, я ответил на следующий вопрос на std :: vector crash и понял, что вывод этого ответа неверен. Libstdc ++ GCC делает умные вещи со строками для поддержки «перекомпиляции при использовании» (в которой все использования данного объекта-контейнера должны быть скомпилированы с одинаковыми флагами, но использование одного и того же класса контейнера в программе не обязательно должно быть скомпилировано с одним и тем же флагов), но это не то же самое, что полная «компиляция на единицу», которая обеспечит необходимую вам возможность сшивки. В частности, в документации говорится об этой способности сшивания,
Мы считаем, что этот уровень перекомпиляции на самом деле невозможен, если мы намереваемся предоставить безопасные итераторы, оставить семантику программы неизменной и не снижать производительность в режиме выпуска ....
Таким образом, если вы передаете контейнеры через интерфейс вашей библиотеки, вам понадобится две отдельные библиотеки. Честно говоря, для этой ситуации я обнаружил, что самое простое решение - просто установить две библиотеки в разные каталоги (по одной для каждого варианта - и вы захотите, чтобы обе они были отделены от каталога вашей основной библиотеки). Кроме того, вы можете переименовать файл библиотеки отладки, а затем установить его вручную.
Как еще одно предложение - вы, вероятно, не часто запускаете это в режиме отладки. Возможно, стоит статически скомпилировать и связать отладочную версию в свое приложение, поэтому вам не нужно беспокоиться об установке нескольких динамических библиотек и сохранении их прямо во время выполнения.