libsodium patch

[smanders]

libsodium was added summer 2021 https://github.com/smanders/externpro/issues/317 and updated end of the year 2021 https://github.com/smanders/externpro/issues/330 including a change that fixed an illegal instruction the current sodium.patch for cmake build support https://github.com/jedisct1/libsodium/compare/aa099f5e82ae78175f9c1c48372a123cb634dd92...smanders:xp21.11.18

there's now an additional system/processor experiencing an illegal instruction

[smanders]

the configure.cmake

• checks that intrinsic instructions are available on the build system and sets a define if they are available
• if the define is set (for example HAVE_AVXINTRIN_H), then check_compiler_opt() is called with a -m option (for example -mavx) and if the compiler supports that option, it is added to the pvtOpts list
• the pvtOpts list is used to set compiler options with target_compile_options(${lib_name} PRIVATE ${pvtOpts})

what was found: the externpro build system would find intrinsic instructions available and set the define, then set the compiler option -- which allows the compiler to use these instructions to optimize code -- but then these instructions wouldn't be an option on a runtime system that doesn't have the instructions available

[smanders]

the change to configure.cmake (see commit above) will not check/set the compiler option for

• -msse3
• -mavx
• -mavx2
• -mavx512f
• -mrdrnd

all of these, except sse3, have an #ifdef __native_client__ in the code check to avoid these opcodes and I considered defining this instead of disabling the compiler option checks, but then the define isn't set and there appears to be value in having the define because then code is compiled in and if the opcodes are found to be available at runtime they can be used -- we just can't let the compiler have free reign on using these opcodes (which is what the -m options give it)

[smanders]

completed with commits referenced above (one to libsodium fork, one to externpro)

[smanders]

email from cheaps

From: Chris Heaps Date: Tuesday, December 13, 2022 at 8:02 AM To: Scott M Anderson Subject: Externpro - libsodium

I have attached a configure.cmake file. (I was going to try to make a pull to your branch on github, but after looking at it for a minute I figured that this would probably just be easier for both of us) The changes in this file should include commenting out the sections where any ‘-m’ modes are enabled that are not supported on my “minimum hardware.” This included avx, avx2, avx512f, and rdrand. I then built externpro (on my local machine) after giving libsodium this file, and the susequent builds of vantBroker and DDE (based off of the updated externpro) successfully run on the crappy hardware.

I also spent a few minutes looking into what Windows is doing. From what I can tell Visual Studio defaults to sse2 instructions unless it is explicitly told (ex. /arch:avx) that avx, avx2, or avx512 are acceptable. This is good for now, but we should keep it in mind that when we have an increase in the minimum hardware, there are potential speedups by telling Visual Studio that it can generate code using avx*.

Thanks, Christopher Heaps