bug#41038: gcc creates binaries that don't find their shared libraries

[zimoun <zimon.toutoune@gmail.com>]

Dear Bruno,

Thank you for your feedback.


On Mon, 4 May 2020 at 01:10, Bruno Haible <bruno@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@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