gcc creates binaries that don't find their shared libraries

  • Done
  • quality assurance status badge
Details
5 participants
  • Bruno Haible
  • Danny Milosavljevic
  • Ludovic Courtès
  • Nicolas Goaziou
  • zimoun
Owner
unassigned
Submitted by
Bruno Haible
Severity
normal
B
B
Bruno Haible wrote on 3 May 2020 01:55
(address . bug-guix@gnu.org)
1928431.D5bU72YO8c@omega
Hi,

I'm using the recent guix-system-vm-image-1.1.0.x86_64-linux.

After installing a couple of package for development
$ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake
I expected to be able to build GNU bison 3.5.91 from source. But I hit a build
failure, due to a program being linked against a shared library that cannot be
found.

How to reproduce (simple test case):
----------------
$ tar xfz gettext-0.20.1.tar.gz
$ cd gettext-0.20.1/libtextstyle/examples/color-hello
$ ./autogen.sh
$ ./configure
...
checking how to link with libtextstyle... -ltextstyle
...
$ make
...
gcc -g -O2 -o hello hello.o -ltextstyle
$ ./hello
./hello: error while loading shared libraries: libtextstyle.so.0: cannot open shared object file: No such file or directory
$ ldd hello
...
libtextstyle.so.0 => not found
...


Discussion
----------

For packages *installed by the user*, the configure test has
code to add -Wl,-rpath,DIR options for appropriate directories.

However, here, the library has been installed by the system (through
'guix install gettext'). It appears that gcc, when searching for the
library, finds it. Whereas the dynamic loader (ld-linux-x86-64.so.2)
apparently does not find it.

It should be GCC's job to create binaries that work, when all
referenced libraries are system libraries. The ELF file format and
dynamic loader have enough facilities to make this possible (-Wl,-rpath
option, ld.so.conf, ld.so.cache).


Bruno
L
L
Ludovic Courtès wrote on 3 May 2020 23:07
(name . Bruno Haible)(address . bruno@clisp.org)(address . 41038@debbugs.gnu.org)
87ftcgviax.fsf@gnu.org
Hi,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (2 lines)
> $ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake

It’s a mistake to explicitly binutils and glibc: they are provided by
‘gcc-toolchain’ along with an ‘ld’ wrapper that takes care of adding
entries to the RUNPATH of binaries:


‘binutils’ shadowed that wrapper. I admit what you did looks perfectly
legit at first sight and the failure mode isn’t great.

The fix is to run:

guix remove glibc binutils

Another way to do software development is with ‘guix environment’:


For example, if you want to hack on Gettext, run:

guix environment gettext

That spawns a shell containing all the development tools and environment
variables to hack on gettext.

HTH!

Ludo’.
D
D
Danny Milosavljevic wrote on 4 May 2020 00:12
(name . Bruno Haible)(address . bruno@clisp.org)(address . 41038@debbugs.gnu.org)
20200504001203.74597aad@scratchpost.org
Hi Bruno,

On Sun, 03 May 2020 01:55:00 +0200
Bruno Haible <bruno@clisp.org> wrote:

Toggle quote (6 lines)
> $ make
> ...
> gcc -g -O2 -o hello hello.o -ltextstyle
> $ ./hello
> ./hello: error while loading shared libraries: libtextstyle.so.0: cannot open shared object file: No such file or directory

I remember being tripped up by this when I started using Guix. It is annoying.

I wonder if it's possible to instruct gcc (or ld, I guess) to automatically
add rpath to where it found the respective library. That's really what we
expect to happen in Guix.

Ugly workaround:

$ tar xfz gettext-0.20.1.tar.gz
$ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake
# or better: guix environment --pure --ad-hoc gcc-toolchain make coreutils binutils glibc gdb gettext m4 autoconf automake sed grep gawk
(env)$ cd gettext-0.20.1/libtextstyle/examples/color-hello
(env)$ ./autogen.sh
(env)$ export LDFLAGS=-Wl,-rpath=`echo $LIBRARY_PATH | sed -e 's;:; -Wl,-rpath=;g'`
(env)$ ./configure
(env)$ make
exit
$ ./hello
Hello

But unfortunately, Makefiles are not standardized in how to add linker
flags--so it's not easy to find out how to do that in general.

