On 01/01/18 14:50, David Holland wrote:
This seems to lead us back to "build everything with the same compiler suite" if possible.On Mon, Jan 01, 2018 at 09:36:20PM +0100, Joerg Sonnenberger wrote: > > The big issue is libstdc++, not libgcc. > > In the case of g95, the problem is actually libgcc_s. So what's the solution then? An ELF binary linked against two incompatible versions of shared libgcc will never fully work.
That's my plan and I think this has to be a well-supported option in whatever solution is implemented.
Those who want/need to avoid building a newer gcc package will have to deal with tool chain mixing issues as they arise.
FreeBSD ports has been dealing with this for years (gcc 4.2 on 9.x, clang on 10.x and later, mixed with various newer gcc ports for Fortran and modern C++ support). There have been problems but there are always solutions. They're a drain on man-hours, but that's unavoidable for some situations.
I think letting end-users choose their own path (PKGSRC_G*_VERSION) is a key component of any good solution. I'll set up my systems to use a current GCC suite for everything in computational science and people on more limited platforms can try to use the base gcc if that works better for them.
-- Earth is a beta site.