LINUX.ORG.RU

Подключить SDL_draw.h

 ,


0

1

Здравствуйте!

Возникла у меня проблема с подключением библиотеки SDL_draw при написании программ на Си под Linux. Перерыл в интернете всё что только можно и не нашёл описания как решить эту проблему. Поэтому прошу помощи и вразумления.

Использую на нескольких компьютерах Linux Mint Cinnamon 17.2 x64 Для программирования на Си использую редактор vim и компилятор gcc

Если честно, то с Си я тоже только ещё разбираюсь, ничего приличного пока не успел сделать.

С SDL я только только пытаюсь разбираться. Для одной конкретной и не сложной задачи мне нужно использовать рисование примитивов: точки, линии, окружности. Решил использовать библиотеку SDL_draw.

В репозитории дистрибутива такой библиотеки не было. Я установил до кучи все libsdl* , но это не помогло.

Я нашёл ссылку и скачал исходники с ( sdl-draw . sourceforge . net ) файл SDL_draw-1.2.13.tar.gz

Распаковал

Выполнил по инструкции:

sudo ./configure
sudo make
sudo make install

В итоге в /usr/local/lib были созданы библиотеки libSDL_draw.a и libSDL_draw.so

Вопрос теперь только в том как подключать эту библиотеку в программе на Си.

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

Например:

#include <SDL/SDL.h>
#include <SDL/SDL_draw.h>

или как вдругом источнике:

#include <SDL_draw.h>

При попытке скомпилировать ругается на отсутствие файла SDL_draw.h

При этом SDL/SDL.h прекрасно подключается, так же как и другие библиотеки установленные из репозитория.

У меня возникло подозрение, что проблема просто в том, что где-то в системе не прописан путь к библиотекам.

Все остальные SDL библиотеки, установленные из репозитория, лежат в папке /usr/lib/x86_64-linux-gnu/

А установленные вручную, как я уже написал, в /usr/local/lib

Я пробовал создавать символьные и жёсткие ссылки, размещая их в /usr/lib/x86_64-linux-gnu/ Пробовал просто копировать файлы туда