The above does work for gettext.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl6vQbMACgkQ5xo1VCww
uqWIQgf/SK2T4RQbMs739WWdMpu7Q7DSmO0Zy+b0Kvf8VG5OuCYNCB8VfDGwNrhw
LCr+vq6Y+JWT45mGvCWjZXASZkdS/ZS8Z7JY+7JaLkHJooZUuKtkDaHEQtp8ppaI
us2EspsdeR/b6grGA/zugdW+4cOEb6CMMogeL1ZuTlJJTIWKN6EKD/R790uahk5A
wiokNqM7xFXnzS0EGK0I+y0avDiW3nOF8zkOepOLj4fI7pOsNPRBjc/GjZ1ntS+X
+ZN5Etc7npTcYRi+Nnxt+87UbXw6hPxiqjuMuKSrOSOdOIvpzt2RrOxQgY6atY/i
NXLen8wfWlKcp+DSK9TYc7XmIUsSww==
=hBch
-----END PGP SIGNATURE-----


B
B
Bruno Haible wrote on 4 May 2020 01:09
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41038@debbugs.gnu.org)
2050118.Ql0zV9tn6O@omega
Hi Ludo,

Toggle quote (15 lines)
> > $ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf automake
>
> It’s a mistake to explicitly binutils and glibc: they are provided by
> ‘gcc-toolchain’ along with an ‘ld’ wrapper that takes care of adding
> entries to the RUNPATH of binaries:
>
> https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain
>
> ‘binutils’ shadowed that wrapper. I admit what you did looks perfectly
> legit at first sight and the failure mode isn’t great.
>
> The fix is to run:
>
> guix remove glibc binutils

This does fix it, thank you.

The question "What packages do I need to do normal C development?" should
really be documented.

How about a doc section - at the beginning of the chapter

Packages needed for C development
=================================

For C development, you will typically need the packages
make gcc-toolchain gdb

Do NOT install glibc and binutils explicitly, as they would shadow
the 'ld' wrapper that is necessary for proper operation of GCC.

Additionally, the documentation page
starts with the sentence
"When using Guix on top of GNU/Linux distribution other than Guix System ..."
but then the majority of the page applies to native Guix as well.
How about restructuring this documentation chapter into two pages:
- one that explains things valid about Guix in general,
- one that covers only the foreign-distro topics.

Toggle quote (11 lines)
> Another way to do software development is with ‘guix environment’:
>
> https://guix.gnu.org/manual/en/html_node/Development.html
>
> For example, if you want to hack on Gettext, run:
>
> guix environment gettext
>
> That spawns a shell containing all the development tools and environment
> variables to hack on gettext.

Sounds very interesting. But for the moment, I use guix only as a
test platform.

Bruno
Z
Z
zimoun wrote on 4 May 2020 10:50
(name . Bruno Haible)(address . bruno@clisp.org)
CAJ3okZ2byK8EXghs453Zy=+gLYemLAgcM+DGG14MgQ3sSOWtkg@mail.gmail.com
Dear Bruno,

Thank you for your feedback.


On Mon, 4 May 2020 at 01:10, Bruno Haible <bruno@clisp.org> wrote:

Toggle quote (14 lines)
> > Another way to do software development is with ‘guix environment’:
> >
> > https://guix.gnu.org/manual/en/html_node/Development.html
> >
> > For example, if you want to hack on Gettext, run:
> >
> > guix environment gettext
> >
> > That spawns a shell containing all the development tools and environment
> > variables to hack on gettext.
>
> Sounds very interesting. But for the moment, I use guix only as a
> test platform.

Note that Guix (as package manager) provides 3 nice features for
development as a test platform: manifest, profile and channel.

1. Manifests allow you to specify the packages you want to install.
For example, this command installs make, gcc-toolchain and gdb in the
default profile (~/.guix-profile).

guix package -m /path/to/my/manifest.scm

