>> Took me longer than expected but I've tested monero-wallet-cli,
>> monero-wallet-rpc, monero-blockchain-stats, monero-blockchain-export,
>> monero-blockchain-import, monero-gen-ssl-cert, and monerod. Everything
>> seems to be operating as expected though I'm running into issues
>> creating a new copy of the blockchain.
>>
>> Whether it's using monerod or monero-blockchain-import when it gets to
>> v12 (randomx introduction) I'm seg-faulting on an opt-code failure.
>> Attaching a tail of the ktrace as the full file is 161GB along with a
>> backtrace from gdb for similar reasons the .core file is 86GB. Seems
>> like a resource exhaustion that shouldn't be happening given it's only
>> suppose to take a few GB of memory and the current system has more than
>> enough memory and disk space available. This was the original intent
>> behind the {snprintf,strncat} patches as I suspect something is not
>> being freed.
>>
>> Where you able to complete a full sync Lucas?
> 
> Nope. I ran monerod for a full-sync. The experience wasn't nice, as the
> whole OS would freeze for quite long periods of times. Even so,
> painstakingly I managed to sync ~51% of the chain, and now I run into a
> SIGSEGV in RandomX, just like you (but in a different binary). I do have
> some things to try out, but I haven't gotten around to it yet.
> 

I think it might be because your port does not install the libwallet.a 
library, which is located in ${WRKBUILD}/lib/. For this reason, I like 
to define the software installation in the port itself, rather than 
trusting the build tools to do everything for me.

> 
>> Don't use -Ofast.
> 
> Please add a comment, no matter how obvious is the change.
> In particular, I tried it locally with a helloword. `-Wl,-z,relro' is
> recognized properly.
> 
> cc -O2 -pipe   -Wl,relro -o x x.c
> ld: error: cannot open relro: No such file or directory
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> So I get the feeling that your patch *is disabling* relro, now and
> noexecstack. noexecheap is the only unsupported one for ld.lld. It seems
> like the feature detection is a bit broken, as `-Wl,-z,noexecheap' ends
> up in the flags anyway, so that's something else to take a look at.
> 
>> Index: CMakeLists.txt
>> --- CMakeLists.txt.orig
>> +++ CMakeLists.txt
>> @@ -338,7 +338,7 @@ endif()
>>   if(WIN32 OR ARM OR PPC64LE OR PPC64 OR PPC)
>>     set(OPT_FLAGS_RELEASE "-O2")
>>   else()
>> -  set(OPT_FLAGS_RELEASE "-Ofast")
>> +  set(OPT_FLAGS_RELEASE "")
>>   endif()
>>   
>>   # BUILD_TAG is used to select the build type to check for a new version
>> @@ -867,15 +867,15 @@ else()
>>         add_linker_flag_if_supported("-pie" LD_SECURITY_FLAGS)
>>       endif()
>>     endif()
>> -  add_linker_flag_if_supported(-Wl,-z,relro LD_SECURITY_FLAGS)
>> -  add_linker_flag_if_supported(-Wl,-z,now LD_SECURITY_FLAGS)
>> -  add_linker_flag_if_supported(-Wl,-z,noexecstack noexecstack_SUPPORTED)
>> +  add_linker_flag_if_supported(-Wl,relro LD_SECURITY_FLAGS)
>> +  add_linker_flag_if_supported(-Wl,now LD_SECURITY_FLAGS)
>> +  add_linker_flag_if_supported(-Wl,noexecstack noexecstack_SUPPORTED)
>>     if (noexecstack_SUPPORTED)
>> -    set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,-z,noexecstack")
>> +    set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,noexecstack")
>>     endif()
>> -  add_linker_flag_if_supported(-Wl,-z,noexecheap noexecheap_SUPPORTED)
>> +  add_linker_flag_if_supported(-Wl,noexecheap noexecheap_SUPPORTED)
>>     if (noexecheap_SUPPORTED)
>> -    set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,-z,noexecheap")
>> +    set(LD_SECURITY_FLAGS "${LD_SECURITY_FLAGS} -Wl,noexecheap")
>>     endif()
>>   
>>     if(BACKCOMPAT)
>