Trying to install binutils-gdb

Trying to install binutils-gdb

[jacob navia]

[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]

Hi
I downloaded the new version of binutils.

To my surprise, it doesn’t work any more, failing with a message that I should get the GMP package.

OK. Tried to download GMP. To my surprise, it isn’t a simple tar ball any more. To get the files you need to install a thing called « mercurial » first.

OK, tried to download « mercurial » since GMP can’t use git as almost everybody else does, or at least provide a git version. You have to get « mercurial ».

OK, that did work, and after typing « hg clone… etc » I got at last a version of GMP. There is no configure nor Makefile. You have to run a script called ".bootstrap ». Yes, with a dot as first character so « ls » doesn’t see it. 

The doc in GMP site says:
Once you have your own repository, you need to generate some build files. Perhaps the script .bootstrap works out-of-the box; if it doesn't, you need to install automake (at least version 1.11.6) and autoconf (at least version 2.59) and then try .bootstrap again. You may safely ignore the 4 lines of warnings from libtoolize.

Do not use autoreconf; it will overwrite config.guess which in turn will cause any builds to be awful.

OK, I started « .bootstrap » and obtained:
./.bootstrap: 7: autoreconf: not found
cp: cannot stat 'ltmain.sh': No such file or directory
rm: cannot remove 'ltmain.sh': No such file or directory
mv: cannot stat 'foo': No such file or directory
cp: cannot stat 'ylwrap': No such file or directory
rm: cannot remove 'ylwrap': No such file or directory
mv: cannot stat 'foo': No such file or directory
cp: cannot stat 'install-sh': No such file or directory
rm: cannot remove 'install-sh': No such file or directory
mv: cannot stat 'foo': No such file or directory
cp: cannot stat 'missing': No such file or directory
rm: cannot remove 'missing': No such file or directory
mv: cannot stat 'foo': No such file or directory
cp: cannot stat 'test-driver': No such file or directory
rm: cannot remove 'test-driver': No such file or directory
mv: cannot stat 'foo': No such file or directory

I do not understand why they do not want us to use autoreconf and the first thing that THEIR script does is… to call « autoreconf ». Luckily it wasn’t found!
Now I have to download automake and autoconf. Just like that.

Why do I need to do all this just to compile binutils? Can’t this complexifying stop somewhere? Why binutils needs GMP now???
And if that is necessary, why can’t we get some version of GMP that ships with the source of binutils WITHOUT requiring that all users of binutils download mercurial, automake and autoconf???

Why can’t we keep things simple?

Here are the first 7 lines of the .bootstrap shell script
  1 #! /bin/sh                                                                              
  2 
  3 # We need to remove the "cache", else things are not regenerated properly
  4 rm -rf autom4te.cache
  5 
  6 # for warnings, add: -v -W all
  7 autoreconf -i -s

So, they tell people not to use autoreconf???

Well all this things aren’t important, just a decision (that is nowhere explained or justified) that makes everything more complicated for everyone.

Jacob

Re: Trying to install binutils-gdb

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3830 bytes --]


jacob navia <jacob@jacob.remcomp.fr> writes:

> Hi
> I downloaded the new version of binutils.
>
> To my surprise, it doesn’t work any more, failing with a message that I should get the GMP package.
>
> OK. Tried to download GMP. To my surprise, it isn’t a simple tar ball any
> more. To get the files you need to install a thing called « mercurial » first.

It is.  In fact, that is the first link on the GMP page under Download.
https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz

