|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 09 Mar 2007 19:09:30
To : Sergey Khvatov
Subject : Re: Динамическая линковка программы
--------------------------------------------------------------------------------
2007-03-09, Sergey Khvatov <xbatob@techno.spb.ru> пишет:
> Fri Mar 09 2007 13:42, Grigoriy Shpakov wrote to Alex Korchmar:
>
> GS> From: Grigoriy Shpakov <grigory@sirena2000.ru>
>
> GS> Как-то раз Alex Korchmar(hue-moe@so.yandex.ru) написал:
>
> GS>>> В общем, нужно что-то с этим сделать. Одна из идей - разбиение
> GS>>> проекта на
> AK>> освоить наконец понятие "библиотека" ?
>
> GS> Дык есть они у нас. То, что не находится в основном каталоге с
> GS> исходниками, в результате компиляции становится библиотеками.
> GS> Только что толку, если линковка все равно статическая. Процесс все
> GS> равно долгий получается.
>
> Hе переживайте. Alex Korchmar основное что тут делает - всех на @!#$ посылает.
Он туда посылает только совсем розовые сопли. Или бульбулятеры вышэ
головы.
А сейчас он (как это часто бывает) -- сказал по делу, хотя и без
разжёвывания.
>
> По делу. Это у вас линковка объектнков столько идёт? Подозрительно - этот
> теперь процесс довольно быстрый. Hо тогда вы можете оформить ваши библиотеки
Вот и остальные думают, что подозрительно.
> как разделяемые. Тут правда возникнут проблемы с совместимостью, но они
И подозревают, что эта туча объектников вообще как библиотеки
не оформлена. Соответственно, сношаться с разделяемыми пока рано.
> преодолимые. Ещё можно использовать dlopen() с компанией. Это как раз более
> всего соответсвует .dll, да и более совместимо. Правда и возни больше.
dlopen вообще говоря менее совместимо. Сомневаюсь, что он вообще
работает для coff.
>
> Более правильный метод - разбить проект на кучу наленьких независимых задач,
> общающихся между собой по сети (unix domain который на самом деле просто ipc).
Подозреваю, что они и сами знают, что это более правильный метод.
Только хер кто даст на это денег. В смысле -- чтобы проект месяца три
буксовал, затем год ловить ошыбки в новой парадигме.
> Было же такое (smalltalk например, а потом nextos - вполне живой проект был)
> Только это потребует изменения идеологии и как следствие значительных
> изменений во всех компонентах проекта. Да ещё и сам message flow engine
> наверное писать придётся.
>
> Хотя как оказалось это не так сложно. У нас на железке (ARM, 8MB fjash, 32Mb
> RAM) крутятся около 30 наших процессов, каждый порядка 3..30 Kb
>
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