Toggle snippet (4 lines)
(specifications->manifest
'("make" "gcc-toolchain" "gdb"))

And note that "version" or "outputs" (debug) can be specified. Well,
manifest can be used with almost all the Guix commands. And manifests
compose: "-m m1.scm -m m2.scm".



2. Profiles allow different versions of the same tool without any
conflict. For example, let consider you would like to develop using
GCC@9 for one project and GCC@8 for another; then:

guix install gcc-toolchain@9 -p /path/to/my/gcc-9
guix install gcc-toolchain@8 -p /path/to/my/gcc-8

Then, for example let prepend the environment variables defined by the
packages gcc-toolchain@9.

eval `guix package --search-paths=prefix -p /path/to/gcc-9`
which gcc

Note that profiles compose too (see --allow-collisions; warning).
Moreover, the regular packages used to develop need time to time to be
temporary extended; without being really "installed":

guix environment -m /path/to/my/manifest-dev-9.scm --ad-hoc libfoo

And options like '--pure' or '--container' are very useful for
testing. And when finished, 'libfoo' becomes a dead link in the store
(guix gc --list-dead) and so would be garbage collected if needed; the
command "guix environment" is very handy when testing and developing,
iMHO.


3. Channels allow to track the exact version of the tools. For
example, the version used:

guix describe -f channels > /path/to/my/channel.scm

Then weeks (or month) or on another machine, it is possible to
re-install the same packages, for example:

guix pull -C /path/to/my/channel.scm
guix package -m /path/to/my/manifest.scm -p /path/to/my/olds

Note that it is not necessary required to pull back at one specific
Guix version for re-installing packages of this very specific Guix
version. It is possible to temporarily re-state another Guix version
without modifying the current one (see Inferior):

guix time-machine -C /path/to/my/channel.scm \
-- package -m /path/to/my/manifest.scm -p /path/to/my/olds

This is equivalent to the 2 commands above but without "updating" the
current Guix.


I do not know if it is useful. Or if it helps to describe Guix as a
test platform. The manual is hairy -- from my point of view -- and
because Guix re-frames good ol' concepts, it is not easy to find the
way.

Best regards,
simon
Z
Z
zimoun wrote on 4 May 2020 11:06
(name . Bruno Haible)(address . bruno@clisp.org)
CAJ3okZ21BJTdJ2DxMOZuxssSDJ0FaC=2PYO7+94zFH9jY+JZsA@mail.gmail.com
Dear Ludo and Bruno,

On Mon, 4 May 2020 at 01:10, Bruno Haible <bruno@clisp.org> wrote:

Toggle quote (15 lines)
> The question "What packages do I need to do normal C development?" should
> really be documented.
>
> How about a doc section - at the beginning of the chapter
> https://guix.gnu.org/manual/en/html_node/Development.html - that says:
>
> Packages needed for C development
> =================================
>
> For C development, you will typically need the packages
> make gcc-toolchain gdb
>
> Do NOT install glibc and binutils explicitly, as they would shadow
> the 'ld' wrapper that is necessary for proper operation of GCC.

Does it make sense to provide example/sample of manifests for
developing in the main languages?
And add advices in the manual? For example:

guix package -m /etc/guix/minimal-opinionated-tools-for-C.scm
guix package -m /etc/guix/minimal-opinionated-tools-for-Python.scm

Well, I do not know what the correct location for such "examples"
files. Folder /etc/? Other?
And with a better name than "minimal-opinionated-tools-for-".

WDYT?


All the best,
simon
L
L
Ludovic Courtès wrote on 4 May 2020 11:30
(name . Bruno Haible)(address . bruno@clisp.org)(address . 41038@debbugs.gnu.org)
87y2q8rqr8.fsf@gnu.org
Hi,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (15 lines)
> The question "What packages do I need to do normal C development?" should
> really be documented.
>
> How about a doc section - at the beginning of the chapter
> https://guix.gnu.org/manual/en/html_node/Development.html - that says:
>
> Packages needed for C development
> =================================
>
> For C development, you will typically need the packages
> make gcc-toolchain gdb
>
> Do NOT install glibc and binutils explicitly, as they would shadow
> the 'ld' wrapper that is necessary for proper operation of GCC.

Good idea, I did something along these lines:


Toggle quote (9 lines)
> Additionally, the documentation page
> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
> starts with the sentence
> "When using Guix on top of GNU/Linux distribution other than Guix System ..."
> but then the majority of the page applies to native Guix as well.
> How about restructuring this documentation chapter into two pages:
> - one that explains things valid about Guix in general,
> - one that covers only the foreign-distro topics.

The locale and nscd bits are foreign-distro-specific, but the for the
rest I agree that something needs to be done.

Thanks for your feedback!

Ludo’.
Z
Z
zimoun wrote on 4 May 2020 11:59
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ1RMqGzv9bB_chOr+zCXLz3b8R1cUO-T-O9Ag5NAqBp4Q@mail.gmail.com
Hi Ludo,

On Mon, 4 May 2020 at 11:32, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (13 lines)
> > Packages needed for C development
> > =================================
> >
> > For C development, you will typically need the packages
> > make gcc-toolchain gdb
> >
> > Do NOT install glibc and binutils explicitly, as they would shadow
> > the 'ld' wrapper that is necessary for proper operation of GCC.
>
> Good idea, I did something along these lines:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1f14e25c1969a93908288cb302a572f3cbbaa478

Compiling Fortran leads to the same issue, if I understand correctly.
Is it not the reason of the addition of 'gfortran-toolchain'?
And I guess it should be the same issue for the other front-ends that
GCC supports (Ada, etc.), isn't it?

Well, is it not GCC related and not only C specific?

I mean, I seems better to me to remove "@subsection The GCC toolchain"
from "Application setup" and then to retitle the subsection "The GCC
toolchain" in "Development" instead of "Packages for C Development".
Keeping for now how it is worded and letting the GFortran use case as
an exercise for the reader. ;-)


