Bliako, you are correct, my solution was not robust. It failed completely on newer versions of macOS with SIP (system integrity protection). It seems that moving the dylib to a non-standard location is a security risk known as "dylib hijacking." Apple has added checks to prevent this.

https://www.virusbulletin.com/virusbulletin/2015/03/dylib-hijacking-os-x

I was able to find a proper solution by linking the the Rmath library into the XS bundle. When compiling the Rmath dylib, an archive file is also produced – libRmath.a. This file is a compilation of the object (.o) code that went into the dylib. I changed a couple of lines in my Makefile.PL, removing the '-lRmath' from the 'LIBS' entry, and adding a new 'MYEXTLIB' line,

use 5.018002;
use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
    NAME              => 'ICC::Support::Rmath',
    VERSION_FROM      => 'lib/ICC/Support/Rmath.pm', # finds $VERSION
    PREREQ_PM         => {}, # e.g., Module::Name => 1.1
    ($] >= 5.005 ?     ## Add these new keywords supported since 5.005
      (ABSTRACT_FROM  => 'lib/ICC/Support/Rmath.pm', # retrieve abstra
+ct from module
       AUTHOR         => 'William Birkett <wbirkett@doplganger.com>') 
+: ()),
    LIBS              => [], # e.g., '-lm'
    DEFINE            => '', # e.g., '-DHAVE_SOMETHING'
    INC               => '-I.', # e.g., '-I. -I/usr/include/other'
    MYEXTLIB => '/usr/local/lib/libRmath.a',
    # Un-comment this if you add C files to link with later:
    # OBJECT            => '$(O_FILES)', # link all the C files too
);
[download]

This change compiles the library code into the XS bundle, so the dylib is no longer required in my distribution. Everything works fine now. I sure wish there was better documentation for making XS modules.

Thanks, again, for your help.