GNU bug report logs - #19733
disfunctional gcc binary when GCJ or gfortran is installed

Previous Next

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

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

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

From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
To: <bug-guix <at> gnu.org>
Subject: disfunctional gcc binary when GCJ or gfortran is installed
Date: Fri, 30 Jan 2015 17:30:00 +0100

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

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

From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
To: <19733 <at> debbugs.gnu.org>
Subject: disfunctional gcc binary when GCJ or gfortran is installed 
Date: Tue, 13 Oct 2015 11:44:03 +0200

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 19733 <at> debbugs.gnu.org
Subject: Re: bug#19733: disfunctional gcc binary when GCJ or gfortran is
 installed
Date: Tue, 13 Oct 2015 16:22:16 +0200

Ricardo Wurmus <ricardo.wurmus <at> 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’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 19733 <at> debbugs.gnu.org
Subject: Re: bug#19733: disfunctional gcc binary when GCJ or gfortran is
 installed
Date: Sat, 19 Dec 2015 18:52:10 +0100

ludo <at> gnu.org (Ludovic Courtès) skribis:

> Ricardo Wurmus <ricardo.wurmus <at> 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.  :-)

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

From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 19733 <at> debbugs.gnu.org
Subject: Re: bug#19733: disfunctional gcc binary when GCJ or gfortran is
 installed
Date: Mon, 21 Dec 2015 16:38:51 +0100

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

> ludo <at> gnu.org (Ludovic Courtès) skribis:
>
>> Ricardo Wurmus <ricardo.wurmus <at> 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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 19733 <at> debbugs.gnu.org
Subject: Re: bug#19733: disfunctional gcc binary when GCJ or gfortran is
 installed
Date: Mon, 21 Dec 2015 22:30:31 +0100

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> ludo <at> gnu.org (Ludovic Courtès) skribis:
>>
>>> Ricardo Wurmus <ricardo.wurmus <at> 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’.

Message #25 received at 19733-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 19733-done <at> debbugs.gnu.org
Subject: disfunctional gcc binary when GCJ or gfortran is installed
Date: Thu, 10 Mar 2016 07:29:46 +0100

Fixed with 82f145ef7aef8f4d28a144ee8efcadf3fdd4b877

Previous Next

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