Портирование Линукс приложений под 64битные системы

Там ничего нового и не написали. Просто напомнили о существовании стандартов, которых следует придерживаться.

Зато в понятном и сжатом виде.

Больше всего в статье понравилось слово "Endianism". :D

Только ни слова, к сожалению, нет про 64битный режим работы с файлами. Что обязательно в таком случае компилировать с флагами -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE и т.д.

Table 7. 0x12345678 as two half words on a little-endian system Memory offset 0 2 Memory content 0x3412 0x7856

Что-то мне кажется, что таки в статье перепутаны машинные слова местами. Или я туплю?

Ха! Пишите на java и ненадо будет никуда портировать! Плюс опять же известные бонусы - меньше памяти жрать будет и шустрее работать.

>Ха! Пишите на java и ненадо будет никуда портировать! Плюс опять же известные бонусы - меньше памяти жрать будет и шустрее работать.

Ха! Иди перепиши ядро Linux на Java.

Ага - а мне дивайс драйверов на жабе плизЪ ... :)

> Плюс опять же известные бонусы - меньше памяти жрать будет и шустрее работать.

Да ты никак обкурился или сановский пеар совсем разъел твои мОзги.

LICQ на Slamd64 работает.

После рекомпиляции (правда, блин, libGL.la ручками приходится создавать), получается в полностью 64 битном режиме.

В заголовке либ написано что-то вроде:
"ELF 64-bit shared library, AMD x86_64", хотя работает на Celeron D с EM64T.

Что прикольно:
размер int в 64-битном линуксе все те же 4 байта.
с другой стороны, последняя дата отодвигается с января 2038 до 23:59:59 31 декабря 9999999 года. :-)

>Ха! Иди перепиши ядро Linux на Java.

Сначала создай Java PC :)))

>Что прикольно:
>размер int в 64-битном линуксе все те же 4 байта.
>с другой стороны, последняя дата отодвигается с января 2038 до 23:59:59 31 декабря 9999999 года. :-)

#include <time.h>

time_t time(time_t *t);

При чем тут размер int ? Функция времени возвращает time_t.
Который в kernel 2.4 сводится к long int.

Насчет того что для преодоления проблемы 2038 года нужно переходить на 64-битную архитектуру - автор сильно прогнал.
Достаточно подправить тип time_t, подправить kernel, пересобрать все программы ( они правда поломаться могут ).

> размер int в 64-битном линуксе все те же 4 байта.

Как это?

> Сначала создай Java PC :)))

Зачем? Пущай на венде работает :-)

"Насчет того что для преодоления проблемы 2038 года нужно переходить на 64-битную архитектуру - автор сильно прогнал."
Хм... Много (не)уважаемый (нужное подчеркнуть), откройте мне истину: ГДЕ я утверждал, что надо переходить на 64 битную архитектуру, чтобы преодолеть 2038?
А кроме того, не пофиг ли? Что-то мне подсказывает, что к 2038 году современные компы будут еще большим раритетом, чем 8086 сейчас. :-)

"При чем тут размер int ?"
Не при чем. Просто логично было ожидать, что что-то изменится.

"Который в kernel 2.4 сводится к long int."
На 2.4 не запускал. А вот на 2.6:
r00t@r00t:~$ gzip -dc /proc/config.gz | grep "_64"
CONFIG_X86_64=y
CONFIG_64BIT=y
r00t@r00t:~$ cat ./test.c
#include <time.h>
int main(void)
{
printf("INT=%i\nLONGINT=%i\nTIME_T=%i\n",sizeof(int),sizeof(long int),sizeof(time_t));
return(0);
}
r00t@r00t:~$ gcc ./test.c -o ./test
r00t@r00t:~$ ./test
INT=4
LONGINT=8
TIME_T=8

Та же прога, но на 32 битном линуксе:
[root@freehost r00t]# gcc ./test.c -o test
[root@freehost r00t]# ./test
INT=4
LONGINT=4
TIME_T=4

Дальше:
r00t@r00t:~$ echo `php -r 'echo date("r", 315507352769999);'`
Fri, 31 Dec 9999999 23:59:59 +031
но:
[root@freehost r00t]# echo `php -r 'echo date("r", 315507352769999);'`
Tue, 23 Jan 1940 15:10:39 -0600