All the best,
simon
L
L
Ludovic Courtès wrote on 4 May 2020 21:52
(name . zimoun)(address . zimon.toutoune@gmail.com)
87eerzqxym.fsf@gnu.org
Hello,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (13 lines)
> Compiling Fortran leads to the same issue, if I understand correctly.
> Is it not the reason of the addition of 'gfortran-toolchain'?
> And I guess it should be the same issue for the other front-ends that
> GCC supports (Ada, etc.), isn't it?
>
> Well, is it not GCC related and not only C specific?
>
> I mean, I seems better to me to remove "@subsection The GCC toolchain"
> from "Application setup" and then to retitle the subsection "The GCC
> toolchain" in "Development" instead of "Packages for C Development".
> Keeping for now how it is worded and letting the GFortran use case as
> an exercise for the reader. ;-)

True! Do you want to send a patch? :-)

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 5 May 2020 11:30
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
87mu6mn2yp.fsf@gnu.org
Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (6 lines)
> I remember being tripped up by this when I started using Guix. It is annoying.
>
> I wonder if it's possible to instruct gcc (or ld, I guess) to automatically
> add rpath to where it found the respective library. That's really what we
> expect to happen in Guix.

See the comment at the top of ld-wrapper.in. I tried hard to avoid
having a wrapper at all but came to the conclusion that this was the
best we could do (it’s already better than what Nixpkgs did/does, which
is to wrap the whole compiler).

Thanks,
Ludo’.
B
B
Bruno Haible wrote on 5 May 2020 13:17
(name . Ludovic Courtès)(address . ludo@gnu.org)
2182276.0QAfrSD9Gv@omega
Ludovic Courtès wrote:
Toggle quote (4 lines)
> I tried hard to avoid
> having a wrapper at all but came to the conclusion that this was the
> best we could do

Can something be done to avoid that installing the packages 'glibc' and
'binutils' shadows this wrapper?

Maybe moving the wrapper to a different package than it is now?

Or adding specific metainformation to some packages?

Bruno
L
L
Ludovic Courtès wrote on 5 May 2020 21:34
control message for bug #41038
(address . control@debbugs.gnu.org)
874ksukwfq.fsf@gnu.org
tags 41038 notabug
close 41038
quit
Z
Z
zimoun wrote on 6 May 2020 19:42
[PATCH] doc: Reword "The GCC toolchain".
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ2AYjiFRZnr1VZo+_OOjysEgwcZWwJo9hjmBe15ayc=8A@mail.gmail.com
Hi Ludo

On Mon, 4 May 2020 at 21:52, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (2 lines)
> True! Do you want to send a patch? :-)

See attached. Feel free to reword the commit message if it is not
compliant with the standard.


Cheers,
simon
From cefffd56f8363b45f3593814ec296015906854b4 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Wed, 6 May 2020 19:26:05 +0200
Subject: [PATCH] doc: Reword "The GCC toolchain".

Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478

