Здравствуйте. Я тут новичок, решил посмотреть в каком состоянии ваша ОС. Впечатления в целом положительные. Интересно, можно ли туда перенести программы на C?
viewtopic.php?f=9&t=480
http://diamond.kolibrios.org/
Смотрел по ссылкам выше. То, что там предлагают использовать (menuetlibc) содержит неправильный Makefile (я пробовал BSD make и GNU make - результат 1 - Line 4: missing dependency operator). Собрать не получается. Есть ли пофиксенная версия?
И ещё, если я сам пофиксю, и скомпилирую какую-нибудь прогу с помощью gcc и этой библиотеки, то как сделать его исполняемым в KolibriOS? В плане, понимает ли она ELF формат?
Вопрос о C
Всё там собирается GNU-тым make. Если дефолтный make - BSDшный, позаботьтесь о замене команды make на путь к правильному бинарнику везде. Переменная окружения MENUETDEV установлена?
Колибри не понимает ELF-формат, одной из целей системы сборки в menuetlibc является сборка бинарников в нужном формате.
Колибри не понимает ELF-формат, одной из целей системы сборки в menuetlibc является сборка бинарников в нужном формате.
даdiamond wrote:Переменная окружения MENUETDEV установлена?
Достаточно использовать gmakediamond wrote:Всё там собирается GNU-тым make. Если дефолтный make - BSDшный, позаботьтесь о замене команды make на путь к правильному бинарнику везде.
Ясно, спасибо.diamond wrote:Колибри не понимает ELF-формат, одной из целей системы сборки в menuetlibc является сборка бинарников в нужном формате.
Таки нет) Ну ладно, я вручную соберу)diamond wrote:Всё там собирается GNU-тым make.
Вы Makefile глазами смотрели? Что он внутри себя make (а вовсе не gmake) вызывает для вложенных папок, видели?Достаточно использовать gmake
Какую библиотеку лучше использовать? Menuetlibc или newlib?
to infinity and beyond
punk_joker
В новой newlib нативная поддержка PE DLL с автоматической линковкой.
Но привязка жесткая к mingw32.
В новой newlib нативная поддержка PE DLL с автоматической линковкой.
Но привязка жесткая к mingw32.
Описание к сисфункции:
раньше я использовал dword и проверял его биты, сейчас я решил разложить его на биты в самой структре;
Почему-то не работает, что я делаю не так?
Code: Select all
Структура блока данных входа каталога (БДВК):
* +0: dword: атрибуты файла:
* бит 0 (маска 1): файл только для чтения
* бит 1 (маска 2): файл является скрытым
* бит 2 (маска 4): файл является системным
* бит 3 (маска 8): это не файл, а метка тома
(на заданном разделе встречается не более одного раза и
только в корневой папке)
* бит 4 (маска 0x10): это папка
* бит 5 (маска 0x20): файл не архивировался - многие программы
архивации имеют опцию, по которой архивируются только файлы
с установленным этим битом, после чего этот бит сбрасывается -
это может быть полезно для автоматического создания
backup-архивов, ибо при записи бит обычно устанавливается
(не в Kolibri, правда)
Code: Select all
dword readonly:1, hidden:1, system:1, volume_label:1, isfolder:1, notarchived:1;
Из хаоса в космос
Может в этом дело:Leency wrote:Почему-то не работает, что я делаю не так?Code: Select all
dword readonly:1, hidden:1, system:1, volume_label:1, isfolder:1, notarchived:1;
"Битовые поля имеют тип unsigned int, так как имеют длину один бит. Если длина поля больше одного бита, то поле может иметь и знаковый целый тип.
http://learnc.info/c/unions_and_bitfields.html"
Не, я перечитал документацию к С-- и нашёл проблему!!! Спасибо Диме за наводку!
Дело в выравнивании http://c--sphinx.narod.ru/c--doc.htm#8.1.8
Правильно так:
Дело в выравнивании http://c--sphinx.narod.ru/c--doc.htm#8.1.8
Правильно так:
Code: Select all
dword readonly:1, hidden:1, system:1, volume_label:1, isfolder:1, notarchived:1, :0;
Из хаоса в космос
чисто мое имхо, но я бы не использовал битовые поля в этой ситуации.
не сказал бы что я крутой спец, но толку тут я особо не вижу:
- более чем уверен что в памяти оно все-равно будет храниться как dword
- если не будет храниться как dword, процессор потратит больше времени на переваривание битового поля, если оно не кратно размеру слова + выравнивание
- переносимость в платформах битовых полей всегда хуже
- [х] да и не нравится оно мне, как-то оно не по сишному выглядит
не сказал бы что я крутой спец, но толку тут я особо не вижу:
- более чем уверен что в памяти оно все-равно будет храниться как dword
- если не будет храниться как dword, процессор потратит больше времени на переваривание битового поля, если оно не кратно размеру слова + выравнивание
- переносимость в платформах битовых полей всегда хуже
- [х] да и не нравится оно мне, как-то оно не по сишному выглядит
Я правильно понял, относительные пути к файлам в newlib не поддерживаются? Есть какой-нить костыль для обхода?
Ну, или, есть ли какой-нибудь способ узнать путь к программе, которая запущена? getwd не работает. Пишет undefined reference to getwd.
menuet-libc умеет то, что я хочу?
Заранее спасибо.
Ну, или, есть ли какой-нибудь способ узнать путь к программе, которая запущена? getwd не работает. Пишет undefined reference to getwd.
menuet-libc умеет то, что я хочу?
Заранее спасибо.
Относительные пути поддерживаются. Проблема в том, что не все файловые менеджеры меняют текущий каталог при перемещении по дереву каталогов. Shell меняет.
Каталог из которого запущена программа определяется традиционно через argv[0]
Текущий рабочий каталог
Каталог из которого запущена программа определяется традиционно через argv[0]
Текущий рабочий каталог
Code: Select all
char *getcwd(char *buf, size_t size)
{
int bsize;
__asm__ __volatile__(
"int $0x40"
:"=a"(bsize)
:"a"(30),"b"(2),"c"(buf), "d"(size)
:"memory");
return buf;
};
Что лучше использовать для портирования новых программ на С? Menuetlibc или Newlib? И можно ли обойтись вообще без них? Хотелось бы просто собрать avra под Колибри, но требование обязательного наличия newlib как то смущает.
to infinity and beyond
Что такое avra ?
http://avra.sourceforge.net/README.html я полагаю
Who is online
Users browsing this forum: No registered users and 1 guest