Hi Alan, Alan O'Cais <a.oc...@fz-juelich.de> writes:
> Hi Loris, > > For case 1, the actual problem has nothing really to do with including > the software in EasyBuild, but building the software with GCC 10 (or > higher). Rather than introduce them to something they might never have > heard of and risk them responding "What do I care about EasyBuild?", > just tell them that their software has issues building with GCC10 and > point them to the Gentoo link. I see your point. I thought developers might see how cool EB is and how it would help people access their software more easily on more powerful systems. However, it could well be that I'm being naive and that your prediction of how most developers might react is more realistic. Indeed, it reminds me of a developer who, when I asked whether he could tag a version of his program, refused with the explanation that simply specifying a commit was sufficient to fulfil the requirements of reproducible research and that, in any case, his program was "never intended to run on an HPC" :-/ Cheers, Loris > For case 2, I can see the use case for a FAQ on this though. > > Alan > > On Tue, 23 Feb 2021 at 14:54, Loris Bennett <loris.benn...@fu-berlin.de> > wrote: > > Hi Kenneth, > > Kenneth Hoste <kenneth.ho...@ugent.be> writes: > > > Hi Loris, > > > > On 23/02/2021 13:42, Loris Bennett wrote: > >> Thanks for the information, John. > >> > >> So there seem to be a number of solutions: > >> > >> 1. Software author patches software > >> 2. EasyConfig author patches software > >> 3. EasyConfig author builds against pre-10 GCC > > > > There's another option if you don't want to patch the code: you could add > > -fcommon to the compiler flags via the easyconfig file (but that's not > > recommended). > > > > > >> > >> Would it be worthwhile having something in the EB docs about the issue > >> which would be useful for those involved in cases 1 and 2? > > > > There's some excellent information on this at > > https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common . > > Thanks for the link. > > In case 1, I was thinking along the lines of writing to the author of > some software and being able to say: > > I want to include your software in EasyBuild (link to EB home), but > you need to patch you program for me to do so (link to page in EB > documentation describing problem, possibly containing other links to > GCC 10 porting). > > In case 2, the EasyConfig author him- or herself would then just be able > to find the information within the EB documentation. > > It just seems to me that this might be a problem which people will run > into again and again until the developers themselves move to GCC 10 and > so it could be handy to have a canonical page in the EB documentation to > point to. > > Cheers, > > Loris > > > regards, > > > > Kenneth > > > >> > >> Cheers, > >> > >> Loris > >> > >> John Dey <j...@fuzzdog.com> writes: > >> > >>> The default with GCC 10.2 is to compile with -fn-common which is causing > many issues with packages. In every case, I have encountered the software > should be patched. > >>> > >>> https://gcc.gnu.org/gcc-10/porting_to.html > >>> > >>> John Dey > >>> j...@fuzzdog.com > >>> > >>> On Mon, Feb 22, 2021 at 5:45 AM Loris Bennett > <loris.benn...@fu-berlin.de> wrote: > >>> > >>> Hi, > >>> > >>> Starting from > >>> > >>> Subread-2.0.0-GCC-8.3.0.eb > >>> > >>> I updated the package to 2.0.1 and changed the compiler version to > >>> 10.2.0 to build: > >>> > >>> Subread-2.0.1-GCC-10.2.0.eb > >>> > >>> However, this fails with multiple errors all like the following: > >>> > >>> > /trinity/shared/easybuild/software/binutils/2.35-GCCcore-10.2.0/bin/ld.gold: > error: core-junction.o: multiple definition of 'replica_index' > >>> > /trinity/shared/easybuild/software/binutils/2.35-GCCcore-10.2.0/bin/ld.gold: > core.o: previous definition here > >>> > >>> There is a Debian bug report which mentions a similar issue > >>> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957846 > >>> > >>> Regarding the solutions given there, I can confirm that building with > >>> GCC 9.2.0 works, however when > >>> > >>> export CC=gcc-10 CXX=g++-10 > >>> > >>> is set, as suggested in the bug report, the build fails with the same > >>> error as above. > >>> > >>> Is this a known problem with GCC 10? > >>> > >>> Cheers, > >>> > >>> Loris > >>> > >>> -- > >>> Dr. Loris Bennett (Hr./Mr.) > >>> ZEDAT, Freie Universität Berlin Email > loris.benn...@fu-berlin.de > >>>