* doc/guix.texi (Packages for C Development): Rename to...
(The GCC toolchain): ...this. Add gfortran-toolchain.
(Invoking guix package): Add guix-search anchor.
(Application Setup)[The GCC toolchain]: Remove.
---
doc/guix.texi | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)

Toggle diff (78 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index bc5ecbbcde..5b56ae757d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -228,6 +228,7 @@ Development
* Invoking guix environment:: Setting up development environments.
* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
Programming Interface
@@ -1767,13 +1768,6 @@ want to avoid auto-loading the Emacs packages installed with Guix, you
can do so by running Emacs with the @code{--no-site-file} option
(@pxref{Init File,,, emacs, The GNU Emacs Manual}).
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros. Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
@node Upgrading Guix
@section Upgrading Guix
@@ -3039,6 +3033,7 @@ availability of packages:
@item --search=@var{regexp}
@itemx -s @var{regexp}
+@anchor{guix-search}
@cindex searching for packages
List the available packages whose name, synopsis, or description matches
@var{regexp} (in a case-insensitive fashion), sorted by relevance.
@@ -4669,9 +4664,9 @@ pack} command allows you to create @dfn{application bundles} that can be
easily distributed to users who do not run Guix.
@menu
-* Invoking guix environment:: Setting up development environments.
-* Invoking guix pack:: Creating software bundles.
-* Packages for C Development:: Working with C code with Guix.
+* Invoking guix environment:: Setting up development environments.
+* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
@end menu
@node Invoking guix environment
@@ -5335,13 +5330,15 @@ In addition, @command{guix pack} supports all the common build options
(@pxref{Common Build Options}) and all the package transformation
options (@pxref{Package Transformation Options}).
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
@cindex GCC
@cindex ld-wrapper
@cindex linker wrapper
@cindex toolchain, for C development
+@cindex toolchain, for Fortran development
If you need a complete toolchain for compiling and linking C or C++
source code, use the @code{gcc-toolchain} package. This package
@@ -5355,7 +5352,9 @@ invoke the actual linker with this new set of arguments. You can instruct the
wrapper to refuse to link against libraries not in the store by setting the
@code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
-
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development. For other languages, please use
+@command{guix search gcc toolchain} (see @pxref{guix-search,, Invoking guix package}).
@c *********************************************************************
@node Programming Interface
--
2.26.1
Z
Z
zimoun wrote on 15 May 2020 18:59
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41038@debbugs.gnu.org)
CAJ3okZ3bvNarMrRAnLbcWQJMf-4kQo0KE7RBBOfzR6Meo6R6Rg@mail.gmail.com
Hi Ludo,

Friendly ping to avoid the tiny patch falls in the cracks.

Thanks,
simon
N
N
Nicolas Goaziou wrote on 15 May 2020 21:42
(name . zimoun)(address . zimon.toutoune@gmail.com)
873681x9wm.fsf@nicolasgoaziou.fr
Hello,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (3 lines)
> See attached. Feel free to reword the commit message if it is not
> compliant with the standard.

I have two minor comments about it.

Toggle quote (4 lines)
> +The package @code{gfortran-toolchain} provides a complete GCC toolchain
> +for Fortran development. For other languages, please use
> +@command{guix search gcc toolchain}

Nitpick: I know there is plenty of this in the manual, but I suggest to
use @samp{guix ...}, not @command{...}.

Toggle quote (2 lines)
> (see @pxref{guix-search,, Invoking guix package}).

You need to remove the "see ":

(@pxref{...})


Regards,

--
Nicolas Goaziou
Z
Z
zimoun wrote on 16 May 2020 16:57
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAJ3okZ35qSS21_E0pdhT9SVV7xUibobzhXmNYtt+9ESjxr=gww@mail.gmail.com
Hi Nicolas,

Thank you for the review. Attached the updated patch.

On Fri, 15 May 2020 at 21:42, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

Toggle quote (7 lines)
> > +The package @code{gfortran-toolchain} provides a complete GCC toolchain
> > +for Fortran development. For other languages, please use
> > +@command{guix search gcc toolchain}
>
> Nitpick: I know there is plenty of this in the manual, but I suggest to
> use @samp{guix ...}, not @command{...}.

