Board.KolibriOS.org

turbocat wrote:

ArenElchinyan wrote:У меня русский язык в консоли не получается включить.
Кто может помочь?

Нужно использовать cp866, при сохранение исходников.

Спасибо!
Я уже решил проблему. Еще с OEM866 работает

Привет!
Начальная версия поддерки автозагрузки библиотек для tcc, для тестирования в Windows (см. прикрепленный архив).
В качестве информации по импорту библиотек используются def файлы. Да, да, сложные lib файлы для линковки теперь тоже больше не нужны.
Def файлы можно создавать самостоятельно пока вручную (образец в архиве), либо написать в дальнейшем отдельную тулзу
clayer (не совсем понял где он живет), который дублирует библиотеки из /sys/lib/ теперь не нужен, соответственно, вызовы типа networklib_init() (в примерах они закомментированы) также не нужны, т.к. dll.obj делает связывания с библиотеками из /sys/lib/, а также вызывает их функции инициализации.
Прочие автозагрузчики тоже не нужны.

Пример использования (стандартно, дополнительно см. справку в tcc):
tcc Путь_к_папке_\samples\файл_исходника.c -I Путь_к_папке_\include LПуть_к_папке_\lib -llibc -lnetwork [lпрочая_используемая_библиотека]

Для работы обязательно требуется lib\start.o (в архиве), это немного модицицирвоанная версия crt0.asm из библиотеки libc.obj для распознания библиотекой dll.obj

Ограничения:
1. memcpy и т.п. встроенные функции не умеет генерировать или я пока не разобрался как это сделать.
например, для теста string_test.c и whois.c в архиве есть файл memcpy.c (в последних версиях в libc.obj memcpy отсутствует, по этой
же причине в файле libc.def эту функцию надо закомментировать).
2. Могут быть конфликты имен разных библиотек, т.к., например, функция get есть как в libc.obj, так и в http.obj

Функции такие как memcpy, memmove, находятся в libtcc. Достаточно просто прилинковать -ltcc.

Пора я думаю на SVN сделать бранч. И там уже работать. Потому что хочется видеть код.

Залил на svn, но версия пока собирается старая. Новая будет собиратсья когда будет сделана адаптация для (временной) совместимости. В архиве прикрепляю свежую сборку для Windows и Kolibri. Можно также попробовать собрать версию для Linux, для этого надо в конфиге для препроцессора заменить TCC_TARGET_MEOS на TCC_TARGET_KX.

Замечание по тестированию: необходимо использовать версию libc.obj из архива, т.к. в новой версии удалены некоторые функции (например, memcpy)

Также потестируйте страрую версию tcc, которая собирается в дистрибутив.

Опа сишка, но я по паскалю. Попробую завтра что-то написать

Привет!
Поясните по libck. Заново собираю библиотеку, скармливаю ее tcc и получаю С уже собранной библиотекой отсюда SVN\programs\develop\ktcc\trunk\bin\lib такой проблемы нет.

Функция __assert_func объявлена в заголовке assert.h и больше нигде не упоминается, также как и __trace_func.

По умолчанию все assert становятся __assert_func, лечится только дефайном NDEBUG. Что я делаю не так?

Coldy wrote:Поясните по libck.

libck is deprecated. Use libc.obj instead.

Я не использую libck, но его используют некоторые программы, которые собираются с помощью tcc, например, teatool. Я сейчас собираю все эти программы, чтобы их можно было в дальнейшем использовать с автозагрузкой через dll.obj, которая уже поддерживается tcc. В связи с этим и возник вопрос.

