|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 27 Jan 2003 11:45:27
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
>>> Zahar Kiselev wrote:
ZK>>> Ответ даже на простейший вопрос "где, в какой библиотеке, определен
ZK>>> этот символ" времени требует.
VN>> А зачем тебе выяснение до такого уровня?
ZK> У меня при линковке вылезло два неопределенных символа - как быстро узнать
ZK> какую еще библиотеку программа хочет? Иногда это бывает понятно по именам,
ZK> а иногда нет. Естественно имеется в виду чужой код, и размером все же
ZK> побольше пары экранов.
Перебор перечисленного в ldd. Для библиотек - в соотв. секции по objdump.
Впрочем, твой пример с s_cmp и s_copy явно что-то другое давал.
ZK>>> Примеры имеют размер всего несколько экранов текста на _знакомом_ Си,
ZK>>> а твой Питон - длинный и непонятный.
VN>> (произносится загробным тягучим голосом)
VN>> Твой Питон длинный и непонятный. Ш-ш-ш-ш-ш-ш-ш-ш-ш...
VN>> Если код не связан с прямым манипулированием регистрами и прочей
VN>> ассемблерщиной, то на Питоне он будет в несколько раз короче.
VN>> (Hе люблю я Питон, но...)
ZK> Интересно - почему тебе можно не любить питон, а мне - нет? :-)
Одно - не любить, другое - не признавать того, что это его преимущество
по сравнению с C действительно есть. (Как и у прочих аналогичных языков -
Perl, Tcl, Ruby...)
ZK> И потом - "короче", еще не значит "лучше". Да, не спорю, _зная_ Питон можно
ZK> что-нибудь на нем быстро сляпать. Hо быстрота ляпания - далеко не
ZK> единственный критерий, по которому программу относят к "хорошим" или
ZK> "плохим". Второй важный критерий - это простота внесения изменений. Сам
ZK> понимаешь кого проще найти - программиста на Си или на Питоне.
А сколько времени этот программист потом будет писать объёмный по
функциональности кусок? А отлаживать?
ZK>>> Естественно предположить, что в системе, разные детали которой
ZK>>> написаны разными людьми, это выражено еще больше. В чем я и убедился на
ZK>>> примере с капризом линкера.
VN>> Угу. Давно хочу увидеть что-то похожее на COM.
ZK> Я плохо себе представляю что такое COM и с чем его едят. И главное - для
ZK> каких задач его "едят".
Винда. То же что OLE и ActiveX. Общий метод взаимосвязи компонент в
околообъектном духе. С общей на всех calling convention.
У него есть свои заморочки, но при адекватной подложке получается весьма
простой код взаимодействия.
VN>> И чтобы были решены все грабли с динамической линковкой. Hапример, чтобы
VN>> разные модули могли каждый видеть свою libc.
ZK> И как это использовать? Как средство собирания бутербродов из кусков кода,
ZK> написанных в разное время и под разные версии системы? Будет ли такой
ZK> вариант решения проблемы совместимости вообще работоспособен?
Вполне.
ZK> Может лучше все же
ZK> подогнать код под имеющуюся в системе libc? Это ведь один раз делать
ZK> придется, а ловить глюки упомянутого тобой хитрого подхода можно дооолго.
Это придётся не делать один раз, а пересобирать каждые полгода под новый
апгрейд системы, причём без шанса пройти этот процесс безглючно.
Обязательно где-то полезут грабли...
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
