Помогите пожалуйста найти заголовочные файлы

[rpomov]

Друзья!
То есть имеется файл-сырец, правильность которого не вызывает сомнений. Это файл cp.c, "родной" для моей оси, скачанный из репозитария. Именно после его компиляции разработчиками был получен ./a.out, переименованный просто в "cp" и ккинутый в папку */bin, коим я (и все мы) благополучно пользуемся. И мне хотелось бы его подправить. Но для начала  я решил прсто компильнуть уже имеющийся ПРАВИЛЬНЫЙ сырец.

То есть мне по скачиванию пакета coreutils оставалась распаковать его, найти в одной из его папок cp.c и набрать в терминале

Код: [Выделить]

gcc сp.c
Что я и сделал, получив добрую сотню ошибок и предупреждений.
Начал я анализ с самого начала. Ребята, перво-наперво компилятор не видит заголовочные файлы. Ну, например, объявленные так:

Код: [Выделить]

#include <config.h>
#include <selinux/selinux.h>
А серьёзно если- это полный улёт. Я лаптем щи хлебаю, а себе такой расхлябанности не позволяю и всегда кладу свои заголовочные файлы либо в одну папку с тем, где находится main (), либо (раньше я так делал) писал полные пути к файлам.

...А эти-то где искать? Поиск по компу файла, например, config.h выдал их много. Какой из них? Да и вообще в свете недавних событий я совневаюсь, что действительно нужный config.h находится у меня в оси. В общем, поиски корректных сырцов, интенсивно продолжаются. Спасибо.

[Yurror]

rpomov, ты бы не кипятился а попробовал понять процессы разработки под *nix системы
конфиг для каждого пакета генерится динамически когда выполняется ./configure в корневом каталоге пакета
selinux/selinux.h видимо лежит в пакете libselinux-dev

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

Попробуй чтоли почитать вообще про разработку на платформе *nix. Многое прояснится.

А твой "полный улет" только рвотный рефлекс вызывает.
Не стоит вваливаться в чужой монастырь размахивая собственным уставом.
Лучше иди дальше щи хлебать пока уму разума не нахлебаешься.

[wl]

http://en.wikipedia.org/wiki/GNU_build_system
http://www.amath.washington.edu/~lf/tutorials/autoconf/toolsmanual.html
http://www.gnu.org/prep/standards/
http://www.gnu.org/software/hello/manual/
http://www.gnu.org/software/automake/manual/index.html

[rpomov]

wi, спасибо, конечно, но мне нужно просто знать- где назодятся заголовочные файлы? Как я ими распоряжусь- это моё дело. Но дайте посмотреть иходники!
Должно же быть какое-то ПРОСТОЕ правило, типа (как вариант всего лишь):
путь к заголовочным файлам исходника такого-то определяет переменная, находящаяся в таком-то файле.
Тогда я открываю этот файл, нахожу эту переменую и... дальше мои дела уже.
И больше мне ничего не надо. Если ты не знаешь, или тебе неохота отвечать- это твоё дело.

Неужели так сложно понять вопрос?

[Mam(O)n]

rpomov, кури интернеты про makefile и про configure скрипты. Заголовочный файл config.h создаётся после выполнения скрипта конфигурирования ПО для конкретной системы.

[Yurror]

wl, там же все по английски и ни слова как скомпилировать cp.c, ну тоесть совсем не в тему! =)

rpomov, выпоняешь командочку
sudo aptitude install libselinux-dev
и, о чудо, нужные заголовочные файлы найдены! (не все правда но это уже не лечится)

Предвижу следующий пост rpomov

афигеть! как сложно, нифига не понятно, нету setup.exe как я делал буквально вчира в Windowsвсе.
убить всех линуксоидов, в них нет ни чего святого. и все не как у людей!
уйду от вас. искать исходные тексты copy.c и dir.c они собирутся моим Borland Turbo C++ без вопросов одним нажатием кнопочки F8

Так и быть, открою тебе правило "путь к заголовочным файлам" определяется настройками компилятора. Кстати довольно простое правило.
Вот некоторые из этих путей (для моего компилятора, у тебя могут быть другими)

Код: [Выделить]

