Содержание
- Cannot find install-sh, install.sh, or shtool in ac-aux
- 2. Build and install
- 10 Answers 10
- Obtaining the software the right way
- So when do you need Autotools?
- TL;DR summary
- MacOS Big Sur + Erlang 22.3 + AutoConf -> cannot find required auxiliary files: install-sh config.guess config.sub #195
- Comments
- configure in doc/example fails with «cannot find install-sh, install.sh, or shtool in «.» «./..» «./../..»» when autoconf is used #34
- Comments
- Не удается найти install-sh, install.sh или shtool в ac-aux
- 2. Сборка и установка
- 10 ответов
- Получение программного обеспечения правильный путь
- Поэтому, когда Вам нужны Автоинструменты?
- TL; сводка
This is my first time trying to compile and install anything on a linux machine. I got the latest version of https://github.com/processone/exmpp via git and read the instructions which state:
2. Build and install
Exmpp uses the Autotools. Therefore the process is quite common:
after type ./configure I get the error
Cannot find install-sh, install.sh, or shtool in ac-aux
Google was of little to no help. Not sure at all what I’m supposed to do. Any help would be much appreciated
10 Answers 10
I got it to create the configure script using the following tools:
I don’t have all the dependencies so I can’t test it right now, but this is generally how you would create a configure script from an ac file.
Well, I tried sebastian_k’s answer and it didn’t work for me ( ./configure crashed midway through with an extremely weird error).
What did, however work for me was copying the instructions used in this build log I found
The short version(so you don’t have to wade through it yourself) is:
This question, and most of the other answers here, arise from a misunderstanding of how projects using the GNU Build System (a.k.a. Autotools) are distributed. In fact, in the case of the Erlang XMPP library mentioned by the OP, the misunderstanding appears to be on the part of the developers.
Obtaining the software the right way
If all you want to do is compile and install a project released with the GNU Autotools, then you should not check it out from the source control system. You should instead download the packaged source release provided by the developer. These normally take the form of tarballs distributed on the project’s website. For projects that are hosted entirely on GitHub, Savannah, or some similar hosting service, these tarballs will usually be found behind some link labelled «Download» or «Releases». You untar the package and utter some variant of the standard ./configure && make && sudo make install incantation. That’s all; you don’t need to invoke any of the GNU Autotools, and don’t even need to have the GNU Autotools installed on your system.
The reason that you, the user, don’t need the GNU Autotools to compile an Autotools-packaged project is that the developer has already used the various Autotools programs to generate a «distribution tarball» that can be used to build the software on any Unix-like system. The distribution tarball contains a highly portable configure script that scans the build environment, checks for dependencies, and constructs a Makefile customized to your system.
The only reason you should need to install and invoke the GNU Autotools yourself is if you want to do development work on a project built with Autotools. And even then, you probably won’t need the Autotools unless you change the project’s dependencies. In that case, you would indeed need to check out the original source, make appropriate changes to the Autotools-specific input files ( configure.ac , Makefile.am , etc.), and run the Autotools on them to generate a new configure file. If you want to independently publish the revised package, then you would use the Makefile generated by Autotools to generate a new distribution tarball, and then publish that tarball somewhere online.
The problem is that some developers make their source repository publically available but neglect to publish their distribution tarballs (or make it difficult to find where they are published). For example, rather than publishing their distribution tarballs as GitHub Releases, the Erlang XMPP library’s GitHub Releases are tarballs of the raw source repository. This makes it impossible to compile the project without the GNU Autotools, defeating the entire purpose of using Autotools in the first place.
TL;DR summary
The GNU Autotools are something that developers use to make portable source code packages for users. Users should download and compile from these source packages, not the original code from the source control system. If the developers don’t provide these source packages, then they aren’t using Autotools correctly, and should be gently slapped with a wet trout until they see the error of their ways.
Источник
MacOS Big Sur + Erlang 22.3 + AutoConf -> cannot find required auxiliary files: install-sh config.guess config.sub #195
I have upgraded my OS yesterday and wanted to re-install Erlang 22.3.4.12 .
It fails with the error configure: error: cannot find required auxiliary files: install-sh config.guess config.sub (full logs at https://gist.github.com/thbar/f2e0a503437c87816feb0b18e11d36a2).
I have tried KERL_CONFIGURE_OPTIONS=—disable-debug —without-javac and the required dependencies are I believe installed.
I’ve noticed that autoconf is at version 2.71 , mentioning this since an issue on Arch (#189), I wonder if this is the same but haven’t downgraded autoconf with homebrew yet (I have to verify the correct way to do this).
It is interesting that Erlang 23 will install properly, on the other hand.
I hoped to benefit from the precompiled binaries available since #190, but apparently the compilation kicks in.
The text was updated successfully, but these errors were encountered:
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
Works for me as well on:
- MacOS Big Sur (11.2.3)
- Xcode 12.4
- Erlang 21.0.5, 23.3.1
where previously for 21.0.5, I have the following errors:
where 23.3.1 works for me without downgrading autoconf from 2.71 to 2.69.
I had similar issues with 22.3.1 .
Running the install with the ERLANG_OPENSSL_PATH environment variable fixed it.
e.g. ERLANG_OPENSSL_PATH=»/usr/local/opt/openssl» asdf install erlang 22.3.1
For y’all Mac users, I hacked my way to a solution for OTP 21, which has the same problem.
use Homebrew to install => brew install erlang@21 , which gets installed into /usr/local/Cellar/erlang@21
Move the Homebrew install to the asdf directory => mv /usr/local/Cellar/erlang@21/21.3.8.21 $HOME/.asdf/installs/erlang
Find all of the erlang shims in
/.asdf/shims & add this under the shebang (I put on line 2 above # asdf-plugin: erlang 23.3.1 ) => # asdf-plugin: erlang 21.3.8.21
Feel dirty for such a hack job, but use the money you made from work to buy a shot of tequila to feel better & get on with your life.
Anyone else having the issue with erlang 23?
@kylesmith13 Where did you install autoconf manually?
EDIT: Oh it actually works just installing autoconf in any directory. Which you seem to be able to delete after wards
I manually edited the autoconf formula to install autoconf 2.69 with brew. Here’s a gist with it: https://gist.github.com/oriolgual/2f881fa3a151dd5f643f755ddcf2a0bc
My workaround, without removing or overwriting my existing copy of autoconf.
Extract it, configure using $PWD as the prefix, add $PWD/bin to your PATH , then install Erlang:
I manually edited the autoconf formula to install autoconf 2.69 with brew. Here’s a gist with it: https://gist.github.com/oriolgual/2f881fa3a151dd5f643f755ddcf2a0bc
There is a specific formulae for this so you can just execute
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
I had the same issue after upgrading an elixir application first to erlang 23.3.4.3 and elixir 1.12.1 and then downgrading again to
erlang 22.3.4.12 elixir 1.10.4 . This solution did not work for me.
What worked however was:
Hope that helps someone.
initially having the same issue after updating to BigSur 11.4 and updating cli for xcode and brew upgrade
configure: error: cannot find required auxiliary files: install-sh config.guess config.sub ERROR: /Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_22.0.7/otp_src_22.0.7/make/configure failed!
tried the workaround as described above (using autoconf 2.69). but am getting another issue when trying to build erlang 22.0.7 .
Источник
configure in doc/example fails with «cannot find install-sh, install.sh, or shtool in «.» «./..» «./../..»» when autoconf is used #34
cmake . && make && make test works fine. README suggest that both work fine. Output:
experienced with 0.10.0-69-g82cdb29
The text was updated successfully, but these errors were encountered:
My guess is that something necessary for the configure script to run is missing. A quick Google search points out that you may not have libtool, shtool, and/or autogen installed. If this is the Ubuntu system mentioned in another issue, could you try installing these and see if it resolves the problem?
As a side question, does this occur using Check 0.10.0 with the provided configure script? How about generating one using autoreconf?
Sorry, I’m an idiot for not mentioning that this happens in doc/example , but some of your comment still applies.
My guess is that something necessary for the configure script to run is missing. A quick Google search points out that you may not have libtool, shtool, and/or autogen installed. If this is the Ubuntu system mentioned in another issue, could you try installing these and see if it resolves the problem?
Doesn’t help because they were already installed. It’s the same system used in #33 (it doesn’t seem to like check unfortunately).
As a side question, does this occur using Check 0.10.0 with the provided configure script? How about generating one using autoreconf?
There’s no configure in doc/example .
There is a Jenkins job which tests that the example is buildable on each pull request, and that is currently passing. Looking at its output and comparing it to what you observe, I see the following line from the Jenkins job:
and the following from your output:
For whatever reason, on the GNU/Linux machine backing the Jenkins node the install-sh script is generated, but on your system it is not.
This site suggests running the following in order to generate the missing files. Could you give it a try and see what happens?
If that works, then we will need to determine why the missing files were not all generated.
Источник
Не удается найти install-sh, install.sh или shtool в ac-aux
Я впервые пытаюсь скомпилировать и установить что-либо на машине с Linux. Я получил последнюю версию https://github.com/processone/exmpp через git и прочитал инструкции, в которых указано:
2. Сборка и установка
Exmpp использует Autotools. Поэтому процесс довольно распространен:
после типа ./configure я получаю ошибку
Не могу найти install-sh, install.sh или shtool в ac-aux
Google мало что помогал. Совершенно не уверен, что я должен делать. Любая помощь будет высоко ценится
10 ответов
Ну, я попробовал ответ sebastian_k, и он не сработал для меня ( ./configure разбился на полпути с очень странной ошибкой).
Что, тем не менее, помогло мне скопировать инструкции, использованные в этом журнале сборки, который я нашел
Короткая версия (так что вам не придется разбираться с ней самостоятельно) :
Я получил его для создания скрипта конфигурирования с использованием следующих инструментов:
У меня нет всех зависимостей, поэтому я не могу проверить его прямо сейчас, но обычно это так создайте скрипт конфигурации из файла AC.
У меня была эта проблема, и я обнаружил, что это произошло из-за следующей строки в configure.ac :
Эта линия сама по себе не была плохой, однако ее нужно было приблизить к верх файла configure.ac .
При попытке скомпилировать GNU Octave из репозитория Mercurial вы можете столкнуться с этой проблемой. Исправление заключается в запуске ./bootstrap , находясь в корне исходного дерева.
sudo apt-get install automake autoconf
его работы успешно
Пожалуйста, сделайте следующее, чтобы решить эту проблему,
Затем выполните установку
У меня была похожая проблема, когда я пытался ./configure получить исходный код и получил ту же ошибку, что и опубликованная. Наконец, решил мои проблемы, введя код:
После установки пакета autogen эта ошибка была исправлена в wolfSSL build.
У меня была немного другая ошибка:
configure: error: cannot find install-sh, install.sh, or shtool in «.» «./..» «./../..»
Оказывается, конфигурация не может найти build-aux/install-sh . Я связал это так
ln -s build-aux/install-sh .
, затем он строит.
Надеюсь, это поможет кому-то там!
Этот вопрос и большинство других ответов здесь, являются результатом неверного толкования как проекты с помощью Система сборки GNU (иначе. Автоинструменты), распределяются. На самом деле, в случае библиотека Erlang XMPP упомянутый OP, недоразумение, кажется, со стороны разработчиков.
Получение программного обеспечения правильный путь
, Если все Вы хотите сделать, скомпилировать и установить проект, выпущенный с Автоинструментами GNU, затем Вы не должны проверять его из системы управления исходным кодом . Необходимо вместо этого загрузить упакованный исходный выпуск , обеспеченный разработчиком. Они обычно принимают форму tarballs, распределенного на веб-сайте проекта. Для проектов, которые размещаются полностью на GitHub, Саванне или некоторой подобной услуге хостинга, эти tarballs будут обычно находиться позади некоторой ссылки, маркировал «Download» или «Releases». Вы untar пакет и чрезвычайный некоторый вариант стандарта ./configure && make && sudo make install колдовство.Это все; Вы не должны вызывать ни один из Автоинструментов GNU и не должны были даже устанавливать Автоинструменты GNU в Вашей системе.
причина, что Вам, пользователю, не нужны Автоинструменты GNU для компиляции Упакованного автоинструментами проекта, состоит в том, что разработчик уже имеет , использовал различные программы Автоинструментов для генерации «распределения tarball», который может использоваться для создания программного обеспечения в любой подобной Unix системе. Распределение tarball содержит очень портативное configure сценарий, который сканирует среду сборки, проверки на зависимости, и создает Makefile настроенный к Вашей системе.
Поэтому, когда Вам нужны Автоинструменты?
единственная причина необходимо должны быть установить и вызвать GNU Autotools, сами то, если Вы хотите сделать разработка работа над проектом, разработанным с Автоинструментами. И даже затем, Вам, вероятно, не будут нужны Автоинструменты, если Вы не измените зависимости проекта. В этом случае необходимо было бы действительно проверить первоисточник, внести соответствующие изменения в Определенные для автоинструментов входные файлы ( configure.ac , Makefile.am , и т.д.), и выполнить Автоинструменты на них для генерации нового configure файл. Если бы Вы хотите независимо опубликовать пересмотренный пакет, то Вы использовали бы Make-файл, сгенерированный Автоинструментами, чтобы генерировать новое распределение tarball и затем опубликовать это tarball где-нибудь онлайн.
проблема состоит в том, что некоторые разработчики делают свой исходный репозиторий публично доступным, но забыли публиковать свое распределение tarballs (или мешать находить, где они публикуются). Например, а не публикация их распределения tarballs как Выпуски GitHub , библиотека Erlang XMPP Выпуски GitHub являются tarballs необработанного исходного репозитория. Это лишает возможности компилировать проект без Автоинструментов GNU, побеждая всю цель использовать Автоинструменты во-первых.
TL; сводка
DR Автоинструменты GNU является чем-то что разработчики использование для создания портативных пакетов исходного кода для пользователей. Пользователи должны загрузить и скомпилировать от этих исходных пакетов, не исходного кода от системы управления исходным кодом. Если разработчики не обеспечивают эти исходные пакеты, то они не используют Автоинструменты правильно и должны быть мягко хлопнувшие с влажной форелью , пока они не видят ошибки своих путей.
Источник
initially having the same issue after updating to BigSur 11.4 and updating cli for xcode and brew upgrade
configure: error: cannot find required auxiliary files: install-sh config.guess config.sub ERROR: /Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_22.0.7/otp_src_22.0.7/make/configure failed!
tried the workaround as described above (using autoconf 2.69). but am getting another issue when trying to build erlang 22.0.7.
/Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_22.0.7/otp_src_22.0.7/make/otp_subdir.mk:29: warning: ignoring old commands for targetclean’
=== Entering application hipe
ERLC ../ebin/hipe_consttab.beam
ERLC ../ebin/hipe_gensym.beam
/bin/sh: line 1: 52264 Segmentation fault: 11 erlc -W +debug_info -Werror +warn_export_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe_consttab.erl
/bin/sh: line 1: 52265 Segmentation fault: 11 erlc -W +debug_info -Werror +warn_export_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe_gensym.erl
make[3]: *** [../ebin/hipe_gensym.beam] Error 139
make[3]: *** Waiting for unfinished jobs….
make[3]: *** [../ebin/hipe_consttab.beam] Error 139
make[2]: *** [opt] Error 2
make[1]: *** [opt] Error 2
make: *** [secondary_bootstrap_build] Error 2`.
full log here otp_build_22.0.7.log
attempting to build 24.0.2 fails but throws a different error
=== Entering application parsetools ERLC ../ebin/leex.beam ERLC ../ebin/yeccparser.beam ERLC ../ebin/yecc.beam ERLC ../ebin/yeccscan.beam /bin/sh: line 1: 86901 Abort trap: 6 erlc -W -Werror +debug_info -DUSE_ESOCK=true -I/Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_24.0.2/otp_src_24.0.2/lib/stdlib/include -Werror -o../ebin yeccparser.erl /bin/sh: line 1: 86902 Abort trap: 6 erlc -W -Werror +debug_info -DUSE_ESOCK=true -I/Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_24.0.2/otp_src_24.0.2/lib/stdlib/include -Werror -o../ebin yecc.erl /bin/sh: line 1: 86903 Abort trap: 6 erlc -W -Werror +debug_info -DUSE_ESOCK=true -I/Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_24.0.2/otp_src_24.0.2/lib/stdlib/include -Werror -o../ebin yeccscan.erl /bin/sh: line 1: 86900 Abort trap: 6 erlc -W -Werror +debug_info -DUSE_ESOCK=true -I/Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_24.0.2/otp_src_24.0.2/lib/stdlib/include -Werror -o../ebin leex.erl make[3]: *** [../ebin/yeccscan.beam] Error 134 make[3]: *** Waiting for unfinished jobs.... make[3]: *** [../ebin/yeccparser.beam] Error 134 make[3]: *** [../ebin/yecc.beam] Error 134 make[3]: *** [../ebin/leex.beam] Error 134 make[2]: *** [opt] Error 2 make[1]: *** [opt] Error 2 make: *** [secondary_bootstrap_build] Error 2
otp_build_24.0.2.log
anyone else experience this?
- MacOS Big Sur (11.4)
- Xcode 12.5
- all dependencies have been installed.
configure in doc/example fails with «cannot find install-sh, install.sh, or shtool in «.» «./..» «./../..»» when autoconf is used #34
Comments
krichter722 commented Mar 31, 2016
cmake . && make && make test works fine. README suggest that both work fine. Output:
experienced with 0.10.0-69-g82cdb29
The text was updated successfully, but these errors were encountered:
brarcher commented Mar 31, 2016
My guess is that something necessary for the configure script to run is missing. A quick Google search points out that you may not have libtool, shtool, and/or autogen installed. If this is the Ubuntu system mentioned in another issue, could you try installing these and see if it resolves the problem?
As a side question, does this occur using Check 0.10.0 with the provided configure script? How about generating one using autoreconf?
krichter722 commented Mar 31, 2016
Sorry, I’m an idiot for not mentioning that this happens in doc/example , but some of your comment still applies.
My guess is that something necessary for the configure script to run is missing. A quick Google search points out that you may not have libtool, shtool, and/or autogen installed. If this is the Ubuntu system mentioned in another issue, could you try installing these and see if it resolves the problem?
Doesn’t help because they were already installed. It’s the same system used in #33 (it doesn’t seem to like check unfortunately).
As a side question, does this occur using Check 0.10.0 with the provided configure script? How about generating one using autoreconf?
There’s no configure in doc/example .
brarcher commented Mar 31, 2016
There is a Jenkins job which tests that the example is buildable on each pull request, and that is currently passing. Looking at its output and comparing it to what you observe, I see the following line from the Jenkins job:
and the following from your output:
For whatever reason, on the GNU/Linux machine backing the Jenkins node the install-sh script is generated, but on your system it is not.
This site suggests running the following in order to generate the missing files. Could you give it a try and see what happens?
If that works, then we will need to determine why the missing files were not all generated.
Источник
MacOS Big Sur + Erlang 22.3 + AutoConf -> cannot find required auxiliary files: install-sh config.guess config.sub #195
Comments
thbar commented Apr 8, 2021
I have upgraded my OS yesterday and wanted to re-install Erlang 22.3.4.12 .
It fails with the error configure: error: cannot find required auxiliary files: install-sh config.guess config.sub (full logs at https://gist.github.com/thbar/f2e0a503437c87816feb0b18e11d36a2).
I have tried KERL_CONFIGURE_OPTIONS=—disable-debug —without-javac and the required dependencies are I believe installed.
I’ve noticed that autoconf is at version 2.71 , mentioning this since an issue on Arch (#189), I wonder if this is the same but haven’t downgraded autoconf with homebrew yet (I have to verify the correct way to do this).
It is interesting that Erlang 23 will install properly, on the other hand.
I hoped to benefit from the precompiled binaries available since #190, but apparently the compilation kicks in.
The text was updated successfully, but these errors were encountered:
thbar commented Apr 8, 2021
kylesmith13 commented Apr 8, 2021
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
kw7oe commented Apr 9, 2021
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
Works for me as well on:
- MacOS Big Sur (11.2.3)
- Xcode 12.4
- Erlang 21.0.5, 23.3.1
where previously for 21.0.5, I have the following errors:
where 23.3.1 works for me without downgrading autoconf from 2.71 to 2.69.
Catharz commented Apr 14, 2021
I had similar issues with 22.3.1 .
Running the install with the ERLANG_OPENSSL_PATH environment variable fixed it.
e.g. ERLANG_OPENSSL_PATH=»/usr/local/opt/openssl» asdf install erlang 22.3.1
devoutsalsa commented Apr 19, 2021
For y’all Mac users, I hacked my way to a solution for OTP 21, which has the same problem.
use Homebrew to install => brew install erlang@21 , which gets installed into /usr/local/Cellar/erlang@21
Move the Homebrew install to the asdf directory => mv /usr/local/Cellar/erlang@21/21.3.8.21 $HOME/.asdf/installs/erlang
Find all of the erlang shims in
/.asdf/shims & add this under the shebang (I put on line 2 above # asdf-plugin: erlang 23.3.1 ) => # asdf-plugin: erlang 21.3.8.21
Feel dirty for such a hack job, but use the money you made from work to buy a shot of tequila to feel better & get on with your life.
dylan-chong commented Apr 26, 2021
Anyone else having the issue with erlang 23?
dylan-chong commented Apr 26, 2021 •
@kylesmith13 Where did you install autoconf manually?
EDIT: Oh it actually works just installing autoconf in any directory. Which you seem to be able to delete after wards
oriolgual commented May 2, 2021
I manually edited the autoconf formula to install autoconf 2.69 with brew. Here’s a gist with it: https://gist.github.com/oriolgual/2f881fa3a151dd5f643f755ddcf2a0bc
sigwinch28 commented May 19, 2021 •
My workaround, without removing or overwriting my existing copy of autoconf.
Extract it, configure using $PWD as the prefix, add $PWD/bin to your PATH , then install Erlang:
spencerdcarlson commented May 26, 2021 •
I manually edited the autoconf formula to install autoconf 2.69 with brew. Here’s a gist with it: https://gist.github.com/oriolgual/2f881fa3a151dd5f643f755ddcf2a0bc
There is a specific formulae for this so you can just execute
ospaarmann commented Jun 17, 2021
i solved this issue by uninstalling autoconf with homebrew then manually installing autoconf 2.69 with
I had the same issue after upgrading an elixir application first to erlang 23.3.4.3 and elixir 1.12.1 and then downgrading again to
erlang 22.3.4.12 elixir 1.10.4 . This solution did not work for me.
What worked however was:
Hope that helps someone.
lamboap commented Jun 20, 2021
initially having the same issue after updating to BigSur 11.4 and updating cli for xcode and brew upgrade
configure: error: cannot find required auxiliary files: install-sh config.guess config.sub ERROR: /Users/lambert/.asdf/plugins/erlang/kerl-home/builds/asdf_22.0.7/otp_src_22.0.7/make/configure failed!
tried the workaround as described above (using autoconf 2.69). but am getting another issue when trying to build erlang 22.0.7 .
Источник
2.2.3 release: configure: error: cannot find required auxiliary files: ltmain.sh compile missing #1624
Comments
mgorny commented Oct 28, 2021
blueman: 2.2.3
BlueZ: 5.62
Distribution: Gentoo Linux
Desktop environment: XFCE
- I have consulted the Troubleshooting page and done my best effort to follow.
It seems that the .tar.xz for 2.2.3 release (i.e. https://github.com/blueman-project/blueman/releases/download/2.2.3/blueman-2.2.3.tar.xz) is incomplete. When trying to run ./configure , I get:
I see that there’s meson.build there as well but FWICS autotools is listed in the docs and the version in meson.build isn’t up-to-date, so I’m assuming autotools is the primary way of building blueman.
The text was updated successfully, but these errors were encountered:
mgorny commented Oct 28, 2021
Just to be clear, I know I can solve this by using autoreconf but in general autotools dists include all the generated files.
cschramm commented Oct 28, 2021
Weird. On the system that I ran autoreconf on it somehow interfered with (older) autoreconf -generated files in the parent folder and just did not create those files (although the output said so. ). I replaced the downloads. Thanks for the quick report!
Regarding meson, yes, autotools is the primary way of building blueman. @infirit started a migration to meson but unfortunately is inactive now and I do not have a strong enough opinion on autotools vs. meson to finalize it yet. The meson build is intended to work, though (apart from the version number 😬 ).
mgorny commented Oct 28, 2021
Weird. On the system that I ran autoreconf on it somehow interfered with (older) autoreconf -generated files in the parent folder and just did not create those files (although the output said so. ). I replaced the downloads. Thanks for the quick report!
I’d suggest using make distcheck for release tarballs.
Regarding meson, yes, autotools is the primary way of building blueman. @infirit started a migration to meson but unfortunately is inactive now and I do not have a strong enough opinion on autotools vs. meson to finalize it yet. The meson build is intended to work, though (apart from the version number grimacing).
Well, I don’t have a strong opinion on them either. However, one clear advantage of meson is that it doesn’t require all the dance around generated files ;-).
cschramm commented Oct 29, 2021
I created a GitHub job to streamline releasing in #1625. It triggers on tag pushes and checks CHANGELOG.md, configure.ac and meson.build for the expected version (matching the tag), runs autogen.sh and creates a release draft with the section from CHANGELOG.md and the resulting tarballs. Review welcome. 🙂
infirit commented Nov 8, 2021
Blueman has an option to run uninstalled. I never got this to work with meson. Afaik this was the only thing holding it back being the default.
The main problem is that meson has a separate build dir. Blueman needs a couple of generated python files to work properly.
mgorny commented Nov 8, 2021
Well, the lazy solution would be to have meson copy all Python files into the build dir.
cschramm commented Nov 8, 2021
@infirit: In case you forgot, there’s #1207 in the basement. 😉
As, I said: No strong opinion, so making meson the default ist perfectly fine for me.
Источник
Cannot find install-sh, install.sh, or shtool in ac-aux
This is my first time trying to compile and install anything on a linux machine. I got the latest version of https://github.com/processone/exmpp via git and read the instructions which state:
2. Build and install
Exmpp uses the Autotools. Therefore the process is quite common:
after type ./configure I get the error
Cannot find install-sh, install.sh, or shtool in ac-aux
Google was of little to no help. Not sure at all what I’m supposed to do. Any help would be much appreciated
10 Answers 10
I got it to create the configure script using the following tools:
I don’t have all the dependencies so I can’t test it right now, but this is generally how you would create a configure script from an ac file.
Well, I tried sebastian_k’s answer and it didn’t work for me ( ./configure crashed midway through with an extremely weird error).
What did, however work for me was copying the instructions used in this build log I found
The short version(so you don’t have to wade through it yourself) is:
This question, and most of the other answers here, arise from a misunderstanding of how projects using the GNU Build System (a.k.a. Autotools) are distributed. In fact, in the case of the Erlang XMPP library mentioned by the OP, the misunderstanding appears to be on the part of the developers.
Obtaining the software the right way
If all you want to do is compile and install a project released with the GNU Autotools, then you should not check it out from the source control system. You should instead download the packaged source release provided by the developer. These normally take the form of tarballs distributed on the project’s website. For projects that are hosted entirely on GitHub, Savannah, or some similar hosting service, these tarballs will usually be found behind some link labelled «Download» or «Releases». You untar the package and utter some variant of the standard ./configure && make && sudo make install incantation. That’s all; you don’t need to invoke any of the GNU Autotools, and don’t even need to have the GNU Autotools installed on your system.
The reason that you, the user, don’t need the GNU Autotools to compile an Autotools-packaged project is that the developer has already used the various Autotools programs to generate a «distribution tarball» that can be used to build the software on any Unix-like system. The distribution tarball contains a highly portable configure script that scans the build environment, checks for dependencies, and constructs a Makefile customized to your system.
So when do you need Autotools?
The only reason you should need to install and invoke the GNU Autotools yourself is if you want to do development work on a project built with Autotools. And even then, you probably won’t need the Autotools unless you change the project’s dependencies. In that case, you would indeed need to check out the original source, make appropriate changes to the Autotools-specific input files ( configure.ac , Makefile.am , etc.), and run the Autotools on them to generate a new configure file. If you want to independently publish the revised package, then you would use the Makefile generated by Autotools to generate a new distribution tarball, and then publish that tarball somewhere online.
The problem is that some developers make their source repository publically available but neglect to publish their distribution tarballs (or make it difficult to find where they are published). For example, rather than publishing their distribution tarballs as GitHub Releases, the Erlang XMPP library’s GitHub Releases are tarballs of the raw source repository. This makes it impossible to compile the project without the GNU Autotools, defeating the entire purpose of using Autotools in the first place.
TL;DR summary
The GNU Autotools are something that developers use to make portable source code packages for users. Users should download and compile from these source packages, not the original code from the source control system. If the developers don’t provide these source packages, then they aren’t using Autotools correctly, and should be gently slapped with a wet trout until they see the error of their ways.
Источник
Bug 777453
— dev-lang/erlang-23.0.4 configure: error: cannot find required auxiliary files: install-sh config.guess config.sub
Summary:
dev-lang/erlang-23.0.4 configure: error: cannot find required auxiliary files…
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Note |
Reported by: Helmut Grohne <helmut@subdivi.de>
Date: Thu, 2 Sep 2021 10:09:06 UTC
Severity: serious
Tags: bookworm, ftbfs, patch, sid
Found in version netgen-lvs/1.5.133-1
Fixed in version netgen-lvs/1.5.133-1.1
Done: Adrian Bunk <bunk@debian.org>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded
to debian-bugs-dist@lists.debian.org, Debian Electronics Team <pkg-electronics-devel@lists.alioth.debian.org>:
Bug#993505; Package src:netgen-lvs.
(Thu, 02 Sep 2021 10:09:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Helmut Grohne <helmut@subdivi.de>:
New Bug report received and forwarded. Copy sent to Debian Electronics Team <pkg-electronics-devel@lists.alioth.debian.org>.
(Thu, 02 Sep 2021 10:09:08 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Source: netgen-lvs
Version: 1.5.133-1
Severity: serious
Tags: ftbfs
netgen-lvs fails to build from source. A build on amd64 ends as follows:
| dh_autoreconf
| autoreconf: warning: autoconf input should be named 'configure.ac', not 'configure.in'
| aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
| configure.in:9: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
| configure.in:9: You should run autoupdate.
| ./lib/autoconf/general.m4:2081: AC_CANONICAL_SYSTEM is expanded from...
| configure.in:9: the top level
| configure.in:25: warning: The macro `AC_ISC_POSIX' is obsolete.
| configure.in:25: You should run autoupdate.
| ./lib/autoconf/specific.m4:550: AC_ISC_POSIX is expanded from...
| configure.in:25: the top level
| configure.in:149: warning: The macro `AC_HEADER_STDC' is obsolete.
| configure.in:149: You should run autoupdate.
| ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
| configure.in:149: the top level
| configure.in:171: warning: The macro `AC_TRY_LINK' is obsolete.
| configure.in:171: You should run autoupdate.
| ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
| configure.in:171: the top level
| configure.in:184: warning: The macro `AC_TRY_LINK' is obsolete.
| configure.in:184: You should run autoupdate.
| ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
| configure.in:184: the top level
| configure.in:874: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead
| configure.in:1293: warning: AC_OUTPUT should be used without arguments.
| configure.in:1293: You should run autoupdate.
| configure.in:1293: warning: AC_C_BIGENDIAN should be used with AC_CONFIG_HEADERS
| debian/rules override_dh_auto_configure
| make[1]: Entering directory '/<<PKGBUILDDIR>>'
| dh_auto_configure -- --libdir=${prefix}/lib
| ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --libdir=${prefix}/lib
| configure: error: cannot find required auxiliary files: install-sh config.guess config.sub
| dh_auto_configure: error: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --libdir=${prefix}/lib returned exit code 1
| make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 2
| make[1]: Leaving directory '/<<PKGBUILDDIR>>'
| make: *** [debian/rules:15: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Helmut
Added tag(s) bookworm and sid.
Request was from Sebastian Ramacher <sramacher@debian.org>
to control@bugs.debian.org.
(Sun, 05 Sep 2021 16:15:05 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Electronics Team <pkg-electronics-devel@lists.alioth.debian.org>:
Bug#993505; Package src:netgen-lvs.
(Sun, 07 Nov 2021 19:09:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Electronics Team <pkg-electronics-devel@lists.alioth.debian.org>.
(Sun, 07 Nov 2021 19:09:02 GMT) (full text, mbox, link).
Message #12 received at 993505@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Control: tags 993505 + patch Control: tags 993505 + pending Dear maintainer, I've prepared an NMU for netgen-lvs (versioned as 1.5.133-1.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian
[netgen-lvs-1.5.133-1.1-nmu.diff (text/x-diff, attachment)]
Added tag(s) patch.
Request was from Adrian Bunk <bunk@debian.org>
to 993505-submit@bugs.debian.org.
(Sun, 07 Nov 2021 19:09:02 GMT) (full text, mbox, link).
Added tag(s) pending.
Request was from Adrian Bunk <bunk@debian.org>
to 993505-submit@bugs.debian.org.
(Sun, 07 Nov 2021 19:09:03 GMT) (full text, mbox, link).
Reply sent
to Adrian Bunk <bunk@debian.org>:
You have taken responsibility.
(Tue, 07 Dec 2021 17:09:08 GMT) (full text, mbox, link).
Notification sent
to Helmut Grohne <helmut@subdivi.de>:
Bug acknowledged by developer.
(Tue, 07 Dec 2021 17:09:08 GMT) (full text, mbox, link).
Message #21 received at 993505-close@bugs.debian.org (full text, mbox, reply):
Source: netgen-lvs Source-Version: 1.5.133-1.1 Done: Adrian Bunk <bunk@debian.org> We believe that the bug you reported is fixed in the latest version of netgen-lvs, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 993505@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Adrian Bunk <bunk@debian.org> (supplier of updated netgen-lvs package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sun, 07 Nov 2021 20:50:30 +0200 Source: netgen-lvs Architecture: source Version: 1.5.133-1.1 Distribution: unstable Urgency: medium Maintainer: Debian Electronics Team <pkg-electronics-devel@lists.alioth.debian.org> Changed-By: Adrian Bunk <bunk@debian.org> Closes: 993505 Changes: netgen-lvs (1.5.133-1.1) unstable; urgency=medium . * Non-maintainer upload. * Fix FTBFS with autoconf 2.71. (Closes: #993505) Checksums-Sha1: f1e83b7fcaab1fc651e8e421a992c74e7a133cae 2032 netgen-lvs_1.5.133-1.1.dsc a66b9f4c1fb5b576d8e4b699afac5df5abc0f2a8 6716 netgen-lvs_1.5.133-1.1.debian.tar.xz Checksums-Sha256: 9db0c757222dbce2aab09b34e1e3ebf138720fd2f3b4b512447ebc5b905ed81a 2032 netgen-lvs_1.5.133-1.1.dsc 87277136c7fc6a075c55eb6d24758af9ee6c44ad585cd4f4f7c34b1e199a6152 6716 netgen-lvs_1.5.133-1.1.debian.tar.xz Files: bfe330426fd6ab3a5f7bd91b9fd9ac44 2032 electronics optional netgen-lvs_1.5.133-1.1.dsc 9f126e62e3e4a046da4eae3b455bdc64 6716 electronics optional netgen-lvs_1.5.133-1.1.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmGIIyoACgkQiNJCh6LY mLFyrg//UvBR4EZQqiF+oZNAhktzq4njzazkR42SAkmA7pSAf1X5iD7+6yHq88+s kBvGIaDltyb0MOukWM15NDplmCJlCedcAczDDMUv7HSSS+fSxXdcJiNCSs2e6m+u lsEqFM5XtobE5lG0795yaPDMPk5ex6J9zvwsWiZaZPg00lBMIfGiJnny7JIXPcRy /wyj2aUQGwmEmcEhcuEwXLbFEPwgy1oTH5hjYP5alFS29Lcv9hvf8PxMwGsUSoYQ BAPGLTaXb956pdFcdmXKKDgW8970ktT1MpTVjrJSHQ/JLV1mgUlTJppJE40/id5r zy9/YtEENlP/GFCwiCGZfmZ/nNY4GfeormBA3hUJB9E+YR0HNoEJaEbIQ0FWH+yT K1NKsP5cWCgvAEHl026PAqKFcE7KzgexK80BSH10qVo9Xe87A00LErRoXaZdV187 gpebEKFnDDxjdAW0UdYO4CFL6ay9NjqqEg6aAyUMX3kYIq/JkVDfOHjEPqOpfTqP lf/6HAgO0ER+pfbZyhUu8KMscp3YSmi/uabmklknhBD+k7c5lQFK7esiZFUzQ2nP Dns6jrH4dsJZ/mZHg5iIj1m9Qizfcbzx2b/XcGaFWc1Tt2O7dlJrFzxEBrnorkDN FkzMimvx3rYQ+8hCbjhujJiu+aedixC7XJhvNEbwHVrtVsC1iaM= =2ILV -----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Fri, 07 Jan 2022 07:24:59 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Thu Feb 9 09:13:48 2023;
Machine Name:
bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.
Source: magic
Version: 8.3.105+ds.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> configure.in:1804: warning: AC_OUTPUT should be used without arguments.
> configure.in:1804: You should run autoupdate.
> configure.in:1804: warning: AC_C_BIGENDIAN should be used with AC_CONFIG_HEADERS
> dh_auto_configure -O—no-parallel
> ./configure —build=x86_64-linux-gnu —prefix=/usr —includedir=${prefix}/include —mandir=${prefix}/share/man —infodir=${prefix}/share/info —sysconfdir=/etc —localstatedir=/var —disable-option-checking —disable-silent-rules —libdir=${prefix}/lib/x86_64-linux-gnu —runstatedir=/run —disable-maintainer-mode —disable-dependency-tracking
> configure: error: cannot find required auxiliary files: install-sh config.guess config.sub
> dh_auto_configure: error: ./configure —build=x86_64-linux-gnu —prefix=/usr —includedir=${prefix}/include —mandir=${prefix}/share/man —infodir=${prefix}/share/info —sysconfdir=/etc —localstatedir=/var —disable-option-checking —disable-silent-rules —libdir=${prefix}/lib/x86_64-linux-gnu —runstatedir=/run —disable-maintainer-mode —disable-dependency-tracking returned exit code 1
The full build log is available from:
http://qa-logs.debian.net/2021/10/23/magic_8.3.105+ds.1-1_unstable.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You’re welcome to contribute!
If you reassign this bug to another package, please marking it as ‘affects’-ing
this package. See https://www.debian.org/Bugs/server-control#affects
If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.