linux Fortran and cmake about aggregate HOT 8 OPEN

Working on a fix at #76 - packages are up on the c3i_test2 channel. Please give them a try if you have time.

from aggregate.

Thanks for the packages to try. No change in this particular issue, as neither omp_lib file found among the following packages. Please let me know if I've overlooked searching somewhere.

# Name                    Version                   Build  Channel
binutils_impl_linux-64    2.30                 h90cb4c1_0    c3i_test2
binutils_linux-64         8.2.0                h90cb4c1_0    c3i_test2
gcc_impl_linux-64         8.2.0                habb00fd_0    c3i_test2
gcc_linux-64              8.2.0                h218040c_0    c3i_test2
gfortran_impl_linux-64    8.2.0                hdf63c60_0    c3i_test2
gfortran_linux-64         8.2.0                h218040c_0    c3i_test2
gxx_impl_linux-64         8.2.0                hdf63c60_0    c3i_test2
gxx_linux-64              8.2.0                h218040c_0    c3i_test2
libgcc-ng                 8.2.0                hdf63c60_0    c3i_test2
libgfortran-ng            8.2.0                hdf63c60_0    c3i_test2
libstdcxx-ng              8.2.0                hdf63c60_0    c3i_test2

Do I gather correctly that because the compilers in c3i_test2 are gcc82, while other packages (e.g., cmake and hdf5) are dependent on gcc72, the channel is suited only to split build/host use? In any case, in that mode, I had no trouble building a C++ package (non-defaults deps are pure-C or pure-Py) with the new compilers.

In good news, the new $HOST-gcov from #58 looks to be working nicely, though afflicted with the error message deluge reported here.

Please let me know if there's another aspect you'd like tested.

from aggregate.

The libgcc and other compiler runtime dependencies pinned to 7.2.* will be hotfixed to change them to >=7.2 to prevent them from pulling in old runtimes.

channel is suited only to split build/host use

All recipes should be updated for this split anyway if possible; it'll allow cross compilation to some extent (once we get some compilers capable of that).

I had trouble with libstdc++ being needed by the compiler when I tested on a clean docker 6 image. Not sure I was using the very latest packages though.

from aggregate.

New packages are up. I also had to hotfix our index metadata to fix some overzealous/underzealous constraints on the runtimes here.

I did not increment the build number - sorry - please remove any prior versions from your package cache before you try these.

from aggregate.

(1)

channel is suited only to split build/host use

All recipes should be updated for this split anyway if possible; it'll allow cross compilation to some extent (once we get some compilers capable of that).

Thanks, I've made the split. Only noticed because I usually put cmake in reqs/build.

(2) In testing, should I be using non-compilers-and-immediate-dependencies from defaults or c3i_test2? I've got an hdf5 problem building against the latter (compilers and hdf5), and I notice that the latter only has v1.10.1 and the libgfortran-ng >=7,<8.0a0 fix looks to have been applied only the the former. I just want to be sure of trying out the right package set.

>>> diff -bwy -W 150 hdf5-1.10.2-hba1933b_1/info/recipe/meta.yaml hdf5-1.10.1-hb0523eb_0/info/recipe/meta.yaml
# This file created by conda-build 3.10.2				  |	# This file created by conda-build 3.0.15+50.g6024f3f
# meta.yaml template originally from:						# meta.yaml template originally from:
# /tmp/build/80754af9/rsync-recipes/hdf5-1.10.2-on-linux_64, last modi	  |	# /home/rdonnelly/conda/aggregate/hdf5-feedstock/recipe, last modified
# ------------------------------------------------				# ------------------------------------------------

package:									package:
    name: hdf5									    name: hdf5
    version: 1.10.2							  |	    version: 1.10.1
...
    host:									    host:
        - libgcc-ng 7.2.0 hdf63c60_3					  |	        - libgcc-ng 7.2.0 hcbc56d2_1
        - libgfortran-ng 7.2.0 hdf63c60_3				  |	        - libgfortran-ng 7.2.0 h6fcbd8e_1
        - libstdcxx-ng 7.2.0 hdf63c60_3					  |	        - libstdcxx-ng 7.2.0 h24385c6_1
        - zlib 1.2.11 ha838bed_2					  |	        - zlib 1.2.11 hfbfcf68_1
    run:									    run:
        - libgcc-ng >=7.2.0							        - libgcc-ng >=7.2.0
        - libgfortran-ng >=7,<8.0a0					  |	        - libgfortran-ng >=7.2.0
        - libstdcxx-ng >=7.2.0							        - libstdcxx-ng >=7.2.0
        - zlib >=1.2.11,<1.3.0a0						        - zlib >=1.2.11,<1.3.0a0

from aggregate.

The hdf5 stuff you discuss is basically the crux of the need for the hotfix. I'll nuke the old stuff on c3i_test2, and that should clear it up.

Edit: done

from aggregate.

Thanks on above. There was more wrong with hdf5 linking, but that seems to be on my end. This is probably too late to be of use, but in case it's of interest:

• Everything in my mini ecosystem builds in some form (perhaps not with all optional features enabled) with the new compilers from c3i_test2.
• Traditionally I build with Intel compilers which use conda GCC compilers as backend. Considering Intel only supports through GCC 6.3, this was always pushing it. The conda GCC 7.2 worked fine for my packages, whereas GCC 8.2 starts issuing header errors for C++ packages. Not surprising. When I backed off and used GCC directly, built fine.
• Is there an hdf5 package built against libgfortran 8.2 somewhere? I'm having trouble building a package using pure 8.2 c/cxx/fortran when hdf5 is a dependency b/c hdf5-->gfortran<8. But if I try mixed compiler versions 8.2 c/cxx & 7.2 fortran, then all the compilers can't install b/c different binutils versions.

EDIT:

• I also tested a pure Intel+GCC-7.2 built package in a libgcc-ng & libstdcxx-ng 8.2 environment. No trouble.

from aggregate.

then all the compilers can't install b/c different binutils versions.

Our binutils pinning is probably too strict. We have an issue with gfortran, it's now gfortran-5 instead of -4, so we need to rebuild everything at some point. Because we needed the aligned_alloc, gomp and fortran fixes we've had to backport them to GCC 7.3.0 which is on c3i_test now (actually the packages are on their way to defaults shortly!)

We do need to rebuild GCC 8.2.0 on more time and figure out what to do with the binutils pinning because we'd like to start using 8.2.0.

One thing to note, we've uploaded the GCC 8.2 runtimes to defaults now and they're getting pulled in and used extensively, in concert with packages built against 7.2 (fingers crossed, I must admit I'm a little nervous).

from aggregate.