/usr/include
/usr/local/include
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/lib/gcc/i486-linux-gnu/4.2.4/include
Не понятно что ты будешь дальше с этим делать. файла config.h там не будет. а если и будет то совсем не тот что нужен.

P.S. кстати вопрос понятен. мы уже все дипломированные телепаты (без шуток) и подобные душеизлияния умеем понимать. тебе дали впоне разумные рекомендации как справиться с проблемой, однако пациент сопротивляется лечению

[rpomov]

wl. Mam(O)n я обескуражен немного. Первую ссылку я ослил. И даже вот эту
http://en.wikipedia.org/wiki/Configure_%28computing%29
осилил. Далее не стал. Спасибо за заботу, но разве стоило читать их, чтобы увидеть, что иначе чем
./configure && make && make install

с пакетами работать нельзя? Я бы поверил и вам и русскоязычному ресурсу.
...Но как бы то ни было, я продвинулся дальше. Ведь заголовочные файлы нужны были мне не сами по себе- без них не происходила компиляция. А, следовательно, я не мог поправить ни один из исходников! (хотя бы для пробы. А так мне кое-что хотелось бы изменить в cp.c) Ребята сказали делать так:
сперва ./configure (как и Вы советовали, Mam(O)n)
...Ну, и собсно, config.h появится и можно компилить.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...Кстати, странно, что никто не обратил внимание на то, что команда gcc cp.c нелепа донельзя! И я не знал, ведь она может выполняться много сложнее, (gcc <опции> <файлы>). Как именно- надо разбираться с make. (Но это совсем другой вопрос) Опыта ручной компиляци совсем нет у меня (кроме как gcc <имя_файла>), я в DEV C++ 4.9.9.2 работал, там всё это дело автоматизировано. Теперь хоть знать буду. Спасибо.

 

[Mam(O)n]

На заметку:
В дебиановской пакетной системе, чтобы что-либо поправить в исходных кодах, минимальные действия можно провернуть такие:
1. apt-get source имя_пакета   # Качаются исходники
2. sudo apt-get build-dep имя_пакета  # Качаются зависимые пакеты, необходимые для сборки
3. поправить исходник (также можно просто закинуть патчи в debian/patches и если есть, то добавить их имена в индексный файл)
3.1. Необязательно, но можно попробовать собрать ./configure && make и испытать бинарники.
(make install не наш метод!!!)
5. добавить в debian/changelog изменения и номер новой версии
6. dpkg-buildpackage
7. ...
8. На уровень выше имеем собранные .deb пакеты.

Спасибо за заботу, но разве стоило читать их, чтобы увидеть, что иначе чем ./configure && make && make install с пакетами работать нельзя? Я бы поверил и вам и русскоязычному ресурсу.

Стоило. Если не знать истоков, то можно запутаться в дальнейшем.

[ArcFi]

осилил. Далее не стал. Спасибо за заботу, но разве стоило читать их, чтобы увидеть, что иначе чем
./configure && make && make install
с пакетами работать нельзя?

Как раз наоборот. Так в пакетном дистрибутиве работать не рекомендуется.

[wl]

осилил. Далее не стал. Спасибо за заботу, но разве стоило читать их, чтобы увидеть, что иначе чем
./configure && make && make install
с пакетами работать нельзя? Я бы поверил и вам и русскоязычному ресурсу.

Виноват, промашка вышла. Я сжег свой диплом телепата и посыпаю голову его пеплом.

...Кстати, странно, что никто не обратил внимание на то, что команда gcc cp.c нелепа донельзя! И я не знал, ведь она может выполняться много сложнее, (gcc <опции> <файлы>).

И за это - тоже.

Как именно- надо разбираться с make.

Нет, надо ознакомиться, хотя бы бегло, с man gcc
Кстати, мануальные страницы можно просматривать в обычной Гномьей системе справки (System -> Help and Support), а Krusader понимает протокол "man:/", т.е. ему можно ввести адрес man:/gcc и тоже с удобством почитать.

Пользователь решил продолжить мысль 26 Января 2010, 11:11:26:

осилил. Далее не стал. Спасибо за заботу, но разве стоило читать их, чтобы увидеть, что иначе чем
./configure && make && make install
с пакетами работать нельзя?