Нашёл описание в файле /etc/ld.so.conf ссылку на папку с конфигами /etc/ld.so.conf.d/*.conf

Там нашёл файл x86_64-linux-gnu.conf

Его содержимое:

# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

Я добавил туда строку: /usr/local/lib

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

Я добавил файл local.conf, куда вынес последнюю строчку и удалил её из файла x86_64-linux-gnu.conf

Ещё я временно добавлял /usr/local/lib в переменную PATH (на всякий случай, для эксперимента, хотя он там и не должен быть)

Это тоже ничем не помогло.

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

Что же мне ещё сделать? У меня уже фантазия кончилась

Чувствую себя полным идиотом из-за того что не могу пока разобраться с этой проблемой.

PS: Ещё что-то читал про libtool, но пока как-то стрёмно туда соваться не разобравшись нормально. Пока все мои эксперименты носили обратимый характер. Не хочется чего-то запороть по своему скудоумию.

PPS: Да, ещё забыл сказать, что как вариант я рассматривал ещё изменение файла configure, ведь именно в нём прописан путь, куда ставятся библиотеки. Но посмотрев на этот файл, я решил, пока его тоже не трогать, т.к. некоторые настройки там мне не очевидны.

PPPS: Ещё могу сказать в своё оправдание, что свободного времени когда я могу с чем-то разбираться у меня суммарно всего несколько часов в неделю и приходится всё делать урывками. Поэтому такой сумбур.


1. Не стоит использовать sdl_draw, лучше обратите свой взор на http://open.gl

2. Компилятору нужно знать, где искать интересующий хедер. Из мана:
-I <value> Add directory to include search path

andreyu ★★★★★ ()

Что же мне ещё сделать?

Скопировать include/SDL_draw.h в /usr/local/include. Там не прописана установка заголовка при make install.

xaizek ★★★★★ ()

Зачем в систему добавлять, если можно в каталог проекта, особенно на первых порах? Тем более это такой жуткий депрекейтед. А свои будущих пользователей тоже будешь заставлять скачивать говно мамонта с сорцфорджа и делать make install? Просто заставляй компилятор собирать с нужными либами и хидерами в мейкфайле. Зачем тащить в систему?

wakuwaku ★★★★ ()
Ответ на: комментарий от xaizek

Скопировать include/SDL_draw.h в /usr/local/include.

Попробовал, не помогло.

В конце концов кинул SDL_draw.h и SDL_draw.a в папку проекта.

Стал ругаться на отсутствие SDL.h хотя раньше вроде не ругался.

Будет время поковыряюсь ещё.

Hemulo ()
Ответ на: комментарий от wakuwaku

Ну у меня специфическая задача.

Мне нужно для школы поставить на нескольких компах для изучения программирования и рисования примитивов и графиков вместо graphics.h

Поэтому актуальность библиотеки или переносимость не так важна, важна простота и работоспособность, а также лёгкость компиляции и минимум лишних файлов.

Т.е. именно хочется избежать таскание файлов в каждую папку каждого проекта.

Кроме того, я сам предпочитаю редактор vim и компиляцию из консоли, а школьники, вероятней всего, будут пользоваться редактор Geany или чем-то подобным.

Преподаватель, который будет работать со школьниками знает Си (в той мере, в которой это необходимо), но не знает Linux и вообще далёк от этого. Привык работать с библиотекой graphics.h

Я должен обеспечить по возможности наиболее лёгкую адаптацию и переход под Linux.

В прошлые годы я использовал для обучения программированию FreeBASIC - там проблем с графикой не было. Но по разным причинам, не связанным со мной, с этого года нужно переходить на Си.

Как вариант - FreePascal, но во-первых, он мне не нравится, во-вторых второй преподаватель сишник, а не паскалист и там всё равно будут сложности с адаптацией, ну и в-третьих, я сам хочу углубить свои знания Си (например, хочу переписать несколько своих обучающих программ написанных ранее с FreeBASIC на Си).

Hemulo ()
Ответ на: комментарий от Hemulo

Похоже расчитано, что залоговок будет лежать в /usr/include/SDL/. Ну либо подправить в нём include на #include <SDL/SDL.h>.

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

Да, спасибо.

Там ещё есть #include «begin_code.h» и #include «close_code.h»

на который ругается компилятор.

Я исправил на

#include «SDL/begin_code.h» и #include «SDL/close_code.h»

Вроде перестало ругаться.

Позже, когда будет время, попробую использовать вызовы функций.

Hemulo ()
Ответ на: комментарий от Hemulo

pkg-config --cflags --libs sdl или sdl-config --cflags --libs, если файлы лежат в каталоге проекта, то вручную -D_GNU_SOURCE=1 -D_REENTRANT -I../include/SDL, и -lpthread -L../libs/sdl -lSDL линкеру. Но заставлять других людей учить то, что им совершенно точно никогда не пригодится в реальной жизни — довольно порочная практика. Бейскик сам сам по себе бесполезный и неактуальный и все это понимают, поэтому с ним проще (можно учить чему угодно, особого вреда не будет).

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

Ну, про бейсик - я не согласен. Есть вполне приличные бейсики, например FreeBASIC или PureBASIC (правда он не свободный).

Просто у них своя область применения.

А что касается изучения графических библиотек, не используемых в реальной жизни, то это не особая проблема.

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

Выбор между Бейсиком, Паскалем и Си обусловлен исключительно их применением при сдаче ЕГЭ и использованием на школьных олимпиадах.

На каком-нибудь Python, Java или Lua ни ЕГЭ, ни олимпиаду написать нельзя.

Лично мне нравился FreeBASIC, потому, что он позволял без заморочек писать небольшие и вполне практичные программки.

Он кстати полностью совместим с Си, может использовать сишные библиотеки, создавать объектные файлы и линковать их с сишными объектными файлами.

В каком-то смысле, компилятор fbc - это надстройка над gcc.

Кроме того, мне не нравится Паскаль, хотя его я, наверное, знаю несколько лучше чем бейсик. Просто он мне кажется совершенно непрактичным языком. В отличие даже от современных версий бейсика.

А с Си просто так сложилось, что я хочу сам его поглубже узнать (причём не C++, а именно Си) для своих практических целей. Плюс ещё второй препод предпочитает Cи/С++ вместо паскаля.

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

Для остальных совершенно без разницы какой язык программирования изучать. Хоть марсианский.

Базовые понятия которые они смогут запомнить во всех процедурных языках подобны, а ничего сложнее они и не будут воспринимать.

Да, графика, в принципе даже не обязательна. Она просто позволяет немного разнообразить учебные задания и делать их не такими скучными, как кажутся большинству. Ну и кроме рисования простых объектов ещё полезна возможность рисования математических графиков.

Hemulo ()
Ответ на: комментарий от Hemulo

Проблема не только в устаревших графических библиотеках, проблема в SDL. Уже давно используется SDL2, первая ветка SDL уже несколько совершенно неактуальна. Изучение особенностей 1 ветки требует вполне реального времени, которое в итоге окажется совсем непродуктивно потраченным.

Касательно васика: писать на нём неформошлёпные приложения — приключение ещё то. Насколько я помню (по vb6 и vb8), у этого языка целый ряд особенностей, невыгодно отличающих его от нормальных языков. Да, он весьма прост в освоении, но реализовать на нём сложную логику может быть довольно нетривиально и выглядеть она будет не лучшим образом.

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

А в SDL2 есть что-то аналогичное SDL_draw, чтобы можно было просто рисовать линии, точки, эллипсы и прямоугольники?

Вот, например что представляет из себя SDL_gfx ? Я пока не нашёл там описания работы с примитивами.

А по поводу Бейсика. Вижил Бейсик не совсем бейсик.

Кстати, современные бейсики сильно отличаются от старых классических. Фактически там от бейсика остался только синтаксис.

В остальном FreeBASIC - надстройка над GCC, а PureBASIC - это высокоуровневое расширение FASM.

На FreeBASIC я, кстати, не писал оконных приложений, только консольные плюс графика.

И уж во всяком случае, эти современные бейсики лучше чем замороженный в своём развитии паскаль.

Про сложную логику судить не могу, но в какой-то области бейсик может вполне быть приемлем.

Кстати, как это ни странно может показаться, но изучение старого классического Бейсика очень полезно для начала изучения Ассемблера. Столкнулся с этим, когда пытался какому-то чужому студенту объяснить работу программ на ассемблере.

Hemulo ()
Ответ на: комментарий от Hemulo

Юзай sdl2, для графических примитивов в связке с OpenGL. SDL в первую очередь нужен для звука, загрузки текстур, сети, шрифтов и прочего, напрямую не связанного с графикой (ну и 2D можно использовать).

peregrine ★★★★★ ()

А мне Allegro5 нравится. Она проще, быстрее и с прекрасной документацией. И там всё есть.

anonymous ()

Ещё актуально?

Есть классная библиотека под линуксом для работы с 2д графикой — imlib2. Хоть она и старая, но вполне рабочая. Очень простая. Есть рисование линий, прямоугольников, полигонов, эллипсов, простые трансформации, загрузка и сохранение изображений разных форматов, включая PNG с прозрачками, JPG и TIFF, работа со шрифтами и даже блюр.

C SDL(2) можно использовать посредством

#include <SDL/SDL.h>
#include <Imlib2.h>
#include <stdint.h>
...

Imlib_Image image = imlib_load_image("image.png");

imlib_context_set_image(image);

int w = imlib_image_get_width();
int h = imlib_image_get_height();

uint32_t * data = imlib_image_get_data();

SDL_Surface * surf = SDL_CreateRGBSurfaceFrom(data, w, h, 32, w*4, 0xff0000, 0xff00, 0xff, 0xff000000);
...

Компилить можно так:

gcc -lSDLmain -lSDL -lImlib2 myprog.c

Устанавливать библиотеки проще из репозиториев. А для школоты, наверное, лучше написать какой-нибудь враппер, чтоб не смущать их лишними подробностями на первых порах.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.