disfunctional gcc binary when GCJ or gfortran is installed

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Ricardo Wurmus
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ricardo Wurmus
Severity
normal
R
R
Ricardo Wurmus wrote on 30 Jan 2015 17:30
(address . bug-guix@gnu.org)
idjiofodyev.fsf@bimsb-sys02.mdc-berlin.net
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
R
R
Ricardo Wurmus wrote on 13 Oct 2015 11:44
disfunctional gcc binary when GCJ or gfortran is installed
(address . 19733@debbugs.gnu.org)
idj37xf14t8.fsf@bimsb-sys02.mdc-berlin.net
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
L
L
Ludovic Courtès wrote on 13 Oct 2015 16:22
Re: bug#19733: disfunctional gcc binary when GCJ or gfortran is installed
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)(address . 19733@debbugs.gnu.org)
87wpuqonl3.fsf@gnu.org
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

Toggle quote (13 lines)
> 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’.
L
L
Ludovic Courtès wrote on 19 Dec 2015 18:52
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)(address . 19733@debbugs.gnu.org)
87si2yxr5h.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (17 lines)
> 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. :-)
R
R
Ricardo Wurmus wrote on 21 Dec 2015 16:38
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 19733@debbugs.gnu.org)
idjlh8n6cc4.fsf@bimsb-sys02.mdc-berlin.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (23 lines)
> 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
L
L
Ludovic Courtès wrote on 21 Dec 2015 22:30
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)(address . 19733@debbugs.gnu.org)
874mfbij60.fsf@gnu.org
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

Toggle quote (27 lines)
> 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?

Toggle snippet (6 lines)
$ 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

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’.
R
R
Ricardo Wurmus wrote on 10 Mar 2016 07:29
disfunctional gcc binary when GCJ or gfortran is installed
(address . 19733-done@debbugs.gnu.org)
87d1r2x2ud.fsf@elephly.net
Fixed with 82f145ef7aef8f4d28a144ee8efcadf3fdd4b877
Closed
?