Re: [NEW WIP]: net/monero (help needed)

>> 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)
>