Линковка .so

gcc src1.c -c
...
gcc srcn.c -c
gcc -shared -o trgt.so src1.o ... srcn.o

Большое спасибо, действительно это так... :) Я работаю с RHIDE и он немножко "тормозит" и не совсем хочет выгонять .so, но с обычным .mak все работает!

Блин, еще один шибка граматнай советчик пришел. Про -fPIC забыл, естественно, как и про многие другие существенные детали. Короче, настоятельно не рекомендуется делать это все руками - тупо и непортабельно получится. Правильный путь - читать до просветления info libtool.

vsl ya pro -fPIC otlichno znayu i pomnyu :) i pro -DPIc togda uzhe davai pripishem. Chego rugatsya to ? ya napisal samiy prostoi variant. cool hacker blin . Ili ty hochesh skazat chto ne poluchitsya .so tem metodom kotoriy ya opisal (pod Linux)

Да уж, бля, простой вариант... Ты получишь .so. Но работать оно не будет. Так что учись, это полезно. Не все же время в песочнице играть. Никогда не видел, как в произвольном месте SEGFAULT ловят динамические бинарники, без -fPIC собранные? Ну а -DPIC - это на фиг не надо, за исключением крайне редких и нежелательных случаев, когда ты в своем коде закладываешься на разницу между статическими и динамическими объектами.

SEGF ne budet poka ya ne popytayus otkryt libu dlopen esli prosto s ney slinkovatsya vse budet ok

Ни фига подобного. Разницы особой нет, как прилинковываться. Но, опять же, все от платформы сильно зависит. На Альфе, к примеру, никакого PIC не надо.

А что это вообще такое, все эти PIC, fPIC DPIC и тому подобное и на уровне чего его используют? В смысле, ядро это использует, или это вызовы (флаги и т.п.) Перла или С++? И самое главное, ХАУТУ где можно откопать по этому поводу (англ./русск. - все равно)...

to vsl razgovor pro linux to anon PIC - position independent code na urovne linkovshika/executera

Ну, про линукс, и что дальше? Во первых, давить умников, которые пишут "софт для линукс", портабельно писать надо. Во вторых, линуксу на Альфе таки PIC не нужен. То есть, не фиг самому во всем этом разбираться, надо тупо взять libtool.

To vsl: А чего так сразу - давить?.. Чем тебе мешают умники, которые пишут "софт для Линукса"? Если бы ничего не писали, то и не было бы его, Линукса... :)

А ты когда нибудь занимался портированием такого софта, который "дизигнед фор линьюкс"? Думаешь, для чего всякие Automake/Autoconf/Libtool сделаны? Дабы не только портабельность обеспечить, а еще и все удобства самому разработчику предоставить. Нет же, находятся ламеры, прописывающие не просто линух-специфичные вещи в Makefile, а вообще что-то, что только для одного конкретного дистрибутива канает. Писать надо ПОРТАБЕЛЬНО хотя бы в пределах всех известных юниксов, я же не утверждаю, что требуется обязательно портабельность на всякие там виндузы да макоси. Кстати, портабельность обеспечивает дополнительную надежность. Как ты думаешь, по каким частям тела и чем тяжелым надо бить тех, кто использует сишные конструкции навроде такой:

int i; char *c; ... i = *((*int)(c+n))

И ведь, блин, частенько встречается... Все от ламерского подхода "у меня работает - и ладно". А то, что на каком-нить Спарке это работать не будет, ламаков не волнует. Та же история и с мейкфайлами...

Дык, не нравится - не портируй. Сам пиши. С чего ты взял, что кто-то обязан писать так, как тебе нравится? И вообще, поди напиши нормальную (читай, для юзверя удобную) прогу на чистом посиксе. Устанешь кувыркаться. На то и расширения в осях делают, чтоб программеру дать дополнительный инструмент. Не использовать его там, где надо - глупо. А тот код, что ты в пример привел, не имеет никакого отношения к "дизигнед фор линьюкс". Где же здесь специфический для оси код? Ламер кропал, согласен, но причем здесь Linux? С тем же успехом можно было написать и Designed for MS Windows. И причем здесь ламерский подход, если чел пишет для себя? Он же не заставляет тебя его код юзать / портировать. Идея Open Source: хочешь - юзай / читай / переделывай, не хочешь - не надо. Бери коммерческую прогу, плати за нее баксы и не жужжи. andy.

Ну, расскажи, насколько отличаются фичи линуха на x86, линуха на Sparc и линуха на Alpha? А потом добавь к списку Digital Unix и Solaris. Фичи будут весьма идентичные, надо только не полениться configure.in написать для проверки их всех. Между прочим, это GNU way, то есть, рекомендации лучших сырцоводов. За примером отправляю смотреть на GNU hello.

А такой код - он не линьюх-специфичный, а x86-специфичный. Что еще хуже.

Ну имей же совесть, vsl, если я все за тебя сделаю, то за что же тогда тебе бабки-то платить? :). andy.