GNU bug report logs - #41038
gcc creates binaries that don't find their shared libraries

Previous Next

Package: guix;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Sat, 2 May 2020 23:56:01 UTC

Severity: normal

Tags: notabug

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41038 in the body.
You can then email your comments to 41038 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sat, 02 May 2020 23:56:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bruno Haible <bruno <at> clisp.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sat, 02 May 2020 23:56:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-guix <at> gnu.org
Subject: gcc creates binaries that don't find their shared libraries
Date: Sun, 03 May 2020 01:55:00 +0200
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):
----------------
$ wget https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.gz
$ 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





Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sun, 03 May 2020 21:08:02 GMT) Full text and rfc822 format available.

Message #8 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Sun, 03 May 2020 23:07:34 +0200
Hi,

Bruno Haible <bruno <at> clisp.org> skribis:

> $ 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

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.

HTH!

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sun, 03 May 2020 22:13:02 GMT) Full text and rfc822 format available.

Message #11 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 4 May 2020 00:12:03 +0200
[Message part 1 (text/plain, inline)]
Hi Bruno,

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

> $ 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:

$ wget https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.gz
$ 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.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sun, 03 May 2020 23:10:02 GMT) Full text and rfc822 format available.

Message #14 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 04 May 2020 01:09:10 +0200
Hi Ludo,

> > $ 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
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.

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.

> 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





Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Mon, 04 May 2020 08:51:01 GMT) Full text and rfc822 format available.

Message #17 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 4 May 2020 10:50:06 +0200
Dear Bruno,

Thank you for your feedback.


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

> > 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

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '("make" "gcc-toolchain" "gdb"))
--8<---------------cut here---------------end--------------->8---

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".

https://guix.gnu.org/manual/devel/en/guix.html#profile_002dmanifest


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

  guix install gcc-toolchain <at> 9 -p /path/to/my/gcc-9
  guix install gcc-toolchain <at> 8 -p /path/to/my/gcc-8

Then, for example let prepend the environment variables defined by the
packages gcc-toolchain <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Mon, 04 May 2020 09:07:01 GMT) Full text and rfc822 format available.

Message #20 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 4 May 2020 11:06:35 +0200
Dear Ludo and Bruno,

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

> 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




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Mon, 04 May 2020 09:32:02 GMT) Full text and rfc822 format available.

Message #23 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 04 May 2020 11:30:51 +0200
Hi,

Bruno Haible <bruno <at> clisp.org> skribis:

> 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:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1f14e25c1969a93908288cb302a572f3cbbaa478

> 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’.




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Mon, 04 May 2020 10:01:02 GMT) Full text and rfc822 format available.

Message #26 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 4 May 2020 11:59:47 +0200
Hi Ludo,

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

> >   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




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Mon, 04 May 2020 19:53:02 GMT) Full text and rfc822 format available.

Message #29 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Mon, 04 May 2020 21:52:49 +0200
Hello,

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

> 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’.




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Tue, 05 May 2020 09:31:01 GMT) Full text and rfc822 format available.

Message #32 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Tue, 05 May 2020 11:30:38 +0200
Hi Danny,

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> 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’.




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Tue, 05 May 2020 11:18:02 GMT) Full text and rfc822 format available.

Message #35 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: gcc creates binaries that don't find their shared
 libraries
Date: Tue, 05 May 2020 13:17:36 +0200
Ludovic Courtès wrote:
> 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






Added tag(s) notabug. Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 05 May 2020 19:35:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 41038 <at> debbugs.gnu.org and Bruno Haible <bruno <at> clisp.org> Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 05 May 2020 19:35:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Wed, 06 May 2020 17:43:02 GMT) Full text and rfc822 format available.

Message #42 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: [PATCH] doc: Reword "The GCC toolchain".
Date: Wed, 6 May 2020 19:42:09 +0200
[Message part 1 (text/plain, inline)]
Hi Ludo

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

> 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
[0001-doc-Reword-The-GCC-toolchain.patch (text/x-patch, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Fri, 15 May 2020 17:00:02 GMT) Full text and rfc822 format available.

Message #45 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: [PATCH] doc: Reword "The GCC toolchain".
Date: Fri, 15 May 2020 18:59:29 +0200
Hi Ludo,

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

Thanks,
simon




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Fri, 15 May 2020 19:43:01 GMT) Full text and rfc822 format available.

Message #48 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: [PATCH] doc: Reword "The GCC toolchain".
Date: Fri, 15 May 2020 21:42:17 +0200
Hello,

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

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

I have two minor comments about it.

> +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{...}.

> (see @pxref{guix-search,, Invoking guix package}).

You need to remove the "see ":

  (@pxref{...})


Regards,

-- 
Nicolas Goaziou




Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sat, 16 May 2020 14:58:02 GMT) Full text and rfc822 format available.

Message #51 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org
Subject: Re: bug#41038: [PATCH] doc: Reword "The GCC toolchain".
Date: Sat, 16 May 2020 16:57:11 +0200
[Message part 1 (text/plain, inline)]
Hi Nicolas,

Thank you for the review.  Attached the updated patch.

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

> > +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
[v2-0001-doc-Reword-The-GCC-toolchain.patch (text/x-patch, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#41038; Package guix. (Sat, 16 May 2020 15:21:02 GMT) Full text and rfc822 format available.

Message #54 received at 41038 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, 41038 <at> debbugs.gnu.org,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41038: [PATCH] doc: Reword "The GCC toolchain".
Date: Sat, 16 May 2020 17:19:54 +0200
Hi,

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

> From efbc579a8884235ac37833ea6ee6fa454110c080 Mon Sep 17 00:00:00 2001
> From: zimoun <zimon.toutoune <at> 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’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 14 Jun 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 288 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.