Генерация исполняемого файла.

Novell-ch> с гарантированой работоспособностью на разных линуксах?

Программа не должна использовать libc что-ли?

интерпретатор( vm ) + программа в конце

Всё основано на api, толи либсишном, толи ядрёном. Либсишный более менее стабильный, но иногда всё таки меняется. Про ядрёный точно не знаю, но думаю он нестабильный by design. Так что можно сделать только что-то, что работает некоторое время, от одного изменения api до другого.

Можно конечно сделать некую вм, api которой заведомо стабильный. Но это просто перенос проблемы из одного места в другое. Всё равно вм передически править надо будет.

На практике линкуют либси статически. Бинарник великоватъ, но работает.

Бинарник, собранный под x86, будет гарантированно неработоспособен на ARM, SPARC, POWERPC, ALPHA и т.д.

Может, поточнее определишь, что конкретно входит в круг «разных линуксов»?

Естественно, редактор ELF-файлов можно написать. В чем вопрос-то?

Либсишный более менее стабильный, но иногда всё таки меняется.

Есть POSIX.

Про ядрёный точно не знаю, но думаю он нестабильный by design.

Ты думаешь неправильно.

Вчера хотел создать тред в толксах, но побоялся слива: в оффтопике такое бывает, что размер/md5 бинарника меняется после его исполнения, например, он записывает в себя свою конфигурацию. А линуксе бинарники статичные? Или просто UNIX-Way призывает хранить конфигурацию в текстовых файлах? Возможно ли под линуксом написание такой вендо-Way самоизменяемой программы? Понятное дело, что это не нужно, но сам факт интересен.

ясное дело что в пределах одной платформы, под разными линуксами я подрозумеваю десктопные дистрибутивы 2006-2012 годов.

:)

$ cat 1.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
        printf("first!\n");
        FILE *f = fopen("1.c", "w");
        fprintf(f, "#include <stdio.h>\nint main(){printf(\"second!\\n\");return 0;}");
        fclose(f);
        unlink("a.out");
        system("gcc 1.c");
        execv("a.out", 0);
        return 0;
}

$ gcc 1.c && ./a.out
first!
second!

http://stackoverflow.com/questions/1893235/etxtbsy-and-how-to-override-it
http://groups.google.com/group/comp.unix.programmer/browse_thread/thread/9108...

Matlab, Quartus - примеры монстров, которые распространяются только бинарно и тащат за собой свои /etc, /lib, perl, xlib, qt и все, от чего зависят.
Qt-шный установщик Quartus запихан в run-файл (sh), он распаковывает себе окружение и в нем работает.

Не уверен, можно ли в случае статической линковки добиться переносимости между, например, ядрами 2.4 и 2.6.
А в случае динамической - между версиями libc.

sh, который есть в POSIX, переносимее ИМХО.

под разными линуксами я подрозумеваю десктопные дистрибутивы 2006-2012 годов

Собирай программу на 32-битном дистрибутиве и линкуй статически с dietlibc.

Можешь посмотреть для примера на мою video3x.

Останется только прицепить к ELF-у свои данные и потом их оттуда достать.

Есть ли способ создания исполняемых файлов (бинарников) без помощи внешних программ с гарантированой работоспособностью на разных линуксах?

нету. Гарантии абсолютной нету, с точностью до ABI: сисколлов, с либы, тулчейна, и т.п.

Если собирать не статические библиотеки (shared object, so) — гарантированно поломается при несовместимых версиях в тулчейне и си либах. Например, обновились на новый glibc, в котором incompatible ABI changes => всё, приплыли — старый бинарник с новой либой не запускается.

Поломанный интерфейс либц - другие компоненты тулчейна.

Можно придумать манифесты и запускать через LD_PRELOAD, но зачем выдумывать велосипед, когда проще собрать статически?

Интерфейс либц-сисколлы более стабилен. Но всё-таки, например, linux 32 битный и 64 битный — разные ABI, разный интерфейс.

Самодостаточная программа, которую можно сгенерировать с нужным содержанием.