Как раз наоборот. Так в пакетном дистрибутиве работать не рекомендуется.

Обратно наоборот. Я дал те ссылки для того, чтобы человек получил представление о GNU Build System (automake, autoconf, и т.п.)
Про пакетный дистрибутив - следующий вопрос.
Отвечаю.
Если бесконтрольно устанавливать программы путем скачивания исходников и применения заклинания ./configure && make && make install, то в системе довольно скоро образуется бардак. В босоногом детстве я неоднократно попадал в ситуации, когда разным устанавливаемым программам требовались разные версии одной и той же библиотеки. Или библиотеку требовалось компилировать с разными ключами у configure.
Потом, требовалось запоминать, что, когда и куда я поставил (/usr или /usr/local или вообще /opt), т.к. винчестер был маленький, и стирать ненужное руками.

Для контроля и унификации установки пакетов есть специальные менеджеры - Deb, RPM, Slackware-вский и т.п. Они ведут каталог - что и куда поставлено, какие файлы куда скопированы.
Потом появились надстройки над ними - APT, YUM, YaST и т.п., которые автоматически контролируют зависимости между пакетами и разрешают конфликты.

[rpomov]

Как раз наоборот. Так в пакетном дистрибутиве работать не рекомендуется.

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

Глупое высказывание, кторого Вы дождались:
Извольте объясниться. Тут вот написано, что так и надо работать.  
http://en.wikipedia.org/wiki/Configure_%28computing%29

...Если Вы имеете ввиду, что прежде надо прочесть README, так и скажите.
...ОТвет получен от wi

И что делать-то? Я услышал от вас пожелание изучить вспомогательные проги Deb, RPM, Slackware-вский чего-то там, APT, YUM, YEST Э... простите, и как долго мне всё это изучать?

Работу-то когда работать? Когда смотреть фильмы, слушать музыку, общаться с людьми, лазить в инете..? Решать задачки по информатике, в конце концов? Если сравнивать с некоторыми другими плохими осями- там к этому можно приступить довольно скоро- проги быстрее, я имею ввиду, устанавливаются, без изучения подобных штук. Извините.
 

[ArcFi]

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

Как перечисленное связано с сабжем, позвольте полюбопытствовать?

[wl]

Извольте объясниться. Тут вот написано, что так и надо работать.  
http://en.wikipedia.org/wiki/Configure_%28computing%29

Последняя мантра "make install" лишняя Она хороша для системы, свободной от пакетных менеджеров.
После ./configure && make имеем собранные исполняемые файлы в текущем каталоге.

И что делать-то? Я услышал от вас пожелание изучить вспомогательные проги Deb, RPM, Slackware-вский чего-то там, APT, YUM, YEST Э... простите, и как долго мне всё это изучать?

Вот странно. А я его не высказывал. Это был исторический экскурс, поясняющий откуда пошли пакеты. Для Ubuntu достаточно уметь тыкать мышкой в Synaptic или Software Center и знать про существование deb и apt.

Работу-то когда работать? Когда смотреть фильмы, слушать музыку, общаться с людьми, лазить в инете..? Решать задачки по информатике, в конце концов? Если сравнивать с некоторыми другими плохими осями- там к этому можно приступить довольно скоро- проги быстрее, я имею ввиду, устанавливаются, без изучения подобных штук. Извините.

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

[rpomov]

Никак.
Вопрос решён, тему можно к закрытию. Пока не закрыли, позволю сеье немного поофтопить.

[Mam(O)n]

Я попросил бы не говорить загадками

Конкретно - на пакетных дистрибутивах командой make install не стоит пользоваться. Она делает своё грязное дело сродни setup.exe в венде. Т.е. по своему алгоритму раскидает свои файлы, без учёта спецификаций и стандартов дистрибутива, и возможно, затем потеряет половину из них. Такое ПО не управляется через пакетный менеджер и может конфликтовать, либо быть затёрто, например при обновлении системы или установке какого-либо нового софта.

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

Адаптированное ПО (точнее оригинал+патчи адаптации), исходники которого лежат в репозитории убунты, можно собрать в пакет одной командой. Я выше писал.