Dear Samet,
On 20/11/2020 16:45, Samet Demir wrote:
Hi,
I was trying to compile GCC with easybuild on newly installed debian
buster and i get this error in the postprocessing step:
Exactly one 'include-fixed' directory expected, found 2:
['/opt/easybuild/software/GCCcore/10.2.0/lib/gcc/i686-pc-linux-gnu/10.2.0/include-fixed',
'/opt/easybuild/software/GCCcore/10.2.0/lib64/gcc/i686-pc-linux-gnu/10.2.0/include-fixed']
(at
easybuild/software/EasyBuild/4.3.1/lib/python2.7/site-packages/easybuild/easyblocks/g/gcc.py:690
in post_install_step)
In the gcc easyblock there is a count check for include-fixed directory,
"if len(matches) == 1:", clearly easybuild expects one include-fixed
directory but my build creates two.
Anyone encountered this problem before? Any ideas about how to fix this?
Usually both the 'lib' and 'lib64' directories get populate in the GCC
installation, with different things.
Here's what I have on my system (CentOS 7):
$ ls GCCcore/10.2.0/lib
gcc
$ ls GCCcore/10.2.0/lib/gcc
x86_64-pc-linux-gnu
$ ls GCCcore/10.2.0/lib/gcc/x86_64-pc-linux-gnu
10.2.0
$ ls GCCcore/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0
crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtfastmath.o
crtprec32.o crtprec64.o crtprec80.o finclude include
include-fixed.renamed-by-easybuild install-tools libcaf_single.a
libcaf_single.la libgcc.a libgcc_eh.a libgcov.a plugin
$ ls GCCcore/10.2.0/lib64
libasan.a libatomic.a libcc1.la libgfortran.a
...
libssp.so.0 libstdc++.so libtsan.a libubsan.a
(there's no 'gcc' subdirectory in 'lib64' for me)
In your case, lib64 is probably a symbolic link to lib, or the other way
around?
That's something we've started doing recently to avoid picking up stuff
from /usr/lib64 or /lib64; see
https://github.com/easybuilders/easybuild-framework/pull/3401 .
GCC seems to be only installing things in either lib64 or lib for you,
and with the symlink in place there will be two hits when checking for
the include-fixed directory...
Can you check whether this matches what you're seeing?
If so, it shouldn't be too difficult to take that possibility into
account in the GCC easyblock (I can send you a patched version that you
can test with "eb --include-easyblocks gcc.py ...").
regards,
Kenneth
Thank you in advance.
--
Samet Demir