Привет!
Во вложении последняя сборка tcc-kx (версия для Kolibri) + все собранные приложения, которые сейчас собираются (в автосборке) с помощью tcc, но с использованием автозагрузки и автосвязывания импортов через dll.obj. Все эти программы уменьшились в размере, т.к. теперь в них отсутствует код загрузчика и часть кода, которая связывала приложение с clayer.
В файле /3rd_party/Programs.txt приведено сравнение размеров.
Отмечу, что teatool и tinybasic используют статическую библиотеку libck.a, а TinyHashView также статическую libcryptal.a. При переводе этих приложений на динамические библиотеки размер этих приложений дополнительно уменьшится.
В папке /tcc/kx/doc имеется руководство (большая часть только на русском) и описание новых возможностей tcc
Для самостоятельной сборки может потребоваться корерктировка путей в файлах build.sh в каждом проекте, если пути будут отличны от следующих:

/fd2/1/ - директория всех файлов, кроме библиотеки kos_mbedtls, для нее была использована директория /cd2/1/libraries.

Примечание: если будет использваться дискета, то может потребоваться только частичная запись на нее проектов, т.к. не все умещается.

В проектах были сделаны корректировки, связанные с отклчюением clayer.
В библитеке libc были сделаны корректировки для исклчюения когда загрузчика (т.к. она устарела - детально описывать не буду).
В заголовочных файлах библиотек были произведены изменения для того чтобы:
1) не зависить от clayer (/3rd_party/libc.obj/include/clayer)
2) вызов функций из библиотек был по указателю (/3rd_party/kos_mbedtls/include/mbedtls)

Эти изменения не являются полными и конечными, а служат пока только для того чтобы успешно собирать вышеописанные приложения. По п. 1 все корректировки оформлены с уловной компиляцией типа По п. 2 добавлено определение и все вызовы из kos_mbedtls оформлены по примеру ниже
В дельнейшем планируется научить tcc понимать аттрибуты dllimport/dllexport.
Тогда можно будет делать объявления так:


В этом случае размер приложения еще дполнительно сократится.

Привет! Ты проделал огромную работу! Ты можешь сделать чтобы libtcc и libc линковались сами? Я глунул tcc.conf ... А зачем такие извращения если есть переменные среды. Типа TCC_DIR=абоба tcc main.c -o main -ltcc -lc

Coldy wrote:Я не использую libck, но его используют некоторые программы, которые собираются с помощью tcc, например, teatool. Я сейчас собираю все эти программы, чтобы их можно было в дальнейшем использовать с автозагрузкой через dll.obj, которая уже поддерживается tcc. В связи с этим и возник вопрос.

Проблема была в том что ты юзал хедеры от libc.obj. libck в ближайшее время будет убрана.

А исходники ты выложил? раз tcc уже работает, значит его можно закинуть на сервак.

Ты можешь сделать чтобы libtcc и libc линковались сами?

нет, 1) не все приложения используют (или будут использовать) эти библиотеки и 2) libtcc вообще костыльная на данный момент, по крайней мере то, что касается memcpy, memmove и т.п. которым в ней не место. По умолчанию нужно подключать как можно меньше кода.

есть переменные среды. Типа TCC_DIR=абоба

Ты говоришь про переменные среды tup. Но в Kolibri на данный момент нет переменных среды и getenv возвращает ноль, putenv просто заглушка, execve вообще не реализована. Тема отдельной разработки если такое будет нужно

ты юзал хедеры от libc.obj

Нет, хэдеры использовал libck.

А исходники ты выложил? раз tcc уже работает, значит его можно закинуть на сервак.

Пока не выкладывал, в текущей версии есть баг, который я пока не закрыл - если прописать def, который не будет использоваться, то tcc падает (т.е. если указывать только используемые бибилиотеки то все нормально). Может еще какие проблемы вылезут - тестируйте.

нет, 1) не все приложения используют (или будут использовать) эти библиотеки и 2) libtcc вообще костыльная на данный момент, по крайней мере то, что касается memcpy, memmove и т.п. которым в ней не место. По умолчанию нужно подключать как можно меньше кода.

Почему нет? libck больше не будет. С libtcc всё и так понятно сорок раз обсуждали. Для того чтобы отключить libc всегда можно заюзать -nostdlib как у всех нормальных компиляторов.