Пробовал ли кто-нибудь использовать библиотеку log4cpp в Билдере? Столкнулся со сложностями, думаю как поступить.
Прежде всего, log4cpp В Билдере 5 не компилируется — нужно произвести несколько правок в исходниках(проблемы с include'ами и define'ми, и проектом), только после этого можно получить dll.
Хуже то, что тесты из поставки работают, но вот как только встраиваешь log4cpp в свой проект — все немедленно валится.
Если ключи компилятора/линкера в настройках проекта немного отличаются от тех, что в тестах — валится exception в Билдеровской CC3250MT.DLL
(Например, рабочий exe'шник можно построить только с cw32mti.lib; c cw32i.lib или cw32mt.lib — нельзя! А рабочую dll построить не получается уже ни с чем...)
То есть сам по себе log4cpp под Билдером вроде работает, а вот в составе проекта его уже работать не заставишь.
Можно ли это как-нибудь победить?
Или может, лучше другой logging framework а-ля log4j выбрать?
iAlexander пишет: > > Пробовал ли кто-нибудь использовать библиотеку log4cpp в Билдере? > Столкнулся со сложностями, думаю как поступить. > Прежде всего, log4cpp В Билдере 5 не компилируется — нужно произвести > несколько правок в исходниках(проблемы с include'ами и define'ми, и > проектом), только после этого можно получить dll. > > Хуже то, что тесты из поставки работают, но вот как только встраиваешь > log4cpp в свой проект — все немедленно валится.
Ты не первый У нас куча народа писала самописные логирующие
системы на каждый новый проект только потому, что не могли собрать
нормально.
> Если ключи компилятора/линкера в настройках проекта немного отличаются > от тех, что в тестах — валится exception в Билдеровской CC3250MT.DLL
Не удивительно. Тебе ж если дать в место ножа вилку наверно тоже не
понравиться
> (Например, рабочий exe'шник можно построить только с cw32mti.lib; c > cw32i.lib или cw32mt.lib — нельзя! А рабочую dll построить не получается > уже ни с чем...) > > То есть сам по себе log4cpp под Билдером вроде работает, а вот в составе > проекта его уже работать не заставишь. > Можно ли это как-нибудь победить?
log4cpp прекрасно работает под как минимум 4-мя различными
компиляторами — те что я регулярно гоняю. Основная проблема всегда лежит
в плоскости сборки. Мой тебе совет — сделай проект для log4cpp в
Builder-е САМ. С нужными тебе настройками. Я не могу гарантировать, что
то, что лежит в каталоге bcb5 нормальное. Для сборки самого log4cpp
нужно минимум define-ов — WIN32, LOG4CPP_HAS_DLL, LOG4CPP_BUILD_DLL. В
модуле, который его использует должен быть продефайнен LOG4CPP_HAS_DLL.
Это все. Ну или приведи в соответствие настройки твоего проекте с теми
что в log4cpp/bcb5. Или наоборот. Главное чтоб одинаковые были. Как
только это сделаешь, так сразу и заработает.
Здравствуйте, _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]
Здравствуйте, _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:
logger.debug("Help!"); //Здесь-то CC3250MT.DLL и ломается
iAlexander пишет:
> __> log4cpp прекрасно работает под как минимум 4-мя различными > __>компиляторами — те что я регулярно гоняю. > Кстати, какими именно?
Главные msvc-8.0, gcc-4.1.1, borland-6.0 + update 4 — регулярная
сборка и использование. Когда тестировал релиз log4cpp 1.0, то собирал
msvc-6.0 + sp6, msvc-7.0, msvc-7.1, msvc-8.0, mingw-3.4.5, какой-то из
gcc уже не помню какой.
> Я говорил про невозможность использования dll, >> > (Например, рабочий exe'шник можно построить только с cw32mti.lib; c
Ну так построй log4cpp.dll без использования ниток. Что мешает это
сделать? При этом impl.dll тоже обязанна быть собранная без ниток ибо
несоответствие рантаймов это 100% crash.
>> > cw32i.lib или cw32mt.lib — нельзя! А рабочую dll построить не получается >> > уже ни с чем...) > которая сама использует log4cpp.dll > log4cpp.dll, как и exe тесты для нее строятся нормально после описанных > выше действий. > Runtime проблемы в CC3250MT.DLL возникают, когда некто использует > impl.dll, которая в свою очередь использует log4cpp.dll. > Где-то в impl.dll: > > logger.debug("Help!"); //Здесь-то CC3250MT.DLL и ломается >
Если impl.dll слинкована с сс3250.dll, а log4cpp.dll слинкована с
CC3250MT.DLL, то конечно же шандарахнет. Нельзя собирать плюсатые проги
с разными рантаймами.
Здравствуйте, _darkangel_, Вы писали:
__>Если impl.dll слинкована с сс3250.dll, а log4cpp.dll слинкована с __>CC3250MT.DLL, то конечно же шандарахнет. Нельзя собирать плюсатые проги __>с разными рантаймами.
Конечно же слинкована с cw32mt.LIB, хотел ты сказать.
Линковал по всякому — и то, и другое в разных комбинациях. Но с одинаковым успехом, то есть без него.
Это все было с 0.35rc. Буду пробовать 1.0
iAlexander пишет:
> __>Если impl.dll слинкована с сс3250.dll, а log4cpp.dll слинкована с > __>CC3250MT.DLL, то конечно же шандарахнет. Нельзя собирать плюсатые проги > __>с разными рантаймами. > Конечно же /слинкована/ с cw32mt.LIB, хотел ты сказать.
Нет. Я сказал именно то что сказал. Посмотри depends.exe с каким
рантаймом у тебя слинкована impl.dll и log4cpp.dll. У них в зависимостях
обязательно должна быть одна и таже ссблаблабла.dll. Если разные, будет
падать. У тебя в настройках проектов должно быть одинаково выставлены
свойства dynamic RTL и Multithreading. Это как минимум. Если игрался с
ABI несовместимыми ключами, то и их нужно привести в соответствие.
> Линковал по всякому — и то, и другое в разных комбинациях. Но с > одинаковым успехом, то есть без него. > Это все было с 0.35rc. Буду пробовать 1.0
Здравствуйте, _darkangel_, Вы писали:
>> Конечно же /слинкована/ с cw32mt.LIB, хотел ты сказать.
__>Нет. Я сказал именно то что сказал. Посмотри depends.exe с каким __>рантаймом у тебя слинкована impl.dll и log4cpp.dll. У них в зависимостях __>обязательно должна быть одна и таже ссблаблабла.dll.
Это уже скорее больше флуд, но все же:
когда говорят, что dll/exe слинкована с, имеют в виду встроенные в dll/exe на момент линковки, не рантайма(!) библиотеки, будь то заголовочные и малые по объему lib, или же полновесные статические lib. Но все же lib, не dll.
Именно ими [lib] и определяются зависимости (dll).
>> Линковал по всякому — и то, и другое в разных комбинациях. Но с >> одинаковым успехом, то есть без него. >> Это все было с 0.35rc. Буду пробовать 1.0
__>В этом нет необходимости. Разницы никакой.
Это уже проверено?
Как правило, разница все же присутствует.
iAlexander пишет:
> __>Нет. Я сказал именно то что сказал. Посмотри depends.exe с каким > __>рантаймом у тебя слинкована impl.dll и log4cpp.dll. У них в зависимостях > __>обязательно должна быть одна и таже ссблаблабла.dll. > Это уже скорее больше флуд, но все же: > когда говорят, что dll/exe *слинкована с*, имеют в виду встроенные в > dll/exe *на момент линковки, не рантайма(!)* библиотеки, будь то > заголовочные и малые по объему lib, или же полновесные статические lib. > Но все же lib, не dll. > Именно ими [lib] и определяются зависимости (dll).
Понимаешь, если вот все то, что ты только что сказал, применить к
linux платформе, то очевидно, что любой линуксоид посмотрит на тебя как
минимум странно . А так как я общаюсь и с виндузятниками и с
линуксоидами, то иметь два различных словаря для них это большая
роскошь. И на бытовом уровне. Меня мало волнует как там называется
foo.lib по той простой причине что подавая на вход линкеру foo.lib вовсе
не значит, что результирующий exe/dll будет зависить от foo.dll. Поэтому
когда я говорю слинкована, то мне глубоко пофигу как называется lib-файл
с экспортируемыми файлами, я оперирую понятием динамической линковки.
Если бы мы говорили о статической линковке, то еще можна было бы
аппелировать к названиям либ, но ведь мы про динамику, не так ли?
Еще у меня сложилось впячетление, что ты немного не понимаешь о
каком рантайме я говорю. Я говорю о библиотеке та которая RTL ==
borland runtime library. А ты похоже под этим понимаешь нечто другое.
>> > Линковал по всякому — и то, и другое в разных комбинациях. Но с >> > одинаковым успехом, то есть без него. >> > Это все было с 0.35rc. Буду пробовать 1.0 > > __>В этом нет необходимости. Разницы никакой. > Это уже проверено?
Добавлены фабрики, может какие-то мелкие баги поправили, уже не помню. Я
один из разработчиков.
> Как правило, разница все же присутствует.
Здравствуйте, _darkangel_, Вы писали:
__>любой линуксоид посмотрит на тебя как минимум странно
Теперь я буду держать это в голове всякий раз, когда буду писать про Билдер
__>Поэтому когда я говорю слинкована, то мне глубоко пофигу как называется lib-файл __>с экспортируемыми файлами, я оперирую понятием динамической линковки.
Ok. Это тоже
__>Если бы мы говорили о статической линковке, то еще можна было бы __>аппелировать к названиям либ, но ведь мы про динамику, не так ли? __> Еще у меня сложилось впячетление, что ты немного не понимаешь о __>каком рантайме я говорю. Я говорю о библиотеке та которая RTL == __>borland runtime library. А ты похоже под этим понимаешь нечто другое.
Рантайм вряд ли можно понимать по-разному. И скорее их все же не более одного.
Если говоря про RTL, ты имел в виду CC3250MT.DLL, то я понял, и можно далее не продолжать.
__>Добавлены фабрики, может какие-то мелкие баги поправили, уже не помню. Я __>один из разработчиков.
Иногда из-за мелкой баги может встать и большой проект. И не факт, что какой-то из мелких фиксов устранил side effect, приводящий к моим проблемам.
А в случае с Билдером я с некоторых пор воспринимаю скомпилированный и прогнанный в рантайме проект как большую удачу
А вот разработчик — это уже интересно.
Собираешься здесь оставаться? (я посмотрел, ты зарегистрировался недавно)
iAlexander пишет:
> __>Если бы мы говорили о статической линковке, то еще можна было бы > __>аппелировать к названиям либ, но ведь мы про динамику, не так ли? > __> Еще у меня сложилось впячетление, что ты немного не понимаешь о > __>каком рантайме я говорю. Я говорю о *библиотеке* та которая RTL == > __>borland runtime library. А ты похоже под этим понимаешь нечто другое. > Рантайм вряд ли можно понимать по-разному. И скорее их все же не более > одного.
Ага, мечтай. Их много разных . Есть как минимум 1) shared multi
threaded 2) static multi threaded 3) shared single threaded 4) static
single threaded. И если собрать две dll-ки с разними рантаймами
то почти 100% падеж гарантирован.
> Если говоря про RTL, ты имел в виду CC3250MT.DLL, то я понял, и можно > далее не продолжать. > > __>Добавлены фабрики, может какие-то мелкие баги поправили, уже не помню. Я > __>один из разработчиков. > Иногда из-за мелкой баги может встать и большой проект. И не факт, что > какой-то из мелких фиксов устранил side effect, приводящий к моим проблемам. > А в случае с Билдером я с некоторых пор воспринимаю скомпилированный и > прогнанный в рантайме проект как большую удачу
Мы с него съехали ибо заколебались выхватывать его приколы. То
исключения проскакивают, то потоки перестают работать из-за того, что
оно где-то там в углу мелко написало, что precompiled файлы неправильно
собрало.
> А вот разработчик — это уже интересно. > Собираешься здесь оставаться? (я посмотрел, ты зарегистрировался недавно)
Я сдесь очень давно, просто старый аккаунт был зареган на мыло которого
уже нет, а пароль я забыл. Пришлось заново регистрироваться.
Уходить в планах не было .
>> Линковал по всякому — и то, и другое в разных комбинациях. Но с >> одинаковым успехом, то есть без него. >> Это все было с 0.35rc. Буду пробовать 1.0
__>В этом нет необходимости. Разницы никакой.
Разница все же есть, как оказалось.
При одних и тех же настройках проекта, использующего log4cpp.lib, include'ы из log4cpp и log4cpp.dll —
в случае версии 0.35rc происходит краш в сс3250.dll в случае версии 1.0 работает!
Сравнил файлы проектов из разных версий — там отличаются наборы пакетов. Исходники не сравнивал.
_darkangel_, если ты разработчик, не мог бы ты внести фиксы для BCB5 подпроекта в пакете log4cpp?
Define'ы там, и прочее.
Это, наверное, эффективнее, чем наносить точечные удары по форумам.
Или это часть технологии воспитания opensource разработчиков? (Вроде "после установки доработать напильником" )
iAlexander пишет:
> __>В этом нет необходимости. Разницы никакой. > Разница все же есть, как оказалось.
Что есть очень странно. Очень.
> *_darkangel_*, если ты разработчик, не мог бы ты внести фиксы для BCB5 > подпроекта в пакете log4cpp? > Define'ы там, и прочее.
Какие? Я сравнил log4cpp-0.3.5rc1, log4cpp-0.3.5rc3 и log4cpp-1.0 между
собой в директории bcb5 — они идентичны. Makefile.in не в счет, ибо к
этому случаю они не относятся.
> Это, наверное, эффективнее, чем наносить точечные удары по форумам. > Или это часть технологии воспитания opensource разработчиков? (Вроде > "после установки доработать напильником" )
Вся проблема в том что я не наношу никаких точечных ударов . Пакет работает. Когда у кого-либо возникают проблемы он должен или их
идентифицировать или сообщить как воспроизвести ошибочное поведение.
Только тогда opensource разработчики могут приступить или не приступить
к решению проблемы. Еще не стоит забывать, что не у всех участников
проекта может быть в наличии BCB5. Вот например у меня его нет. Хочешь
чтобы у других не было таких проблем как у тебя? Помоги им. И тогда
следующему пользователю не нужно будет дорабатывать напильником.
Здравствуйте, _darkangel_, Вы писали:
__>Какие? Я сравнил log4cpp-0.3.5rc1, log4cpp-0.3.5rc3 и log4cpp-1.0 между __>собой в директории bcb5 — они идентичны. Makefile.in не в счет, ибо к __>этому случаю они не относятся.
Да, и поэтому и в log4cpp-0.3.5rc3, и в log4cpp-1.0 одни и те же проблемы при компиляции проекта.
__> Вся проблема в том что я не наношу никаких точечных ударов . Пакет __>работает. Когда у кого-либо возникают проблемы он должен или их __>идентифицировать или сообщить как воспроизвести ошибочное поведение. __>Только тогда opensource разработчики могут приступить или не приступить __>к решению проблемы. Еще не стоит забывать, что не у всех участников __>проекта может быть в наличии BCB5. Вот например у меня его нет.
Это конечно. Но у кого-то из разработчиков он наверное есть
__>Хочешь __>чтобы у других не было таких проблем как у тебя? Помоги им. И тогда __>следующему пользователю не нужно будет дорабатывать напильником.
Почти два (!) года назад я описал не только проблемы, которые возникли в BCB5, но и дал их решение на багтрекере log4cpp. http://sourceforge.net/tracker/index.php?func=detail&aid=1630070&group_id=15190&atid=115190
Однако воз и ныне там
iAlexander пишет:
> > __>Какие? Я сравнил log4cpp-0.3.5rc1, log4cpp-0.3.5rc3 и log4cpp-1.0
между > __>собой в директории bcb5 — они идентичны. Makefile.in не в счет, ибо к > __>этому случаю они не относятся. > Да, и поэтому и в log4cpp-0.3.5rc3, и в log4cpp-1.0 одни и те же
проблемы при компиляции проекта.
Меня тогда не было, да и не собирал никогда BCB5. Я глянул запись.
Тут есть нюанс. В трекере ты описал проблему и даже попытался привести
решение ее. Но есть одно большое НО. Это лишь приблизительное решение
доступное для повторения только тем членам группы у которых есть две
вещи: 1) BCB5; 2) Время.
Если все еще есть желание мы можем поступить следующим образом. Ты
поднимаешь из CVS-а log4cpp. Вносишь необходимые модификации. Делаешь
патч и отсылаешь его мне. Я применяю его и тестирую на доступных мне
компиляторах и если все ОК, то комичу в trunc. Так пойдет?
P.S. В личку уйти не смог — почтовик посылает далеко и надолго.
Здравствуйте, _darkangel_, Вы писали:
__>Да, и поэтому и в log4cpp-0.3.5rc3, и в log4cpp-1.0 одни и те же __>проблемы при компиляции проекта. >> Брррр. Я совсем потерялся. Что ты исправил в 1.0 что оно стало работать?
Итак:
log4cpp-0.3.5rc3 и log4cpp-1.0 оба не компилируются в BCB5. Оба требуют одинаковой корректировки для компиляции.
Разница между ними —
в исходниках
незначительная в ключах компилятора и пакетах в файле проекта.
__> Если все еще есть желание мы можем поступить следующим образом. Ты __>поднимаешь из CVS-а log4cpp. Вносишь необходимые модификации. Делаешь __>патч и отсылаешь его мне. Я применяю его и тестирую на доступных мне __>компиляторах и если все ОК, то комичу в trunc. Так пойдет?
Давай сделаем.
Только тестировать на других компиляторах не нужно — изменения только в каталоге bcb5.
Лучше достань Builder 5 — я думаю, это не проблема
__>P.S. В личку уйти не смог — почтовик посылает далеко и надолго.
Моя сервер не отвечает или твой сервер тебя посылает?
У нас куча народа писала самописные логирующие 
