создание .so, который является также исполняемым файлом
В теории да, если Вы распределяете определенные блоки LINQ и любые зависимости. Однако это нарушает лицензирование Microsoft. Scott Hanselman записал сообщение в блоге [приблизительно 110] Развертывающийся ASP.NET MVC на ASP.NET 2.0 , который подобен тому, что Вы желаете сделать.
2 ответа
Создание вашей общей библиотеки с параметром -pie , похоже, даст вам все, что вы хотите:
/* pie.c */
#include <stdio.h>
int foo()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return 42;
}
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
/* main.c */
#include <stdio.h>
extern int foo(void);
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so
$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$
PS glibc реализует write (3) через системный вызов, потому что ему больше некуда вызывать (это уже самый низкий уровень ). Это не имеет ничего общего с возможностью выполнить libc.so.6 .
Я полагаю, у вас будет указатель ld -e на точку входа, которая затем будет использовать семейство функций dlopen () для поиска и загрузите остальную часть динамического компоновщика. Конечно, вам нужно будет убедиться, что сам dlopen () был либо статически связан, либо вам, возможно, придется реализовать достаточное количество вашей собственной заглушки компоновщика, чтобы добраться до него (используя интерфейсы системных вызовов, такие как mmap () так же, как делает сама libc.
Ничто из этого не кажется мне "приятным". Фактически, просто мысль о чтении исходных текстов glibc (и исходного кода ld-linux , в качестве одного примера) достаточно, чтобы оценить объем работы, для меня это звучит довольно мрачно и может быть кошмаром переносимости. Могут быть серьезные различия между тем, как Linux реализует ld-linux , и тем, как выполняются связи в OpenSolaris, FreeBSD и так далее. (Не знаю).