новый оператор уже определен в пользовательском диспетчере памяти с библиотекой

Question

Извините за плохой заголовок, но, надеюсь, описание делает его более понятным.

На данный момент у меня есть одно основное приложение, которое создается вместе с другими библиотеками (такими как libpng, libvorbis и т. Д.).Я пытаюсь добавить libtheoraplayer в основное приложение, но продолжаю сталкиваться с проблемами:

1) При связывании с предварительно созданной библиотекой llibtheoraplayer и включении соответствующих заголовочных файлов возникает ошибка, в которой говорится, что pushMemoryManager не можетбыть найденным (часть нашего собственного менеджера памяти)

2) Сборка библиотеки вместе с основным приложением приводит к ошибке компоновщика "ошибка LNK2005:" оператор void * __cdecl new (unsigned int, void *) "(?? 2 @ YAPAXIPAX @ Z) уже определено в win32Mem.obj "

Я не совсем уверен, с чего начать отладку.Основное приложение не поддерживает STL, и я начал с изменения ссылок на STL в libtheoraplayer на наши собственные замены STL, но я все еще получаю ошибку 2, как указано выше, после нахождения испорченных файлов и их изменения.

Какие-нибудь дикие идеи?

Answer 1

Отключите ошибку компоновщика (преобразуйте в предупреждение) с помощью /FORCE и помолитесь, чтобы не было межбиблиотечного распределения, заканчивающегося различными распределителями.

Довольно сложно заменить функции выделения в Windows (NT или CE), потому что:

1. Динамические символы загружаются из определенных библиотек, поэтому вы замените, какой распределитель используется в вашем коде, но не который используется в библиотеках, которые вы динамически связываете. Если вы не создадите динамическую связь и не отключите ошибку компоновщика с помощью /FORCE, это будет правильно, и вы просто переопределите средства выделения из стандартной библиотеки.

   При динамическом связывании, если код, размещенный в одной библиотеке, выделяется, а код, находящийся в другой библиотеке, освобождается, будет иметь место несоответствие в используемых распределителях и, следовательно, возможно, произойдет сбой. К сожалению, это может легко произойти, даже если обе функции определены одной и той же библиотекой, но одна из них является шаблоном (поэтому экземпляр живет в библиотеке, ссылающейся на него), а другая - нет (поэтому он живет в библиотеке, определяющей его) .

2. Они имеют некоторые нестандартные точки входа в распределитель и иногда используют их из другого кода. Раньше мы использовали библиотеку duma и фактически сумели переопределить как распределители C (malloc / realloc / free), так и C ++ (оператор new и удаление оператора), но столкнулись с проблемой, когда мы начали использовать iostreams, где они выделяют со стандартной функцией, но бесплатно с чем-то вроде __debug_free или наоборот '.

С другой стороны, то же самое абсолютно тривиально в Linux, потому что в GNU libc malloc, realloc и free вызывают реальный распределитель с помощью указателей, которые вы можете легко переопределить (оператор new и оператор delete просто вызывают malloc и free соответственно в основном везде).