> OK, tried to download « mercurial » since GMP can’t use git as almost everybody
> else does, or at least provide a git version. You have to get « mercurial ».
>
> OK, that did work, and after typing « hg clone… etc » I got at last a version
> of GMP. There is no configure nor Makefile. You have to run a script called
> ".bootstrap ». Yes, with a dot as first character so « ls » doesn’t see it.
>
> The doc in GMP site says:
> Once you have your own repository, you need to generate some build
> files. Perhaps the script .bootstrap works out-of-the box; if it doesn't, you
> need to install automake (at least version 1.11.6) and autoconf (at least
> version 2.59) and then try .bootstrap again. You may safely ignore the 4 lines
> of warnings from libtoolize.
>
> Do not use autoreconf; it will overwrite config.guess which in turn will cause any builds to be awful.
>
> OK, I started « .bootstrap » and obtained:
> ./.bootstrap: 7: autoreconf: not found
> cp: cannot stat 'ltmain.sh': No such file or directory
> rm: cannot remove 'ltmain.sh': No such file or directory
> mv: cannot stat 'foo': No such file or directory
> cp: cannot stat 'ylwrap': No such file or directory
> rm: cannot remove 'ylwrap': No such file or directory
> mv: cannot stat 'foo': No such file or directory
> cp: cannot stat 'install-sh': No such file or directory
> rm: cannot remove 'install-sh': No such file or directory
> mv: cannot stat 'foo': No such file or directory
> cp: cannot stat 'missing': No such file or directory
> rm: cannot remove 'missing': No such file or directory
> mv: cannot stat 'foo': No such file or directory
> cp: cannot stat 'test-driver': No such file or directory
> rm: cannot remove 'test-driver': No such file or directory
> mv: cannot stat 'foo': No such file or directory
>
> I do not understand why they do not want us to use autoreconf and the first
> thing that THEIR script does is… to call « autoreconf ». Luckily it wasn’t
> found!
> Now I have to download automake and autoconf. Just like that.
>
> Why do I need to do all this just to compile binutils? Can’t this
> complexifying stop somewhere? Why binutils needs GMP now???

They don't.  I'm not sure where you got that.  GDB requires GMP, though.

I assume you downloaded a distribution that contains both Binutils and
GDB.  You can pass --disable-gdb.

> And if that is necessary, why can’t we get some version of GMP that ships with
> the source of binutils WITHOUT requiring that all users of binutils download
> mercurial, automake and autoconf???
>
> Why can’t we keep things simple?
>
> Here are the first 7 lines of the .bootstrap shell script
>   1 #! /bin/sh                                                                              
>   2 
>   3 # We need to remove the "cache", else things are not regenerated properly
>   4 rm -rf autom4te.cache
>   5 
>   6 # for warnings, add: -v -W all
>   7 autoreconf -i -s
>
> So, they tell people not to use autoreconf???

Due to the cache workaround, presumably.

> Well all this things aren’t important, just a decision (that is nowhere
> explained or justified) that makes everything more complicated for everyone.
>
> Jacob

Hope that helps, have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Trying to install binutils-gdb

[Nick Clifton]

Hi Jacob,

> I downloaded the new version of binutils.
> To my surprise, it doesn’t work any more, failing with a message that I should get the GMP package.

This is really a documentation issue.  I assume that you
were following the instructions in the binutils/README file
on how to unpack and install the binutils ?  I am thinking
of changing that section of the file to read like this:

-------------------------------------------------------------
[...]
   To build binutils you will need a C99 compliant compiler and library.
   You can just do:

	cd binutils-XXX
	./configure [various options, see below]
	make
	make install # copies the programs files into /usr/local/bin
		     # by default.

   This will configure and build all the libraries as well as the
   assembler, the binutils, and the linker.

   If you only want to build the binutils and not GDB as well then
   you can add a configure option to disable GDB.  This may help
   reduce the need for extra libraries to be installed.  ie:

	./configure --disable-gdb

   Since the configure script can be quite verbose, you may also
   like to add the --quiet option to reduce the amount of output. ie:

	./configure --quiet

   If you have GNU make, we recommend building in a different directory:
[...]
---------------------------------------------------------------------------

   Would this help ?

Cheers
   Nick

Re: Trying to install binutils-gdb

[Hans-Peter Nilsson]

On Wed, 27 Sep 2023, Nick Clifton via Binutils wrote:

> Hi Jacob,
> 
> > I downloaded the new version of binutils.
> > To my surprise, it doesn?t work any more, failing with a message that I
> > should get the GMP package.
> 
> This is really a documentation issue.  I assume that you
> were following the instructions in the binutils/README file
> on how to unpack and install the binutils ?  I am thinking
> of changing that section of the file to read like this:
> 
> -------------------------------------------------------------
> [...]

