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:
$ ./configure
$ make
$ sudo make install
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
install-from-source configure
add a comment |
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:
$ ./configure
$ make
$ sudo make install
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
install-from-source configure
add a comment |
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:
$ ./configure
$ make
$ sudo make install
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
install-from-source configure
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:
$ ./configure
$ make
$ sudo make install
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
install-from-source configure
install-from-source configure
edited Jun 18 '15 at 20:19
BH2017
3,6951859107
3,6951859107
asked Feb 23 '11 at 6:14
MicahMicah
529179
529179
add a comment |
add a comment |
9 Answers
9
active
oldest
votes
I got it to create the configure script using the following tools:
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
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.
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
|
show 6 more comments
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:
$ autoreconf -vif
$ ./configure --prefix=/usr/lib/erlang/lib
$ make
$ sudo make install
16
+1.autoreconf -i
is the correct answer (thev
andf
are usually optional)
– Nemo
May 8 '15 at 18:46
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
add a comment |
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.
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran./configure && make && sudo make install
as you suggested in the second paragraph.
– Pilot6
Sep 1 '17 at 10:56
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
add a comment |
I've had this problem, and found it was due to the following line in configure.ac
:
AC_CONFIG_AUX_DIR([build-aux])
The line wasn't bad per se, however it needed to be moved closer to the top of the configure.ac
file.
add a comment |
Please do the following to fix this problem,
sudo apt-get install autogen libtool shtool
Then do the installation
sh autogen.sh --prefix=prefered_install_path
make
make install
add a comment |
When trying to compile GNU Octave from Mercurial repository, you may come across this problem. The fix is to run ./bootstrap
while being in the root of the source tree.
add a comment |
sudo apt-get install automake autoconf
its works sucessfully
add a comment |
I had a similar problem when i tried to ./configure
a source code and got the same error as posted. Finally resolved my issues by entering the code:
sudo apt-get install autotools-dev
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
add a comment |
After installing autogen
package this error got resolved in wolfSSL
build.
sudo apt-get install autogen libtool shtool
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f27677%2fcannot-find-install-sh-install-sh-or-shtool-in-ac-aux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
I got it to create the configure script using the following tools:
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
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.
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
|
show 6 more comments
I got it to create the configure script using the following tools:
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
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.
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
|
show 6 more comments
I got it to create the configure script using the following tools:
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
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.
I got it to create the configure script using the following tools:
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
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.
edited Nov 4 '16 at 2:15
Evan Carroll
4,789113467
4,789113467
answered Feb 23 '11 at 6:30
sebastian_ksebastian_k
1,68321011
1,68321011
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
|
show 6 more comments
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
2
2
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
The instructions in the README were probably blindly copied from somewhere else. I have to admit that I don't understand every detail of the autoconf toolchain; it's basically a collection of macros that are generated and used to create your configure script (which, in turn, sets the stage for the compilation and installation process). I never had to fine-tune these things, so I'm not an expert, but there are some fairly extensive explanations here
– sebastian_k
Feb 23 '11 at 7:05
11
11
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
Note to programmers: please stop using the automake toolchain. Please.
– Qix
Oct 2 '15 at 9:41
1
1
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
@Qix, could you, please, explain us why?
– Sergei
Feb 21 '16 at 20:01
4
4
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
@Sergei it's messy, slow, and breaks constantly. It clutters up defines and is incredibly magic. Its way of handling dependencies (or lack thereof) gives cryptic error messages, and the files it produces are unreadable at best and nightmarishly broken at worst.
– Qix
Feb 22 '16 at 19:53
4
4
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
@Sergei CMake is the most viable at this point in time in my opinion. I'm sure there will be something better in the (near) future.
– Qix
Feb 26 '16 at 1:04
|
show 6 more comments
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:
$ autoreconf -vif
$ ./configure --prefix=/usr/lib/erlang/lib
$ make
$ sudo make install
16
+1.autoreconf -i
is the correct answer (thev
andf
are usually optional)
– Nemo
May 8 '15 at 18:46
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
add a comment |
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:
$ autoreconf -vif
$ ./configure --prefix=/usr/lib/erlang/lib
$ make
$ sudo make install
16
+1.autoreconf -i
is the correct answer (thev
andf
are usually optional)
– Nemo
May 8 '15 at 18:46
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
add a comment |
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:
$ autoreconf -vif
$ ./configure --prefix=/usr/lib/erlang/lib
$ make
$ sudo make install
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:
$ autoreconf -vif
$ ./configure --prefix=/usr/lib/erlang/lib
$ make
$ sudo make install
edited Oct 7 '16 at 9:50
answered Nov 10 '12 at 13:30
entropyentropy
49144
49144
16
+1.autoreconf -i
is the correct answer (thev
andf
are usually optional)
– Nemo
May 8 '15 at 18:46
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
add a comment |
16
+1.autoreconf -i
is the correct answer (thev
andf
are usually optional)
– Nemo
May 8 '15 at 18:46
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
16
16
+1.
autoreconf -i
is the correct answer (the v
and f
are usually optional)– Nemo
May 8 '15 at 18:46
+1.
autoreconf -i
is the correct answer (the v
and f
are usually optional)– Nemo
May 8 '15 at 18:46
2
2
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
+1. This is the only answer that worked for me.
– weberc2
Jan 30 '17 at 19:32
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
@Nemo nice one. The accepted answer technically works, but yours is the simplest by far.
– Avindra Goolcharan
Nov 5 '17 at 0:06
add a comment |
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.
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran./configure && make && sudo make install
as you suggested in the second paragraph.
– Pilot6
Sep 1 '17 at 10:56
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
add a comment |
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.
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran./configure && make && sudo make install
as you suggested in the second paragraph.
– Pilot6
Sep 1 '17 at 10:56
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
add a comment |
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.
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.
answered Sep 1 '17 at 10:53
PsychonautPsychonaut
19314
19314
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran./configure && make && sudo make install
as you suggested in the second paragraph.
– Pilot6
Sep 1 '17 at 10:56
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
add a comment |
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran./configure && make && sudo make install
as you suggested in the second paragraph.
– Pilot6
Sep 1 '17 at 10:56
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran
./configure && make && sudo make install
as you suggested in the second paragraph.– Pilot6
Sep 1 '17 at 10:56
How is this long post related to the question? Did OP try to use autotools? They downloaded some soft and ran
./configure && make && sudo make install
as you suggested in the second paragraph.– Pilot6
Sep 1 '17 at 10:56
3
3
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
It's relevant because the software downloaded by the OP did not contain a correct configure script (and the most recent version in source control, plus the released tarballs, do not contain a configure script at all). Almost all the answers here are telling the OP to run Autotools. While this may work around the problem, it's important to understand the root cause: the developers are the ones responsible for running Autotools, and they haven't done this correctly (or at all).
– Psychonaut
Sep 1 '17 at 11:02
1
1
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
This is a good answer, and although I like the phrase "gently slapped with a wet trout" it might be more appropriate to explicitly mention the the correct response is to report the bug upstream.
– William Pursell
Sep 1 '17 at 14:43
1
1
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
@WilliamPursell I take it the pun is intended. :)
– Psychonaut
Sep 1 '17 at 14:51
add a comment |
I've had this problem, and found it was due to the following line in configure.ac
:
AC_CONFIG_AUX_DIR([build-aux])
The line wasn't bad per se, however it needed to be moved closer to the top of the configure.ac
file.
add a comment |
I've had this problem, and found it was due to the following line in configure.ac
:
AC_CONFIG_AUX_DIR([build-aux])
The line wasn't bad per se, however it needed to be moved closer to the top of the configure.ac
file.
add a comment |
I've had this problem, and found it was due to the following line in configure.ac
:
AC_CONFIG_AUX_DIR([build-aux])
The line wasn't bad per se, however it needed to be moved closer to the top of the configure.ac
file.
I've had this problem, and found it was due to the following line in configure.ac
:
AC_CONFIG_AUX_DIR([build-aux])
The line wasn't bad per se, however it needed to be moved closer to the top of the configure.ac
file.
answered May 2 '16 at 11:29
Craig McQueenCraig McQueen
1477
1477
add a comment |
add a comment |
Please do the following to fix this problem,
sudo apt-get install autogen libtool shtool
Then do the installation
sh autogen.sh --prefix=prefered_install_path
make
make install
add a comment |
Please do the following to fix this problem,
sudo apt-get install autogen libtool shtool
Then do the installation
sh autogen.sh --prefix=prefered_install_path
make
make install
add a comment |
Please do the following to fix this problem,
sudo apt-get install autogen libtool shtool
Then do the installation
sh autogen.sh --prefix=prefered_install_path
make
make install
Please do the following to fix this problem,
sudo apt-get install autogen libtool shtool
Then do the installation
sh autogen.sh --prefix=prefered_install_path
make
make install
edited Nov 3 '16 at 8:13
Evan Carroll
4,789113467
4,789113467
answered Sep 2 '15 at 11:30
Ravi HegdeRavi Hegde
212
212
add a comment |
add a comment |
When trying to compile GNU Octave from Mercurial repository, you may come across this problem. The fix is to run ./bootstrap
while being in the root of the source tree.
add a comment |
When trying to compile GNU Octave from Mercurial repository, you may come across this problem. The fix is to run ./bootstrap
while being in the root of the source tree.
add a comment |
When trying to compile GNU Octave from Mercurial repository, you may come across this problem. The fix is to run ./bootstrap
while being in the root of the source tree.
When trying to compile GNU Octave from Mercurial repository, you may come across this problem. The fix is to run ./bootstrap
while being in the root of the source tree.
answered Mar 22 '17 at 13:45
RuslanRuslan
485717
485717
add a comment |
add a comment |
sudo apt-get install automake autoconf
its works sucessfully
add a comment |
sudo apt-get install automake autoconf
its works sucessfully
add a comment |
sudo apt-get install automake autoconf
its works sucessfully
sudo apt-get install automake autoconf
its works sucessfully
edited Jun 12 '13 at 7:19
Radu Rădeanu
118k35250325
118k35250325
answered Jun 12 '13 at 6:47
Shafiul Karim BulanShafiul Karim Bulan
111
111
add a comment |
add a comment |
I had a similar problem when i tried to ./configure
a source code and got the same error as posted. Finally resolved my issues by entering the code:
sudo apt-get install autotools-dev
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
add a comment |
I had a similar problem when i tried to ./configure
a source code and got the same error as posted. Finally resolved my issues by entering the code:
sudo apt-get install autotools-dev
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
add a comment |
I had a similar problem when i tried to ./configure
a source code and got the same error as posted. Finally resolved my issues by entering the code:
sudo apt-get install autotools-dev
I had a similar problem when i tried to ./configure
a source code and got the same error as posted. Finally resolved my issues by entering the code:
sudo apt-get install autotools-dev
edited Jul 27 '15 at 23:03
answered Feb 9 '13 at 16:35
retnanretnan
276
276
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
add a comment |
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
2
2
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Error: Unable to locate package autotools.
– Mauricio Scheffer
Apr 20 '14 at 1:30
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
Same here. Error: Unable to locate package autotools. Downvoted. Sorry.
– PJunior
Jul 18 '15 at 20:20
add a comment |
After installing autogen
package this error got resolved in wolfSSL
build.
sudo apt-get install autogen libtool shtool
add a comment |
After installing autogen
package this error got resolved in wolfSSL
build.
sudo apt-get install autogen libtool shtool
add a comment |
After installing autogen
package this error got resolved in wolfSSL
build.
sudo apt-get install autogen libtool shtool
After installing autogen
package this error got resolved in wolfSSL
build.
sudo apt-get install autogen libtool shtool
answered 12 mins ago
rashokrashok
1114
1114
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f27677%2fcannot-find-install-sh-install-sh-or-shtool-in-ac-aux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown