Forcing static linking with Intel compiler?

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Hi,

sind ages, I am carrying a patch that drops the -static-libxca that
pkgsrc enforces when using the Intel compiler. I don't use it often, in
fact, the new OneAPI branding with differing compiler names trips up
things for sure, anyway. But to the point, the comment in my patch
should be explicit enough:

diff -ruN -x CVS pkgsrc-cvs/./mk/wrapper/cmd-sink-icc-cc pkgsrc/./mk/wrapper/cmd-sink-icc-cc
--- pkgsrc-cvs/./mk/wrapper/cmd-sink-icc-cc	2019-03-23 11:45:06.520162028 +0100
+++ pkgsrc/./mk/wrapper/cmd-sink-icc-cc	2019-03-25 01:31:50.605903351 +0100
@@ -32,7 +32,10 @@
 # icc provided libraries. use the static linking method so binary
 # packages can be used on systems that do not have these libraries
 # available.
-arg=-static-libcxa
+# ThOr: Nope, we take care of library paths here, thank you.
+# Also, this seems to break as early as building perl, which doesn't
+# use any libcxa, but still gets non-PIC binaries where they don't fit.
+arg=
 $debug_log $wrapperlog "    (cmd-sink-icc-cc) pop:  $arg"
 . $buildcmd


Is it actually a thing that someone builds binary packages with icc
that need static linking to be distributed? Does it even _work_? As
indicated, I quickly had trouble with PIC mismatch when forcing in the
static icc libs, as you often do on current platforms. Maybe that's
fixed with current compiler releases … but generally: My use case
involves the toolchain being available at runtime, too. And you don't
statically link in the whole MKL, do you?

Can this be dropped from pkgsrc? Otherwise … I can continue to carry
that patch, it's not high-maintenance.


Alrighty then,

Thomas


-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg