Parallel-NetCDF / PnetCDF

Source code repository of PnetCDF library and utilities
https://parallel-netcdf.github.io
Other
80 stars 22 forks source link

Suppressing /usr/bin/ld warning message "missing .note.GNU-stack section implies executable stack" #102

Open cponder opened 1 year ago

cponder commented 1 year ago

Building PNetCDF 1.12.3 on the NERSC/perlmutter cluster (HPE/Cray with SLES 15.4) I get messages like this building the library and the regression-tests using the NVHPC 22.7 compilers:

/usr/bin/ld: warning: /tmp/pgcudafatlp1hHndhHOzT.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

I'm posting this in case anyone else is trying to deal with the messages; they may well go away with a newer version of ld in future SLES releases or adjustments to the compiled-file formats in future NVHPC releases.

cponder commented 1 year ago

The workaround I used was to set these:

export MPIF77="mpif77 -Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"
export CXXFLAGS="-Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"
export  FCFLAGS="-Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"

I couldn't just set any of these

export LDFLAGS="-z noexecstack"
export LDFLAGS="--Wl,z,noexecstack"
export LDFLAGS="-Wl,--Wl,z,noexecstack"

The first would break all the compiles because the mpi compilers are being used for linkage and the -z has to be passed directly to ld. The second would break most of the regression-test builds because the -Wl is already being stripped when the MPI compiler is invoked for linkage, so the -z`` is detected at that level. The third would break theconfigurephase because the C-compiler peels-off the first-Wlbutlddoesn't know what to do with the second-Wl```.

cponder commented 1 year ago

A more specific set of settings would be

export F77FLAGS="-Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"
export CXXFLAGS="-Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"
export  FCFLAGS="-Wl,-Xlinker,-z -Wl,-Xlinker,noexecstack"

but the Makefile doesn't appear to implement a F77FLAGS variable, so we have to attach the flags to the compiler variable instead. Is this an oversight?

wkliao commented 1 year ago

FYI. I did not encounter the ld problem when using the following commands on Perlmutter.

% module swap PrgEnv-gnu PrgEnv-nvidia
Lmod is automatically replacing "gcc/11.2.0" with "nvidia/22.7".
Due to MODULEPATH changes, the following have been reloaded:
  1) cray-mpich/8.1.24

% which mpicc
/opt/cray/pe/mpich/8.1.24/ofi/nvidia/20.7/bin/mpicc

% mpicc -show
nvc -I/opt/cray/pe/mpich/8.1.24/ofi/nvidia/20.7/include -L/opt/cray/pe/mpich/8.1.24/ofi/nvidia/20.7/lib -lmpi_nvidia

% nvc --version
nvc 22.7-0 64-bit target on x86-64 Linux -tp zen3 
NVIDIA Compilers and Tools
Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

% ../pnetcdf-1.12.3/configure \
    MPICC=mpicc MPICXX=mpicxx MPIF77=mpif77 MPIF90=mpif90 \
    CFLAGS=-O2 CXXFLAGS=-O2 FFLAGS=-O2 FCFLAGS=-O2

And here is the modules loaded in my env.

% module list

Currently Loaded Modules:
  1) craype-x86-milan                       10) cudatoolkit/11.7
  2) libfabric/1.15.2.0                     11) craype-accel-nvidia80
  3) craype-network-ofi                     12) gpu/1.0
  4) xpmem/2.5.2-2.4_3.30__gd0f7936.shasta  13) nvidia/22.7
  5) perftools-base/23.02.0                 14) craype/2.7.19
  6) cpe/23.02                              15) cray-dsmml/0.2.2
  7) xalt/2.10.2                            16) cray-mpich/8.1.24
  8) Nsight-Compute/2022.1.1                17) cray-libsci/23.02.1.1
  9) Nsight-Systems/2022.2.1                18) PrgEnv-nvidia/8.3.3