>   To build binutils you will need a C99 compliant compiler and library.
>   You can just do:

This text continues a section that describes how to build from a 
source *tarball*; the "Unpacking and installation" and "When you 
unpack the binutils archive file..."

>   If you only want to build the binutils and not GDB as well then
>   you can add a configure option to disable GDB.  This may help
>   reduce the need for extra libraries to be installed.  ie:
> 
> 	./configure --disable-gdb

...so this step would then be confusing.

IMHO it needs to say something like "if you build from a 
checkout of the binutils-gdb git, you may also want to build 
only binutils and exclude gdb, like so:" [...]

brgds, H-P

Re: Trying to install binutils-gdb

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Hi Guys,

On 9/28/23 01:42, Hans-Peter Nilsson wrote:
> This text continues a section that describes how to build from a
> source *tarball*; the "Unpacking and installation" and "When you
> unpack the binutils archive file..."
> 
>>    If you only want to build the binutils and not GDB as well then
>>    you can add a configure option to disable GDB.  This may help
>>    reduce the need for extra libraries to be installed.  ie:
>>
>> 	./configure --disable-gdb
> 
> ...so this step would then be confusing.
> 
> IMHO it needs to say something like "if you build from a
> checkout of the binutils-gdb git, you may also want to build
> only binutils and exclude gdb, like so:" [...]

That makes sense.  I have checked in the following updated patch instead.

Cheers
   Nick


