Чтоб мой ELF с любой установленной LIBC запускался

не знаю. посмотри на сайте nvidia.

 

r90

Я в своём коде делаю так (для совместимости с BSD и Linux):

Код (Text):

1. #define _exit(a)    syscall(1, (void*)a,0,0)
2. #define read(a,b,c) syscall(3, (void*)a,(void*)b,c)
3. // далее идут все остальные универсальные
4. // системные функции: write, open, creat, ...
5.  
6. int syscall(int param_code, void* param_a, void* param_b, int param_c){
7.     asm(    "pushl %%edx\n\t"
8.         "pushl %%ecx\n\t"
9.         "pushl %%ebx\n\t"
10.         "pushl %%eax\n\t"
11.         "int $0x80\n\t"
12.         "addl $16,%%esp"
13.         : "=a" (param_code)
14.         : "a" (param_code), "b" (param_a), "c" (param_b), "d" (param_c)
15.     );
16.     return param_code;
17. }

Решение не оптимальное, но вполне рабочее.



Nothing

Угу, но символьные ссылки с именами более старых либ я нашёл только в Mandrake. Ни в одном другом дистрибутиве я ничего подобного не нашёл. Интерпретатор тоже не нашёл ничего подобного, т.к. выплюнул сообщение типа "Libc vx.x.x not found".

Во-первых, зачем собирать именно для самой старой, если мы хотим потом убрать версию из эльфа? Во-вторых, подправить (убрать) версию можно только ручками в хекс-редакторе?

Интерпретатор вызывается загрузчиком перед стартом программы. В основном, этот интерпретатор используется для динамической связки с *.so. Можно, конечно, использовать свой интерпретатор в любых других целях (vm, декриптор, ...), но стандартная функция - ресолвить импорт. Но сам интерпретатор по определению должен быть статическим, что затрудняет его разработку.

 

а нельзя импорт настраивать "вручную"?

 

Asterix

Для этого я и хотел свой интерпретатор писать, но это сложно. В принципе, можно, наверное, это организовать прямо в entry point (main), чтоб не таскать с собой интерпретатор, но это ещё сложнее

[offtop]

Думаю, что всё-таки правы были сорсфоржовцы, когда попросили нас удалить экзешники из тарбола Хорошо, что Eff не использует libc.

[/offtop]

 

Можно слинковаться статически, а можно тащить glibc с собой. Тока, если используешь потоки, то, в обоих случаях, возможно, придется 2 дистрибутива подготовить -- с LinuxThreads и с NPTL.

Если тащить с собой, то кладешь все потребные so-шки (libc.so, libgcc_s.so и пр.) в директорию своего приложения, а приложение запускаешь из скрипта, задав в нем LD_LIBRARY_PATH.
Напр.,
сложить so-шки в /opt/myapp/lib
а в скрипте
-------------------------------------------------
#!/bin/sh
export LD_LIBRARY_PATH=/opt/myapp/lib
/opt/myapp/bin/myapp
-------------------------------------------------

Или вместо LD_LIBRARY_PATH можно "прошить" директорию загрузки so-шек в сам исполняемый файл (если его местоположение фиксировано, конечно) с помощью опции компилятора -Wl,-rpath=/opt/myapp/lib
Напр.,
g++ -O3 -Wl,-rpath=/opt/myapp/lib myapp.cpp

В таком случае можно без скрипта.

 

Мда. Вот что значит беспорядочный процесс разработки опенсорс проекта... Тонны кода и все через жопу. Имхо фтопку этот линух...

 

hwegh
Просто неудобно распространять бинарники или даже не принято А с исходниками всё легко и просто, но это влияет на бизнес-схему. У *никсов своя идеология и я бы не рискнул сравнивать её с виндовой - это просто разные вещи.

А проблема с libc как-то сама собой разрешилась.

 

В топку линух не надо, но, к сожалению, проблема бинарной совместимости в линух является ключевой.