bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ricardo Wurmus]

Hi Guix,

installing the gcj or the gfortran package, my profile's /bin directory
gets a gcc link.  If I use Guix as a package manager on top of another
system that has a working installation of the GNU C compiler and my
profile bin path has preference to all other items in PATH, then I end
up with a disfunctional gcc binary.

gcj as well as gfortran come with a couple of binaries (gcc, gcc-ar,
etc) that do not constitute a working C compiler.  Trying to build an
application with

   ./configure
   make
   sudo make install

"configure" complains about gcc not being able to compile C code.

Other distributions seem to remove common binaries like gcc, gcc-ar, etc
from their gfortran packages and it seems that we should too in order to
avoid conflicts.  It seems that neither gfortran nor gcj actually need
these binaries to function.

Should we add another phase to the definitions of "custom-gcc" and "gcj"
to remove these binaries?

~~ Ricardo

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ricardo Wurmus]

Commit 5f6887e8 fixes this for GCJ, but we still have this problem for
all variants of gfortran, gcc-objc, and gccgo, all of which are built
using the ‘custom-gcc’ procedure.

It’s probably safe to add a build phase like this to ‘custom-gcc’:

    (add-after 'install 'remove-broken-or-conflicting-files
     (lambda* (#:key outputs #:allow-other-keys)
       (for-each delete-file
         (find-files (string-append (assoc-ref outputs "out") "/bin")
                     ".*(c\\+\\+|cpp|g\\+\\+|gcc.*)"))
       #t))

~~ Ricardo

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Commit 5f6887e8 fixes this for GCJ, but we still have this problem for
> all variants of gfortran, gcc-objc, and gccgo, all of which are built
> using the ‘custom-gcc’ procedure.
>
> It’s probably safe to add a build phase like this to ‘custom-gcc’:
>
>     (add-after 'install 'remove-broken-or-conflicting-files
>      (lambda* (#:key outputs #:allow-other-keys)
>        (for-each delete-file
>          (find-files (string-append (assoc-ref outputs "out") "/bin")
>                      ".*(c\\+\\+|cpp|g\\+\\+|gcc.*)"))
>        #t))

Sounds like it should work.  The pattern should also include ‘gcov’.

Ludo’.

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>
>> Commit 5f6887e8 fixes this for GCJ, but we still have this problem for
>> all variants of gfortran, gcc-objc, and gccgo, all of which are built
>> using the ‘custom-gcc’ procedure.
>>
>> It’s probably safe to add a build phase like this to ‘custom-gcc’:
>>
>>     (add-after 'install 'remove-broken-or-conflicting-files
>>      (lambda* (#:key outputs #:allow-other-keys)
>>        (for-each delete-file
>>          (find-files (string-append (assoc-ref outputs "out") "/bin")
>>                      ".*(c\\+\\+|cpp|g\\+\\+|gcc.*)"))
>>        #t))
>
> Sounds like it should work.  The pattern should also include ‘gcov’.

Could you give it a try?

Ludo’, trying to tidy up the bug database.  :-)

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>>
>>> Commit 5f6887e8 fixes this for GCJ, but we still have this problem for
>>> all variants of gfortran, gcc-objc, and gccgo, all of which are built
>>> using the ‘custom-gcc’ procedure.
>>>
>>> It’s probably safe to add a build phase like this to ‘custom-gcc’:
>>>
>>>     (add-after 'install 'remove-broken-or-conflicting-files
>>>      (lambda* (#:key outputs #:allow-other-keys)
>>>        (for-each delete-file
>>>          (find-files (string-append (assoc-ref outputs "out") "/bin")
>>>                      ".*(c\\+\\+|cpp|g\\+\\+|gcc.*)"))
>>>        #t))
>>
>> Sounds like it should work.  The pattern should also include ‘gcov’.
>
> Could you give it a try?
>
> Ludo’, trying to tidy up the bug database.  :-)

Wouldn’t this cause a rebuild of a very large number of packages?
Should I push the above (with ‘gcov’ added to the pattern) to a wip
branch?

~~ Ricardo

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>>>
>>>> Commit 5f6887e8 fixes this for GCJ, but we still have this problem for
>>>> all variants of gfortran, gcc-objc, and gccgo, all of which are built
>>>> using the ‘custom-gcc’ procedure.
>>>>
>>>> It’s probably safe to add a build phase like this to ‘custom-gcc’:
>>>>
>>>>     (add-after 'install 'remove-broken-or-conflicting-files
>>>>      (lambda* (#:key outputs #:allow-other-keys)
>>>>        (for-each delete-file
>>>>          (find-files (string-append (assoc-ref outputs "out") "/bin")
>>>>                      ".*(c\\+\\+|cpp|g\\+\\+|gcc.*)"))
>>>>        #t))
>>>
>>> Sounds like it should work.  The pattern should also include ‘gcov’.
>>
>> Could you give it a try?
>>
>> Ludo’, trying to tidy up the bug database.  :-)
>
> Wouldn’t this cause a rebuild of a very large number of packages?

--8<---------------cut here---------------start------------->8---
$ GUIX_PACKAGE_PATH= guix refresh -l -e '(@@ (gnu packages gcc) gfortran)'
Building the following 57 packages would ensure 144 dependent packages are rebuilt: bless-1p02 fftw-openmpi-3.3.4 mumps-metis-5.0.1 mumps-5.0.1 r-gridbase-0.4-7 r-plotrix-3.6 r-servr-0.2 r-htmlwidgets-0.5 r-readr-0.2.2 r-lattice-0.20-33 r-data-table-1.9.6 r-dplyr-0.4.3 r-devtools-1.9.1 python2-rpy2-2.6.0 python-rpy2-2.6.0 r-qtl-1.37-11 rsem-1.2.20 python-ipython-3.2.1 python-numexpr-2.4.4 python-h5py-2.4.0 python-biopython-1.66 python-statsmodels-0.6.1 python-scikit-learn-0.16.1 python-scikit-image-0.11.3 python-seaborn-0.5.1 idr-2.0.0 python2-scikit-image-0.11.3 python2-numexpr-2.4.4 python2-statsmodels-0.6.1 python2-seaborn-0.5.1 python2-ipython-3.2.1 enblend-enfuse-4.1.3 libreoffice-5.0.3.2 macs-2.1.0.20140616 rseqc-2.6.1 crossmap-0.2.1 deeptools-1.5.11 miso-0.5.3 grit-2.0.2 seqmagick-0.6.1 clipper-0.3.0 python2-warpedlmm-0.21 pbtranscript-tofu-2.2.3.8f5467fe6 superlu-dist-3.3 gmsh-2.8.4 mumps-openmpi-5.0.1 slepc-complex-openmpi-3.6.2 plink-1.07 apl-1.5 dealii-openmpi-8.2.1 dealii-8.2.1 flann-1.8.4 slepc-complex-3.6.2 slepc-3.6.2 shogun-4.0.0 couger-1.8.2 julia-0.3.10
$ GUIX_PACKAGE_PATH= guix refresh -l gfortran gccgo gcc-objc gcc-objc++ 
No dependents other than themselves: gcc-objc++-4.8.5 gcc-objc-4.8.5 gccgo-4.8.5 gfortran-5.3.0
--8<---------------cut here---------------end--------------->8---

So that’s mostly several GCC rebuilds and a LibreOffice rebuild.  I
think it’s not unreasonable to do on ‘master’ once ‘security-updates’
has been merged (hopefully soon.)

Ludo’.

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

[Ricardo Wurmus]

Fixed with 82f145ef7aef8f4d28a144ee8efcadf3fdd4b877