Allow "-c" to be anywhere on the command line of the legacy compiler wrappers

[martinjotte]

The compiler wrappers h5cc and h5fc now need the "-c" option to be at the beginning of the compile line. If "-c" is not at the beginning, the scripts do not give a warning but instead mangle the compile line:

h5fc test.f90 -c
ifort: command line error: no files specified; for help type "ifort -help"
compile failed with command: /opt/intel/oneapi/compiler/latest/bin/ifort -c -c -I/usr/local/include

or

h5fc -show -O3 -c test.f90
/opt/intel/oneapi/compiler/latest/bin/ifort -c -c test.f90 -I/usr/local/include

My build system usually adds "-c" to the end of the compiler flags when only compiling, so this change in the behavior of the compiler wrappers affected me until I realized that the placement of "-c" was important.

An improvement would be to not try to strip "-c" from the argument list and not add it to the compile_args:

diff -up hdf5-2.0.0/config/libh5cc.in.orig hdf5-2.0.0/config/libh5cc.in
--- hdf5-2.0.0/config/libh5cc.in.orig	2026-02-11 16:26:50.169412698 -0500
+++ hdf5-2.0.0/config/libh5cc.in	2026-02-11 16:27:20.453250437 -0500
@@ -182,9 +182,6 @@ for arg in $@ ; do
       add_rpath="no"
       ;;
     -c)
-      compile_args="${compile_args:+${compile_args} }$arg"
-      shift
-
       do_link="no"
       ;;
     *)

This works because "-c" is still passed to the compiler along with the rest of the compile line. With this small change, the new compiler wrappers behave like the pre-2.0 wrappers with regard to recognizing "-c":

h5fc -show -O3 -c test.f90
/opt/intel/oneapi/compiler/latest/bin/ifort -O3 -c test.f90 -I/usr/local/include

Please consider this small change so that others using the legacy compiler wrappers do not run into any unexpected issues with the placement of "-c" on the command line.

[jhendersonHDF]

Hi @martinjotte,

thanks for reporting this. When I made changes to the compiler wrappers for 2.0.0, I added a line to the help text (probably in a non-obvious spot):

All options specific to h5cc should appear BEFORE any options specified for <compile line>.

Before 2.0.0, the compiler wrappers had other issues with the compile line getting mangled due to overly-simplistic argument parsing. With the argument parsing now using shift to remove options while processing them, removing the shift from -c would cause other issues due to the fact that shift commands for the other options could end up shifting off the -c and leaving behind an h5cc-specific option. For example,

h5cc -c -norpath file.c
cc: error: unrecognized command-line option ‘-norpath’
compile failed with command: /usr/bin/cc  -norpath file.c -I/usr/include

For now, this should be considered intended behavior, but the overall argument parsing in the compiler wrappers may be able to be improved.

[martinjotte]

How about just doing a check that "-c" is the current first argument before performing the shift:

diff -up hdf5-2.1.1/config/libh5cc.in.orig hdf5-2.1.1/config/libh5cc.in
--- hdf5-2.1.1/config/libh5cc.in.orig	2026-03-23 14:25:34.000000000 -0400
+++ hdf5-2.1.1/config/libh5cc.in	2026-03-25 17:00:38.810657106 -0400
@@ -182,9 +182,10 @@ for arg in $@ ; do
       add_rpath="no"
       ;;
     -c)
-      compile_args="${compile_args:+${compile_args} }$arg"
-      shift
-
+      if test "$1" = "-c"; then
+        compile_args="${compile_args:+${compile_args} }$arg"
+        shift
+      fi
       do_link="no"
       ;;
     *)

Now this will work whether "-c" is at the start of the arguments or after the compiler-specific flags have begun.

h5fc -c -norpath -show test.f90 
/usr/local/opt/intel-compiler/bin/ifort -c test.f90 -I/usr/local/include

/h5fc -show -O3 test.f90 -c
/usr/local/opt/intel-compiler/bin/ifort -O3 test.f90 -c -I/usr/local/include

I think most people who use the legacy wrappers will assume that "-c" can be anywhere on the command line.

Another option is to give an error message if the wrapper arguments are not at $1 when the arguments are shifted. That would be better than the command succeeding but with mangled compiler flags.

[jhendersonHDF]

Thanks @martinjotte,

I'd like to do a little more testing but I think that change could work. A little hacky but that's expected since the script co-opted the -c option from compilers to make its own adjustments. I would've leaned more toward a warning/error to simplify things since the argument parsing is still very simplistic, but I'd also be happy if we can make this work for all cases.