Здравствуйте, _darkangel_, Вы писали:

>> Если ключи компилятора/линкера в настройках проекта немного отличаются
>> от тех, что в тестах — валится exception в Билдеровской CC3250MT.DLL
__>Не удивительно. Тебе ж если дать в место ножа вилку наверно тоже не
__>понравиться
Возможно, стоило сделать акцент на "немного отличаются" — как например для single- и multi-threaded.
Это все же не нож и вилка. А ключей в проекте предостаточно

>> То есть сам по себе log4cpp под Билдером вроде работает, а вот в составе
>> проекта его уже работать не заставишь.
>> Можно ли это как-нибудь победить?

__> log4cpp прекрасно работает под как минимум 4-мя различными
__>компиляторами — те что я регулярно гоняю.
Кстати, какими именно?

__>Для сборки самого log4cpp
__>нужно минимум define-ов — WIN32, LOG4CPP_HAS_DLL, LOG4CPP_BUILD_DLL. В
__>модуле, который его использует должен быть продефайнен LOG4CPP_HAS_DLL.
__>Это все. Ну или приведи в соответствие настройки твоего проекте с теми
__>что в log4cpp/bcb5. Или наоборот. Главное чтоб одинаковые были. Как
__>только это сделаешь, так сразу и заработает.
Все верно.

Я говорил про невозможность использования dll,
>> (Например, рабочий exe'шник можно построить только с cw32mti.lib; c
>> cw32i.lib или cw32mt.lib — нельзя! А рабочую dll построить не получается
>> уже ни с чем...)
которая сама использует log4cpp.dll
log4cpp.dll, как и exe тесты для нее строятся нормально после описанных выше действий.
Runtime проблемы в CC3250MT.DLL возникают, когда некто использует impl.dll, которая в свою очередь использует log4cpp.dll.
Где-то в impl.dll:
[code]logger.debug("Help!");//Здесь-то CC3250MT.DLL и ломается[code]