[-- Attachment #2: README.patch --]
[-- Type: text/x-patch, Size: 1960 bytes --]

diff --git a/binutils/README b/binutils/README
index 5120503b80f..82ebd5e774c 100644
--- a/binutils/README
+++ b/binutils/README
@@ -2,12 +2,12 @@
 
 These are the GNU binutils.  These are utilities of use when dealing
 with binary files, either object files or executables.  These tools
-consist of the linker (ld), the assembler (gas), and the profiler
-(gprof) each of which have their own sub-directory named after them.
-There is also a collection of other binary tools, including the
-disassembler (objdump) in this directory.  These tools make use of a
-pair of libraries (bfd and opcodes) and a common set of header files
-(include).
+consist of the linkers (ld and gold), the assembler (gas), and the
+profiler (gprof and gprofng) each of which have their own
+sub-directory named after them.  There is also a collection of other
+binary tools, including the disassembler (objdump) in this directory.
+These tools make use of a pair of libraries (bfd and opcodes) and a
+common set of header files (include).
 
 There are README and NEWS files in most of the program sub-directories
 which give more information about those specific programs.
@@ -44,6 +44,20 @@ You can just do:
 This will configure and build all the libraries as well as the
 assembler, the binutils, and the linker.
 
+Note - if you have obtained the sources by checking out a copy from
+the git repository then you will have both the binutils and GDB
+sources in one place.  In this case you may wish to add an option to
+the configure command line to stop it from configuring GDB.  This will
+also stop the configure script from checking the libraries that are
+needed by GDB, but not by the binutils.
+
+	./configure --disable-gdb 
+
+Since the configure script can be quite verbose, you may also
+want to add the --quiet option to reduce the amount of output. ie:
+
+	./configure --quiet
+
 If you have GNU make, we recommend building in a different directory:
 
 	mkdir objdir

Re: Trying to install binutils-gdb

[Maciej W. Rozycki]

On Fri, 29 Sep 2023, Nick Clifton via Binutils wrote:

> > >    If you only want to build the binutils and not GDB as well then
> > >    you can add a configure option to disable GDB.  This may help
> > >    reduce the need for extra libraries to be installed.  ie:
> > > 
> > > 	./configure --disable-gdb
> > 
> > ...so this step would then be confusing.
> > 
> > IMHO it needs to say something like "if you build from a
> > checkout of the binutils-gdb git, you may also want to build
> > only binutils and exclude gdb, like so:" [...]
> 
> That makes sense.  I have checked in the following updated patch instead.

 I have only come across this message now.

 Note that nowadays we have other GDB components at the top level, most 
notably `gdbserver', as well as the GNU simulator, all of which are a part 
of the GDB project.  So to build parts that comprise binutils only from a 
git checkout you really need to disable more, such as with:

$ ./configure --disable-gdb --disable-gdbserver --disable-libbacktrace \
  --disable-libdecnumber --disable-readline --disable-sim

This is what I have been doing with my builds.

 I'll be happy to offer a patch if this turns out how we want to update 
binutils/README further, however it seems to me that we probably want to 
have a pair of umbrella options, say `--disable-gdb-components' and 
`--disable-binutils-components', to let people choose more easily what 
project they want to build from a checkout without the need to dive into 
individual components and also possibly without having to keep track of 
what new components get added as they upgrade.  There'd be a slight 
maintenance burden for such options though.

 Cc-ing the GDB mailing list for any input from the other camp.

  Maciej

Re: Trying to install binutils-gdb

[Guinevere Larsen]

On 28/01/2024 20:30, Maciej W. Rozycki wrote:
> On Fri, 29 Sep 2023, Nick Clifton via Binutils wrote:
>
>>>>     If you only want to build the binutils and not GDB as well then
>>>>     you can add a configure option to disable GDB.  This may help
>>>>     reduce the need for extra libraries to be installed.  ie:
>>>>
>>>> 	./configure --disable-gdb
>>> ...so this step would then be confusing.
>>>
>>> IMHO it needs to say something like "if you build from a
>>> checkout of the binutils-gdb git, you may also want to build
>>> only binutils and exclude gdb, like so:" [...]
>> That makes sense.  I have checked in the following updated patch instead.
>   I have only come across this message now.
>
>   Note that nowadays we have other GDB components at the top level, most
> notably `gdbserver', as well as the GNU simulator, all of which are a part
> of the GDB project.  So to build parts that comprise binutils only from a
> git checkout you really need to disable more, such as with:
>
> $ ./configure --disable-gdb --disable-gdbserver --disable-libbacktrace \
>    --disable-libdecnumber --disable-readline --disable-sim
>
> This is what I have been doing with my builds.
>
>   I'll be happy to offer a patch if this turns out how we want to update
> binutils/README further, however it seems to me that we probably want to
> have a pair of umbrella options, say `--disable-gdb-components' and
> `--disable-binutils-components', to let people choose more easily what
> project they want to build from a checkout without the need to dive into
> individual components and also possibly without having to keep track of
> what new components get added as they upgrade.  There'd be a slight
> maintenance burden for such options though.

yes please!

I can never remember all the components that I need to disable from 
binutils to get as quick a compilation as possible. I am still not sure 
if I did disable everything or if copying my previous configure run 
isn't accidentally building some parts unnecessarily. I'm not sure if I 
personally like the `-components` suffix, but I don't have any better 
suggestions.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>   Cc-ing the GDB mailing list for any input from the other camp.
>
>    Maciej
>

Re: Trying to install binutils-gdb

[Nick Clifton]

Hi Maciej,

> $ ./configure --disable-gdb --disable-gdbserver --disable-libbacktrace \
>    --disable-libdecnumber --disable-readline --disable-sim
> 
> This is what I have been doing with my builds.
> 
>   I'll be happy to offer a patch if this turns out how we want to update
> binutils/README further,

I think that that would be a good idea, at least until your suggestion
below is implemented.

> however it seems to me that we probably want to
> have a pair of umbrella options, say `--disable-gdb-components' and
> `--disable-binutils-components', to let people choose more easily what
> project they want to build from a checkout without the need to dive into
> individual components and also possibly without having to keep track of
> what new components get added as they upgrade.  There'd be a slight
> maintenance burden for such options though.

To make things simpler, I think that it might be better to have users
'enable' the tool that they want.  ie:

   "configure --enable-gdb"        just configure gdb and friends
   "configure --enable-binutils"   just configures the binutils stuff

We might even make it so that if neither of these options are given then
configure prints: "configuring both GDB and BINUTILS, is this really what you want ?"
or something like that.

Cheers
   Nick