например, fasm позволяет генерировать самодостаточные бинарники, вручную задавая секции ELF-файла. Как пример, до чего можно доизвращаться, можешь посмотреть ПурБасик (пурик, http://lurkmore.to/PureBasic — гыгыгы, лурконавты ниасилили)
http://en.wikipedia.org/wiki/PureBasic

В общем, это Basic, реализованный на FASM, со своей стд. библиотекой с 10500 функций, с возможностью макропроцессором похакать генерируемый асм исходник, с возможностью линковки с С библиотеками (например, GTK)

но у кого какие есть идеи по этому поводу?

перекрыть динамический линкер (man 8 ld.so) каким-то стабом со стабильным ABI, как вариант — какая-то VM.

Про ядрёный точно не знаю, но думаю он нестабильный by design.

+10500

Либсишный более менее стабильный, но иногда всё таки меняется.

зависит от разновидности libc. glibc — тоже не очень-то стабильный, и больше к линуксу прикручен. Его нестабильность проявляется в 2х вещах: завязанность на ядрёное API, само по себе нестабильное, и завязанность на gnu toolchain в gcc/binutils/libc

Есть другие более стабильные и мобильные (переносимые) libc-ы, например, newlib или тот же dietlibc

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

в более свежем ABI не работает, см. http://www.hackercurriculum.org/elf

в макинтоше получается более толсто: http://osxbook.com/blog/2009/03/15/crafting-a-tiny-mach-o-executable/

http://news.ycombinator.com/item?id=1663858
http://blogs.oracle.com/ksplice/entry/hello_from_a_libc_free

посмотри на ebfc http://www.muppetlabs.com/~breadbox/software/elfkickers.html

перечитай http://asm.sourceforge.net/resources.html#docs

http://www.muppetlabs.com/~breadbox/software/tiny/ — в конце гуёвый puzzle.asm для иксов

Есть POSIX.

официально линукс не совсем posix, а тс спрашивает именно про линукс.

Ты думаешь неправильно.

Это ты думаешь неправильно.

Возможно ли под линуксом написание такой

http://www.hackercurriculum.org/elf

http://vx.netlux.org/lib/static/virus-writing-HOWTO/virus-writing-HOWTO/_html...
http://virus.bartolich.at/virus-writing-HOWTO/_html/i386-redhat8.0-linux/magi...
http://vx.netlux.org/lib/vrn00.html

Вот в FreeDOS правильный дизайн был: http://en.wikipedia.org/wiki/Pat_Villani , а лялих такой лялих

In contrast to MS-DOS, which is not designed to be reentrant, the system calls of his operating system were,[2] which is often a requirement for multitasking and real-time applications in embedded systems. This system was named NSS-DOS and also offered commercially.[2]

When one potential contractor sought to use the OS in a system equipped with Motorola 680x0 processors instead of Intel x86 processors, for which the system was designed originally and which utilize different instruction sets and memory models, Villani was able to redesign his system to become portable across a range of different compilers and target environments.[2] This move to a completely different target platform, while losing binary compatibility with existing applications, would have required a complete rewrite from scratch had his system not been written in a high-level language such as C, which allowed him to reuse large parts. His new DOS/NT used a microkernel architecture with logical separation of file system, memory and task manager.[2]

Ты думаешь неправильно.

Это ты думаешь неправильно.

?

...под разными линуксами я подрозумеваю десктопные дистрибутивы 2006-2012 годов.

Такое у мeня работает:

Собрать libc с отключённым nsswitch и выставленной минимальной версией ядра 2.4 и линковаться статически.

Первый пукт обязателен, иначе оно всё установленное libc за собой потянет и грохнется.

вот и я о том же. твоё утверждение без доказательсва вызвало у меня точто такие же мысли как и у тебя - моё. иными словами, ты хотя бы ссылку какую-нибудь привёл, или расписал поподробнее то, что ты возможно знаешь лучше чем я.

Этого, как бы, никто запретить не может. Но проблемы начнутся с момента, когда ты разместишь свой чудо-бинарник в каталоге, куда запрещена запись. Исполняемый код от изменяемых данных призывают отделять не просто так.

Если речь идёт не об изменении пары статически влинкованных строчек, может оказаться, что проще будет взять этот бинарный «чёрный ящик» и переписать весь его наблюдаемый функционал, тем самым сгенерировав исходник на подходящем ЯП. Который пересобрать компилятором в новый бинарник. А ещё лучше, предусмотрев изменяемые данные в виде параметров.

man 2 syscalls

Ты хоть сам её читал?

alloc_hugepages(2)          2.5.36        Removed in 2.5.44
...
free_hugepages(2)           2.5.36        Removed in 2.5.44
...
pwrite64(2)                               Added as "pwrite" in 2.2;
                                                 renamed "pwrite64" in 2.6

Добавление и удаление в 2.5 совершенно без разницы, так как это была нестабильная версия ядра. Переименование тоже никак не мешает, так как обращение идёт по номерам.