A user was trying to use SDX 1.4.0 on a mac (Sonoma 10.14.1.1). I believe it is not an M1, but I can get more details.
They said the binary fails to launch, and when trying it via the CLI, it gets a SIGSEGV. They were familiar with the CLI so I told them how to do it that way.
When they launched ./dragonxd it actually started syncing HUSH. It turns out that binary was not the dragonxd script from hush3.git but the hushd binary renamed to dragonxd . I had them rename it to hushd and then download the correct dragonxd script and they were able to start syncing. So we know the full node binary does work in the SDX 1.4.0 release.
As a test, I had them try to launch the GUI app again, while their dragonx full node was syncing. They got the same SIGSEGV, so it seems the GUI app launching is maybe a different bug than the binary being misnamed.
A user was trying to use SDX 1.4.0 on a mac (Sonoma 10.14.1.1). I believe it is not an M1, but I can get more details.
They said the binary fails to launch, and when trying it via the CLI, it gets a SIGSEGV. They were familiar with the CLI so I told them how to do it that way.
When they launched `./dragonxd` it actually started syncing HUSH. It turns out that binary was not the `dragonxd` script from hush3.git but the `hushd` binary renamed to `dragonxd` . I had them rename it to `hushd` and then download the correct `dragonxd` script and they were able to start syncing. So we know the full node binary does work in the SDX 1.4.0 release.
As a test, I had them try to launch the GUI app again, while their dragonx full node was syncing. They got the same SIGSEGV, so it seems the GUI app launching is maybe a different bug than the binary being misnamed.
I think this was the easiest way to get things working at the time. I can test with using the script and bundling hushd instead, but the error they are getting is probably something specific with Sonoma since it was released ~3 months ago. I last tested 1.3.1 on Ventura and don't get errors with GUI wallet, but will need to test with latest release.
`When they launched ./dragonxd it actually started syncing HUSH`
This is expected if running it directly from the bundled app without passing any params. It's just renamed so other code in SD knows it's DRGX and passes chain params via code here:
https://git.hush.is/hush/SilentDragon/src/branch/master/src/connection.cpp#L452
I think this was the easiest way to get things working at the time. I can test with using the script and bundling hushd instead, but the error they are getting is probably something specific with Sonoma since it was released ~3 months ago. I last tested 1.3.1 on Ventura and don't get errors with GUI wallet, but will need to test with latest release.
@fekt I see why it is like that now. It was very surprising to me, though. Maybe SD source code should change and hushdProgram should not be set to "dragonxd". I think that Windows cannot execute a .bat file from QT but is it also true that OSX cannot run a bash script from QT?
@fekt I see why it is like that now. It was very surprising to me, though. Maybe SD source code should change and hushdProgram should not be set to "dragonxd". I think that Windows cannot execute a .bat file from QT but is it also true that OSX cannot run a bash script from QT?
@duke OSX can run the script fine so no change is needed. I had the dragonx scripts and hushd in 3.9.4 mac release. In 3.10.0 I must have renamed hushd as a quick hack while testing and not realizing the scripts weren't there. That's how it got into SDX. The mac 3.10.0 release doesn't even have hushd and I didn't realize that until now 😆
It works either way with the code in SDX but I'll fix in latest release.
@duke OSX can run the script fine so no change is needed. I had the dragonx scripts and hushd in 3.9.4 mac release. In 3.10.0 I must have renamed hushd as a quick hack while testing and not realizing the scripts weren't there. That's how it got into SDX. The mac 3.10.0 release doesn't even have hushd and I didn't realize that until now 😆
It works either way with the code in SDX but I'll fix in latest release.
1.4.1 SD/SDX run fine for me on Monterey (compiled on) and Ventura (downloaded installer from release page). With Ventura it's on an M1 Max. I can upgrade to Sonoma and test later. They might want to try latest release. There are multiple warnings, firewall, etc to get around. On a fresh install, it seemed to take ~15 minutes to get connected to some peers.
1.4.1 SD/SDX run fine for me on Monterey (compiled on) and Ventura (downloaded installer from release page). With Ventura it's on an M1 Max. I can upgrade to Sonoma and test later. They might want to try latest release. There are multiple warnings, firewall, etc to get around. On a fresh install, it seemed to take ~15 minutes to get connected to some peers.
I upgraded to Sonoma 14.2.1 and 1.4.1 still works fine. Either the 3.10.0/1.4.0 Mac bins are junk or something else up but hopefully latest releases work for them.
I upgraded to Sonoma 14.2.1 and 1.4.1 still works fine. Either the 3.10.0/1.4.0 Mac bins are junk or something else up but hopefully latest releases work for them.
fekt
A user was trying to use SDX 1.4.0 on a mac (Sonoma 10.14.1.1). I believe it is not an M1, but I can get more details.
They said the binary fails to launch, and when trying it via the CLI, it gets a SIGSEGV. They were familiar with the CLI so I told them how to do it that way.
When they launched
./dragonxdit actually started syncing HUSH. It turns out that binary was not thedragonxdscript from hush3.git but thehushdbinary renamed todragonxd. I had them rename it tohushdand then download the correctdragonxdscript and they were able to start syncing. So we know the full node binary does work in the SDX 1.4.0 release.As a test, I had them try to launch the GUI app again, while their dragonx full node was syncing. They got the same SIGSEGV, so it seems the GUI app launching is maybe a different bug than the binary being misnamed.
When they launched ./dragonxd it actually started syncing HUSHThis is expected if running it directly from the bundled app without passing any params. It's just renamed so other code in SD knows it's DRGX and passes chain params via code here:
https://git.hush.is/hush/SilentDragon/src/branch/master/src/connection.cpp#L452
I think this was the easiest way to get things working at the time. I can test with using the script and bundling hushd instead, but the error they are getting is probably something specific with Sonoma since it was released ~3 months ago. I last tested 1.3.1 on Ventura and don't get errors with GUI wallet, but will need to test with latest release.
@fekt I see why it is like that now. It was very surprising to me, though. Maybe SD source code should change and hushdProgram should not be set to "dragonxd". I think that Windows cannot execute a .bat file from QT but is it also true that OSX cannot run a bash script from QT?
@duke OSX can run the script fine so no change is needed. I had the dragonx scripts and hushd in 3.9.4 mac release. In 3.10.0 I must have renamed hushd as a quick hack while testing and not realizing the scripts weren't there. That's how it got into SDX. The mac 3.10.0 release doesn't even have hushd and I didn't realize that until now 😆
It works either way with the code in SDX but I'll fix in latest release.
1.4.1 SD/SDX run fine for me on Monterey (compiled on) and Ventura (downloaded installer from release page). With Ventura it's on an M1 Max. I can upgrade to Sonoma and test later. They might want to try latest release. There are multiple warnings, firewall, etc to get around. On a fresh install, it seemed to take ~15 minutes to get connected to some peers.
I upgraded to Sonoma 14.2.1 and 1.4.1 still works fine. Either the 3.10.0/1.4.0 Mac bins are junk or something else up but hopefully latest releases work for them.