Make не работает
Хотел скомпилировать c код, root есть, командой cd попал в эту папку, проверил есть ли там Makefile, потом набрал make, и мне говорят, что его там нету. Как. Я же сам проверял. ./configure тоже не работает, что делать?
make у тебя работает, попутно твой make от тебя же дуреет, ты хоть читай иногда выхлоп команды, которую запускаешь.
Я новичок, что там не так?
Я же в папке со всеми файлами и ввел все правильно вроде
новичок — это я, а ты или скучающий толстячок, или невменяемый школьник. выбор за тобою.
Makefile.in это не то же самое, что Makefile. Это только заготовка для генерации Makefile. Генерируется он обычно скриптом configure, но у тебя среди файлов почему-то его нет.
Не оскорбляй, я не школьник, просто надо срочно скомпилировать, а я в linux не разбираюсь из-за сложных ошибок
надо — компилируй, хотя, емнип, ты ж сам на каждом углу кричал, что твоя убунта у тебя урезана по самое немогу, а тут внезапно на ней, как минимум, дев-пакеты образовались и компилятор.
Я нашёл configure и configure.ac в корне проекта, хотел скомпилировать отдельно библиотеку. Какой выбрать из этих файлов?
А это была другая система на другом устройстве, на android я решил скомпилировать потому, что там не могу
Пробуй собирать всё из корня проекта. Значит пакет не рассчитан для сборки по частям.
Поставь нормальный не урезанный дистрибудив.
Не могу, есть много причин. 1.) Это не пк с операционной системой, а программа-эмулятор. 2.) Она проверяет подлинность и не разрешает ставить другую OС. 3.) Эта ОС самая быстрая
Попробовал. Почему denied? Root есть!
Дай права на выполнение.
Что за бл***. Все сделал как надо, но всё равно сыпятся ошибки
права на выполнение дать
Должно работать вот так:
Дай сам код то, я на своём попробую собрать, сейчас тоже с Termux играюсь ))
Оффтоп: а нахрена собирать с рутовыми правами?
Что за ошибка permission denied? При любых действиях с компилятором правильных такая ошибка
Ошибка прав доступа.
он там не нужен вообщето, если ты через tsu рутуешься то всё ок если через su то ты уже не в консоли Termux, а в консоли android
sudo su не в консоли работает а как обычно
Вот новая ошибка
я не школьник, просто надо срочно скомпилировать
у тебя там вообще нет файла ./configure
Есть. Я проверил, теперь есть
В скриптах, выполняемых при конфигурировании стоит вызов командного интерпретатора /bin/sh, если его нет в эмуляторе, то либо ставь его туда как-то, если там есть /bin/bash, то можешь сделать символьную ссылку, ну либо правь исходники.
Ошибка доступа. Значит, у тебя нет прав на каталог либо файлы в нём. Это значит, что их нужно поправить. Тем не менее, для собственно компиляции рут не нужен, хоть и может скрыть проблему
chmod u+x configure помог. Теперь другая ошибка configure error cannot run /bin/sh ./config.sub
В эмуляторе нет /bin/sh
Создал папку bin и этот файл, экскортировал переменные но не получается
Создал папку bin и этот файл
/bin/sh — это программа, а не просто какой-то файл.
В Linux, когда ты в командной строке вводишь имя и пароль, то после авторизации у тебя запускается командная оболочка, так вот эта запущенная оболочка и есть /bin/sh, /bin/bash или другая реализация.
Аналогично и в эмуляторе терминала в графической оболочке.
Разбираться как добавить в эмулятор эту программу.
Получилось, эта команда исправила export CONFIG_SHELL=$PREFIX/bin/sh Но теперь ошибка ещё непонятнее https://image.ibb.co/jw3nHR/Screenshot_20180116_112438.png
Что именно непонятно в фразе No C compiler found?
Gcc has no installation candidate, не могу его установить
И еще что за cc и cl.exe
Это не помогает apt-get clean rm -rf /var/lib/apt/lists/* apt-get clean apt-get update apt-get upgrade
Источник
Просто о make
Меня всегда привлекал минимализм. Идея о том, что одна вещь должна выполнять одну функцию, но при этом выполнять ее как можно лучше, вылилась в создание UNIX. И хотя UNIX давно уже нельзя назвать простой системой, да и минимализм в ней узреть не так то просто, ее можно считать наглядным примером количество- качественной трансформации множества простых и понятных вещей в одну весьма непростую и не прозрачную. В своем развитии make прошел примерно такой же путь: простота и ясность, с ростом масштабов, превратилась в жуткого монстра (вспомните свои ощущения, когда впервые открыли мэйкфайл).
Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом ‘пережитке прошлого’ (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.
Make- основные сведения
make — утилита предназначенная для автоматизации преобразования файлов из одной формы в другую. Правила преобразования задаются в скрипте с именем Makefile, который должен находиться в корне рабочей директории проекта. Сам скрипт состоит из набора правил, которые в свою очередь описываются:
1) целями (то, что данное правило делает);
2) реквизитами (то, что необходимо для выполнения правила и получения целей);
3) командами (выполняющими данные преобразования).
В общем виде синтаксис makefile можно представить так:
То есть, правило make это ответы на три вопроса:
Несложно заметить что процессы трансляции и компиляции очень красиво ложатся на эту схему:
Простейший Makefile
Предположим, у нас имеется программа, состоящая всего из одного файла:
Для его компиляции достаточно очень простого мэйкфайла:
Данный Makefile состоит из одного правила, которое в свою очередь состоит из цели — «hello», реквизита — «main.c», и команды — «gcc -o hello main.c». Теперь, для компиляции достаточно дать команду make в рабочем каталоге. По умолчанию make станет выполнять самое первое правило, если цель выполнения не была явно указана при вызове:
Компиляция из множества исходников
Предположим, что у нас имеется программа, состоящая из 2 файлов:
main.c
Makefile, выполняющий компиляцию этой программы может выглядеть так:
Он вполне работоспособен, однако имеет один значительный недостаток: какой — раскроем далее.
Инкрементная компиляция
Представим, что наша программа состоит из десятка- другого исходных файлов. Мы вносим изменения в один из них, и хотим ее пересобрать. Использование подхода описанного в предыдущем примере приведет к тому, что все без исключения исходные файлы будут снова скомпилированы, что негативно скажется на времени перекомпиляции. Решение — разделить компиляцию на два этапа: этап трансляции и этап линковки.
Теперь, после изменения одного из исходных файлов, достаточно произвести его трансляцию и линковку всех объектных файлов. При этом мы пропускаем этап трансляции не затронутых изменениями реквизитов, что сокращает время компиляции в целом. Такой подход называется инкрементной компиляцией. Для ее поддержки make сопоставляет время изменения целей и их реквизитов (используя данные файловой системы), благодаря чему самостоятельно решает какие правила следует выполнить, а какие можно просто проигнорировать:
Попробуйте собрать этот проект. Для его сборки необходимо явно указать цель, т.е. дать команду make hello.
После- измените любой из исходных файлов и соберите его снова. Обратите внимание на то, что во время второй компиляции, транслироваться будет только измененный файл.
После запуска make попытается сразу получить цель hello, но для ее создания необходимы файлы main.o и hello.o, которых пока еще нет. Поэтому выполнение правила будет отложено и make станет искать правила, описывающие получение недостающих реквизитов. Как только все реквизиты будут получены, make вернется к выполнению отложенной цели. Отсюда следует, что make выполняет правила рекурсивно.
Фиктивные цели
На самом деле, в качестве make целей могут выступать не только реальные файлы. Все, кому приходилось собирать программы из исходных кодов должны быть знакомы с двумя стандартными в мире UNIX командами:
Командой make производят компиляцию программы, командой make install — установку. Такой подход весьма удобен, поскольку все необходимое для сборки и развертывания приложения в целевой системе включено в один файл (забудем на время о скрипте configure). Обратите внимание на то, что в первом случае мы не указываем цель, а во втором целью является вовсе не создание файла install, а процесс установки приложения в систему. Проделывать такие фокусы нам позволяют так называемые фиктивные (phony) цели. Вот краткий список стандартных целей:
- all — является стандартной целью по умолчанию. При вызове make ее можно явно не указывать.
- clean — очистить каталог от всех файлов полученных в результате компиляции.
- install — произвести инсталляцию
- uninstall — и деинсталляцию соответственно.
Для того чтобы make не искал файлы с такими именами, их следует определить в Makefile, при помощи директивы .PHONY. Далее показан пример Makefile с целями all, clean, install и uninstall:
Теперь мы можем собрать нашу программу, произвести ее инсталлцию/деинсталляцию, а так же очистить рабочий каталог, используя для этого стандартные make цели.
Обратите внимание на то, что в цели all не указаны команды; все что ей нужно — получить реквизит hello. Зная о рекурсивной природе make, не сложно предположить как будет работать этот скрипт. Так же следует обратить особое внимание на то, что если файл hello уже имеется (остался после предыдущей компиляции) и его реквизиты не были изменены, то команда make ничего не станет пересобирать. Это классические грабли make. Так например, изменив заголовочный файл, случайно не включенный в список реквизитов, можно получить долгие часы головной боли. Поэтому, чтобы гарантированно полностью пересобрать проект, нужно предварительно очистить рабочий каталог:
Для выполнения целей install/uninstall вам потребуются использовать sudo.
Переменные
Все те, кто знакомы с правилом DRY (Don’t repeat yourself), наверняка уже заметили неладное, а именно — наш Makefile содержит большое число повторяющихся фрагментов, что может привести к путанице при последующих попытках его расширить или изменить. В императивных языках для этих целей у нас имеются переменные и константы; make тоже располагает подобными средствами. Переменные в make представляют собой именованные строки и определяются очень просто:
Существует негласное правило, согласно которому следует именовать переменные в верхнем регистре, например:
Так мы определили список исходных файлов. Для использования значения переменной ее следует разименовать при помощи конструкции $( ); например так:
Ниже представлен мэйкфайл, использующий две переменные: TARGET — для определения имени целевой программы и PREFIX — для определения пути установки программы в систему.
Это уже посимпатичней. Думаю, теперь вышеприведенный пример для вас в особых комментариях не нуждается.
Автоматические переменные
Автоматические переменные предназначены для упрощения мейкфайлов, но на мой взгляд негативно сказываются на их читабельности. Как бы то ни было, я приведу здесь несколько наиболее часто используемых переменных, а что с ними делать (и делать ли вообще) решать вам:
Источник
«clean» not working in make file
This is my make file.
Here I’m trying to use
To clean up the temporary *.o files. But program compiles and generate the target assembly, but doesn’t delete the *.o files. Not showing any errors also.
- I tried rm -f *o observer in terminal. It works fine.
- I have used Tab for indent
- there are no files start with clean or rm in the directory.
- tried $(RM) instead of rm . but no lucky
3 Answers 3
I found the issue. Have to specify clean as a target of all otherwise it wont call. generally like this.
all: [your executive names] clean
all: observer clean
Here is the full make file of above case
As others have mentioned, this is likely an indentation issue. I copied your makefile exactly, touched some dummy .o files and ran it:
After fixing indentation, it seems to work just fine for me:
The specific indentation fixes I made were:
- target lines should not have any leading whitespace at all
- recipe lines must start with exactly one tab and no other whitespace
I have saved the fixed version here, because stackoverflow messes with tabs/whitespace. Make sure to copy from the RAW Paste Data.
Having read the question, comments and your self-answer in a little more detail, I think there is possibly some explaining to do about conventional usage of make.
You may call the make executable with a list of targets to build, or no targets at all.
In the case that targets are specified, then make will attempt to build/rebuild those targets. For instance, with the corrected Makefile, make observer would build the observer target ( observer executable), make main.o would simply compile main.cpp to produce main.o, and make clean would invoke the clean rule to delete the listed files.
On the other hand, if you invoke make with no targets, then make will simply use the first target defined in the Makefile as the target that it builds. The convention is that this target is called all , but it can be called whatever you like. So in the case of the corrected makefile, invoking make without explicitly passing any targets should result in all and its dependency observer being rebuilt. I suspect this is where the confusion has arisen — invoking make for this makefile with no targets explicitly mentioned should not result in invocation of the clean target. This is the expected make behavior.
Источник