Question on compiling and linking with YAC

Hi, I wrote two toy models that are being used to check the coupling with a hydrology model. These toy models are part of the repository of the other model. The toys are compiled as follows:

mpicc -o toy_land.exe -O0 -g ../code/src/toy_land.c  `pkg-config --libs yac`  `pkg-config --cflags yac`

The toys themselves use NetCDF. Since, YAC also uses netcdf, pkg delivers the respective arguments for compiling and linking with NetCDF. However, the arguments from pkg do not contain the rpath to the libraries. In order the run the toys I have explictily to set the LD_LIBRARY_PATH...

I could also explicitly set the rpath when compiling the toys, but then this path would have to match the library from the pkg agruments.

What is method to handle this issue? Would it be possible for YAC to already provide the rpath?

assigned to @m300488

@k202077, sorry for the long read

1. For now, I can recommend extending your command with `pkg-config --libs-only-L yac | sed 's/-L/-Wl,-rpath,/g'`.
2. I strongly believe that if a user application depends on NetCDF directly, its build procedure must not rely on the pkg-config file of YAC to provide flags that are required for linking to NetCDF. First, NetCDF is an optional dependency of YAC and the required flags might simply not be there. Second, the user application might require a different instance (version, enabled features, installation prefix, etc.) of NetCDF and, therefore, the linking to the library must be done explicitly to avoid ambiguity. And if the user application is supposed to link to NetCDF library explicitly, it's fair to expect that the required RPATH flags will be specified as well.
3. Although I am not sure whether pkg-config files are supposed to provide RPATH flags, we can do that for yac.pc. Things that we will need to take care of:

   1. Make sure that we do not return RPATH flags for system directories (e.g. /usr/lib64) because this might lead to very strange symptoms at the link- and runtime of a user application.

   2. Ideally, we should not return RPATHs to the directories if we link statically, e.g. we should not return -Wl,-rpath,/path/to/netcdf/lib if we link (our test programs) to libnetcdf.a (even if there is also libnetcdf.so in that directory). I don't know how to handle this reliably.

   3. Fortran and C compilers might require different flags, e.g. nag requires -Wl,-Wl,,-rpath,,/path/to/library and fails with what gcc needs (-Wl,-rpath,/path/to/library), and the other way around. Therefore, we need to:

      • detect the right format for the flags at the configure time, based on the compiler vendor (and version);
      • use the flags when building the test programs (so we could be more or less sure that the flags do the job and do not harm);
      • decide how to let the users choose which of the two compilers they need the RPATH flags for.

      For the last bullet point, we could introduce custom variables in yac.pc, say crpaths and fcrpaths, and then the usage would be pkg-config --variable=crpaths yac and pkg-config --variable=fcrpaths yac, respectively. We could, of course, detect that both CC and FC require the same format of the flags and add them to the output of pkg-config --libs yac in that case but it will be very confusing for the users not to get the flags in the output otherwise.

      On the other hand, we can tell the users that:

      • `pkg-config --cflags yac` is guaranteed to work for the C compiler;
      • `pkg-config --cflags yac` works for the Fortran compiler if YAC is not installed to prefix /usr (pkg-config omits -I/usr/include because the C compiler is supposed to search for headers in that directory by default but the Fortran compiler is not) and the Fortran compiler interprets -I as a hint on where to look for the module files (it does not have to support the flag at all or might accept it for files included with #include "file" or INCLUDE "file" only);
      • `pkg-config --libs yac` works for the Fortran compiler if they know that it accepts RPATH flags that are meant for the C compiler;
      • they should use `pkg-config --libs-only-L --libs-only-l yac` if they do not want the RPATH flags at all;
      • if they want to be on the safe side with the Fortran compiler, they should use `pkg-config --variable=fcflags yac` for compilation and `pkg-config --libs-only-L --libs-only-l yac` `pkg-config --variable=fcrpaths yac` for linking.

      If that is fine with you, I can implement this in the not-so-distant future. I think I have all the bits for this.

P.S. I am so happy that we provide YAC as a static library only and, therefore, don't really have to fulfil the user expectations related to the shared linking (which would, most probably, require using libtool and that's another big adventure).

Hi Sergey,

thank you very much for the detailed answer.

I agree that, if a user requires NetCDF for his application, he should provide the library himself. However, pkg-config --libs yac already provides -L and -l for netcdf...doesn't this potentially generate conflicts, if the user also provides NetCDF library flags?

If the user provides flags to the same installation of NetCDF, it's the right thing to do. Otherwise, it does potentially generate conflicts. I would also expect different symptoms depending on whether we link to a static or a dynamic version of NetCDF library. It's also not nice to build YAC against one version and then link the user application to another one.

@m300488 Hi Sergey, also thanks from my side. May I ask you whether the configure below is correct to install/compile YAC on Levante?

configure \
--with-yaxt-root=${mypath}/yaxt \
--with-netcdf-root=/sw/spack-levante/netcdf-c-4.8.1-f7hh57 \
--with-xml2-include=/usr/include/libxml2 \
--with-xml2-lib=/usr/lib64 \
--prefix=${mypath}/yac \
CC=/sw/spack-levante/openmpi-4.1.2-yfwe6t/bin/mpicc \
FC=/sw/spack-levante/openmpi-4.1.2-yfwe6t/bin/mpifort \
CFLAGS="-g"  \
FCFLAGS="-g"  \
MKL_CLIBS="`pkg-config --libs mkl-static-lp64-seq`" \
MKL_CFLAGS="`pkg-config --cflags mkl-static-lp64-seq`" \
MPI_LAUNCH="$(which mpirun)"

@g260062 you should not need --with-xml2-lib=/usr/lib64, you might want to enable -O2 (at least) optimizations in CFLAGS and FCFLAGS. I would also think about the configure option --with-external-lapack. In ICON, we set it to fortran so that both ICON and YAC used the same set of functions. That would, of course, mean that MKL_CLIBS and MKL_CFLAGS should be replaced with FORTRAN_LAPACK_CLIBS (there is no need for headers in that case).

Another story is the mtime library. By default, YAC uses an internal copy of mtime but ICON needs it too. To avoid possible inconsistency, we build YAC with --with-external-mtime and provide MTIME_CFLAGS/MTIME_CLIBS pointing to the same installation of mtime that we use in ICON.

@m300488 Thank you very much for the answer! With the mtime library and the modified configure for YAC, now I can install YAC and compile the two toy models as well as run a test with the coupled model HD+toy models via YAC. I'm looking forward to seeing how to compile HD as a part inside the ICON source code.