I did not know the difference. Thank you for the nitpick.



All the best,
simon
From efbc579a8884235ac37833ea6ee6fa454110c080 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Wed, 6 May 2020 19:26:05 +0200
Subject: [PATCH v2] doc: Reword "The GCC toolchain".

Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478

* doc/guix.texi (Packages for C Development): Rename to...
(The GCC toolchain): ...this. Add gfortran-toolchain.
(Invoking guix package): Add guix-search anchor.
(Application Setup)[The GCC toolchain]: Remove.
---
doc/guix.texi | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)

Toggle diff (78 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index 90324ce291..22bf6bd224 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -228,6 +228,7 @@ Development
* Invoking guix environment:: Setting up development environments.
* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
Programming Interface
@@ -1773,13 +1774,6 @@ want to avoid auto-loading the Emacs packages installed with Guix, you
can do so by running Emacs with the @option{--no-site-file} option
(@pxref{Init File,,, emacs, The GNU Emacs Manual}).
-@subsection The GCC toolchain
-
-@c XXX: The contents of this section were moved under
-@c ``Development'', since it makes more sense there and is not specific
-@c foreign distros. Remove it from here eventually?
-@xref{Packages for C Development}, for information on packages for C/C++
-development.
@node Upgrading Guix
@section Upgrading Guix
@@ -3045,6 +3039,7 @@ availability of packages:
@item --search=@var{regexp}
@itemx -s @var{regexp}
+@anchor{guix-search}
@cindex searching for packages
List the available packages whose name, synopsis, or description matches
@var{regexp} (in a case-insensitive fashion), sorted by relevance.
@@ -4675,9 +4670,9 @@ pack} command allows you to create @dfn{application bundles} that can be
easily distributed to users who do not run Guix.
@menu
-* Invoking guix environment:: Setting up development environments.
-* Invoking guix pack:: Creating software bundles.
-* Packages for C Development:: Working with C code with Guix.
+* Invoking guix environment:: Setting up development environments.
+* Invoking guix pack:: Creating software bundles.
+* The GCC toolchain:: Working with languages supported by GCC.
@end menu
@node Invoking guix environment
@@ -5388,13 +5383,15 @@ In addition, @command{guix pack} supports all the common build options
(@pxref{Common Build Options}) and all the package transformation
options (@pxref{Package Transformation Options}).
-@node Packages for C Development
-@section Packages for C Development
+
+@node The GCC toolchain
+@section The GCC toolchain
@cindex GCC
@cindex ld-wrapper
@cindex linker wrapper
@cindex toolchain, for C development
+@cindex toolchain, for Fortran development
If you need a complete toolchain for compiling and linking C or C++
source code, use the @code{gcc-toolchain} package. This package
@@ -5408,7 +5405,9 @@ invoke the actual linker with this new set of arguments. You can instruct the
wrapper to refuse to link against libraries not in the store by setting the
@env{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
-
+The package @code{gfortran-toolchain} provides a complete GCC toolchain
+for Fortran development. For other languages, please use
+@samp{guix search gcc toolchain} (@pxref{guix-search,, Invoking guix package}).
@c *********************************************************************
@node Programming Interface
--
2.26.1
L
L
Ludovic Courtès wrote on 16 May 2020 17:19
(name . zimoun)(address . zimon.toutoune@gmail.com)
87o8qnsy91.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (13 lines)
> From efbc579a8884235ac37833ea6ee6fa454110c080 Mon Sep 17 00:00:00 2001
> From: zimoun <zimon.toutoune@gmail.com>
> Date: Wed, 6 May 2020 19:26:05 +0200
> Subject: [PATCH v2] doc: Reword "The GCC toolchain".
>
> Fix commit 1f14e25c1969a93908288cb302a572f3cbbaa478
> as discussed in <https://bugs.gnu.org/41038>.
>
> * doc/guix.texi (Packages for C Development): Rename to...
> (The GCC toolchain): ...this. Add gfortran-toolchain.
> (Invoking guix package): Add guix-search anchor.
> (Application Setup)[The GCC toolchain]: Remove.

Applied, thanks!

Ludo’.
?
Your comment

This issue is archived.

To comment on this conversation send an email to 41038@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 41038
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch