HDF (4) does not build with cce

[vanderwb]

For some reason, it produces an error at build time that does not appear with the other compilers. Will need to try a build outside of Spack to identify root cause.

/opt/cray/pe/cce/14.0.2/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_x86_64 --enable-new-dtags --dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib64//crt1.o /usr/lib64//crti.o /opt/cray/pe/gcc/10.3.0/snos/lib/gcc/x86_64-suse-linux/10.3.0//crtbegin.o /opt/cray/pe/gcc/10.3.0/snos/lib/gcc/x86_64-suse-linux/10.3.0//crtfastmath.o /opt/cray/pe/cce/14.0.2/cce/x86_64/lib/no_mmap.o /glade/gust/scratch/csgteam/temp/pe_46892/conftest_1.o -Bdynamic -ltirpc -rpath=/opt/cray/pe/cce/14.0.2/cce/x86_64/lib -L/opt/cray/pe/gcc/10.3.0/snos/lib64 -rpath=/opt/cray/pe/gcc-libs -L/opt/cray/pe/dsmml/0.2.2/dsmml//lib -L/opt/cray/pe/cce/14.0.2/cce/x86_64/lib/pkgconfig/../ -L/opt/gcc/10.3.0/snos/lib64 -L/opt/cray/pe/gcc/10.3.0/snos/lib64 -L/opt/cray/pe/cce/14.0.2/cce/x86_64/lib/pkgconfig/../ --as-needed -ldsmml --no-as-needed --as-needed -lstdc++ --no-as-needed --as-needed -lpgas-shmem --no-as-needed -lquadmath -lmodules -lfi -lcraymath -lf -lu -lcsup --as-needed -lgfortran --no-as-needed --whole-archive -ltcmalloc_minimal --no-whole-archive -lstdc++ -lpthread -L/opt/cray/pe/cce/14.0.2/cce-clang/x86_64/lib/clang/14.0.6/lib/linux --start-group -lc -lcsup -lgcc_eh -lm -lclang_rt.craypgo-x86_64 -lgcc --end-group -lclang_rt.builtins-x86_64 --disable-new-dtags -L/opt/cray/pe/gcc/10.3.0/snos/lib/gcc/x86_64-suse-linux/10.3.0 -L/opt/cray/pe/cce/14.0.2/binutils/x86_64/x86_64-pc-linux-gnu/..//x86_64-unknown-linux-gnu/lib -EL -o conftest /opt/cray/pe/gcc/10.3.0/snos/lib/gcc/x86_64-suse-linux/10.3.0//crtend.o /usr/lib64//crtn.o
/opt/cray/pe/cce/14.0.2/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: cannot find -ltirpc: No such file or directory

Note the colon at the end of -ltirpc. Where is this coming from?

[benkirk]

The colon is only part of the error message, it is not in the actual link line.

-ltirpc is one of the libraries i've recommended in common - it is a Sun RPC compatibility layer AFAIK for things like XDR and <rpc/xdr.h> that used to be widely available. Not sure why cce wants this and others don't though...

FWIW, I have this lib installed in my sandbox:

benkirk@gust02(6)$ pwd
/glade/gust/scratch/benkirk/spack-tests

benkirk@gust02(7)$ lfs find common -type f -name "libtirpc*"
common/22.08/envs/build/.spack-env/repos/builtin/packages/libtirpc/libtirpc-remove-pipe-flag-for-nvhpc.patch
common/22.08/envs/build/opt/__spack_path_placeholder__/__spack_path_placeholder__/__spac/libtirpc/1.2.6/gcc/7.5.0/lib/libtirpc.a
common/22.08/envs/build/opt/__spack_path_placeholder__/__spack_path_placeholder__/__spac/libtirpc/1.2.6/gcc/7.5.0/lib/pkgconfig/libtirpc.pc
common/22.08/envs/build/opt/__spack_path_placeholder__/__spack_path_placeholder__/__spac/libtirpc/1.2.6/gcc/7.5.0/lib/libtirpc.so.3.0.0

[benkirk]

[build] benkirk@gust02(19)$ spack info libtirpc
AutotoolsPackage:   libtirpc

Description:
    Libtirpc is a port of Suns Transport-Independent RPC library to Linux.

Homepage: https://sourceforge.net/projects/libtirpc/

Preferred version:  
    1.2.6    https://sourceforge.net/projects/libtirpc/files/libtirpc/1.2.6/libtirpc-1.2.6.tar.bz2/download

Safe versions:  
    1.2.6    https://sourceforge.net/projects/libtirpc/files/libtirpc/1.2.6/libtirpc-1.2.6.tar.bz2/download
    1.1.4    https://sourceforge.net/projects/libtirpc/files/libtirpc/1.1.4/libtirpc-1.1.4.tar.bz2/download

Deprecated versions:  
    None

Variants:
    None

Build Dependencies:
    gnuconfig  krb5

Link Dependencies:
    krb5

Run Dependencies:
    None

[vanderwb]

Hi Ben - yes, you are correct on second inspection. Apologies for the red herring. However, libtirpc is installed into common already and is being happily used by the other four compilers, so why cce cannot is still a mystery to me.

[vanderwb]

Found the root cause here. Turns out unlike every other compiler, crayftn does not support LIBRARY_PATH. Even craycc and crayCC support it via their clang-based linker, so I think it's fair to ask for matching behavior here in an RFE.