JS8Call-improved
Replies: 7 comments 4 replies
|
I was able to solve the problem building JS8Call 4.0-b1 with Hamlib 4.7.2 with QtCreator: I found I needed to build Hamlib (I used JTSDK64-Tools to build) with the -static flag, then it worked. I had to also copy libhamlib.dll.a which was generated in a dynamic build of 4.7.2 into the js8lib/hamlib/lib directory. Strange! But it worked, and I won't argue with success. So, as far as I can tell, Hamlib 4.7.2 will be good. If you guys have a chance, do some testing with it to see what you think. According to the changelog, there are some improvements/fixes for some of the newer rigs. 73, |
|
I don't see switching to Hamlib 4.7.2 happening any time soon. It would only go into master, and JS8Call 4.0 will not be released this year. I also don't see moving to Hamlib 5.0 just because it appears. We'll let the Hamlib guys finalize their 4.7 long term support release before we make any more changes to Hamlib. Chasing the latest biggest Hamlib number is like chasing your tail. |
|
It's worth keeping up with though. We should be ready and aware of its status, and it is of value for us to test it in case we need to suggest something to help them with development. We are, after all, a significant end-user of the product. I don't see anything pressing in the changelog that would make 4.7.2 a priority upgrade, so not a big deal at this point I don't think. 73, |
|
@Joe-K0OG there must be something misconfigured or wrong with your build environment. I updated the PowerShell script on js8lib in the Windows branch, built a new library with it with Hamlib 4.7.2. Test built it with Qt Creator and it runs out-of-the-box with no .dll shenanigans required. I'm not going to update the library on js8lib with the new build, however. It's not worth it at this point. We'll let them stabilize their 4.7-series releases before getting exited about it since we don't have any releases planned anytime soon anyway. If individual developers want to chase their constant version bumping and test it, that's fine. But the JS8Call project itself is not going do that unless there's a compelling reason to change it. I mean, for pete's sake, the newest Hamlib most of the linux distro's got is 4.6.5 and that likely won't change for two years. Even Ubuntu 26 ships with Hamlib 4.6.5 and Debian 13 ships with 4.6.2. |
|
Chris - Good - you did exactly what I hoped: Tested it, and it works. I like to keep an eye out for bugs as things progress. Agreed, no compelling reason to push 4.7.2 out. Good evening & 73, |
|
@Joe-K0OG I updated the workflows for all three platforms to use Hamlib 4.7.2, mainly as an exercise to see what's involved with the new library/workflow system. As part of that I created an automated library build system for linux with a workflow on js8lib. This will make it easier in the future since I can now build standard libraries for both arm64 and amd64 linux in about 6 1/2 minutes on js8lib. |
|
@Chris-AC9KH I tested the Linux and Windows js8libs 4.0, and they work fine on both platforms. Good work! 73, |
|
It's pretty easy to change library versions. Just replace the libraries on js8lib and the workflows use the new libraries. The only thing that needs to be changed is on the Windows workflow for the cmake prefix path. So it should be a fully repeatable and stable system - fully scripted library builds, workflows use our own internally hosted libs and do not depend on upstream, using the LLVM/clang compiler and toolchain across all three platforms. The only thing I wonder about, and maybe @wmiler can comment; now that's it's all working, should I move the AppImage building shell script to .github/workflows/scripts? Or leave it in the tools directory? It can still be run locally from either place, but it was not really intended to be an end-user script. It was an experiment to see if I could get a runner to run a bash shell script instead of trying to define everything with yaml code in a workflow file. And it works very well, with a backup that can be run locally on anybody's machine so we no longer actually DEPEND on a GitHub runner to create a release build. IMO it should probably go in .github/workflows/scripts with the Inno one, but wanted your thoughts on it. |
|
From an end-user's point of view, either in tools or .github/workflows/scripts makes no difference to me. As long as we have access to the scripts in case a user wants or needs them, the location is not too important. A text file in tools explaining the scripts (and their location, if elsewhere) might be helpful, if the tools directory still exists. 73, |
|
There's a lot of other scripts in tools. We got the end-user build script there that now handles either architecture and works on Debian, Redhat or Arch systems - all in one script. We got one there to test building different versions of Qt for linux. And we got the experimental one that makes a .deb. Plus some source files for diagnosing issues or problems with the decoder. So tools is not going away. It's that one script that is used regularly in the workflows that I'm wondering if it's in the right place. |
|
And yeah, a simple README in tools might be helpful to explain what the various scripts do. |
Uh oh!
There was an error while loading. Please reload this page.
I noticed that Hamlib 4.7.2 has been released. I thought it would be a no-brainer to roll it into JS8Call, and indeed on Linux and the Windows JTSDK64-Tools build systems, it works fine.
However, when I attempt to build JS8Call on Windows with QtCreator, I can get it to build without errors, but when I attempt to execute JS8Call, it flags a "(null).DLL not found" error. This error is flagged whether I use the Windows 64-bit download from the Hamlib Github repository, or use a version I've built locally with JTSDK64-Tools. I've tried replacing all the .dll files with ones I know work, but nothing I've tried so far fixes the problem.
We are certainly under no immediate pressure to move to 4.7.2, but would be good if we could without too much effort. Perhaps Hamlib 5 is not far off, and we could just wait until then, which will likely require more effort as @Chris-AC9KH has previously pointed out.
73,
-Joe-
K0OG
All reactions