Startup Error on OSX Build

[rabarar]

Was able to successfully build SigDigger for OSX 12.3 - but when I run it I get a pop-up on startup -

Error occurred during startup:

exception in "dir_url = ..." exception in "dir_url = ..."

[BatchDrake]

Hi Rob,

Can you provide details on how you built SigDigger and all its dependencies? What branch have you cloned from? The master branch is rather old now and will be updated soon with the changes in the develop branch (which is already in feature freeze state)

On the other hand, there is a script in SigDigger sources that performs all building steps automatically, resulting in a .dmg file you can open as any other piece of software. Just clone SigDigger from develop, go to the Scripts folder and run ./dist-dmg.sh (you don't even need to clone suscan / sigutils / SuWidgets, as this script does all that for you)

Cheers,

[grantbarrett]

I was not able to build SigDigger 0.2.0 or the development branch (0.3.0) for macOS 12.3.1 using the provided dist-dmg.sh script. Both failed at the building SuWidgets stage. On 0.3.0, an error was thrown:

`In file included from Waterfall.cpp:40: ./Waterfall.h:41:10: fatal error: 'QOpenGLWidget' file not found

include `

OpenGL is deprecated on macOS, but I installed the Homebrew glfw and glew libraries in case that helped; it did not. I also have qt5 and qt6 installed with Homebrew.

I am enclosing the make logs for both build attempts.

Also, the prebuilt development binary available for download also does not run. It opens, shows just the SigDigger menu next to the Apple menu, then locks up with the spinning beach ball. The 0.2.0 binary loads further, to the app splash screen, but then it crashes. I am enclosing a spindump from development version lockup.

make-62721-stderr.log make-62721-stdout.log 0.2.0 make-61414-stderr.log 0.2.0 make-61414-stdout.log SpindumpSample of SigDigger.txt

[BatchDrake]

Hi @grantbarrett

1. The QOpenGLWidget issue is definitely a build issue from my part, my apologies. It turns out that, in some systems, Qt5 will not find the OpenGL include directories unless explicitly enabled. I have just fixed that, both in SuWidgets and SigDigger. Could you please run dist-dmg.sh again?
2. Don't bother to build SigDigger in Qt6, it is not going to work. I only support Qt5 for the time being (although plans to move to Qt6 exist).
3. Regarding the startup issues you are experiencing with the prebuilt binaries, I am afraid I will not be able to debug them until I lay my hands on a more or less modern macOS system. Could you please open a separate issue so we can track its state more easily?

[grantbarrett]

@BatchDrake Thank you for the prompt response. To try to solve the OpenGL/Qt problem, I have run the build numerous times and ways, and it always fails. I have tried it with the same change in the SigDigger.pro file that you made in the commit — and only that change — and I have also tried with everything in the commit tree since the last release.

I took a look at the stderr.log, and it seems to be referencing Qt6, and as you said that is not supported, I tried a build after make a different change to the same line you changed in SigDigger.pro. I changed it to:

equals(QT_VERSION, 5): QT += widgets opengl

Unfortunately, that didn't work, either, as the build failed and stderr.log looks pretty much the same. I am enclosing it here.

I will make a new issue for #3, regarding lockup with launching the app.

make-81358-stderr.log make-81358-stdout.log

[BatchDrake]

Check your logs again. You are still attempting to build SigDigger with Qt6.

[BatchDrake]

Just out of curiosity, where is Qt5 installed in your system? Maybe this is a mere PATH issue, and that's easy to fix.

[grantbarrett]

Sorry, I'm in the middle of moving over to a new laptop so things are in flux right now. I'll try this all again when I get everything setup on the new machine.

[BatchDrake]

Cool. I am having trouble getting my hands on a macOS 12.3 laptop, could I give you some directions on how to build everything in debug mode instead? I hope we can get more meaningful information in the crash logs this way.

[grantbarrett]

Yes! The new laptop is up and running. I have both osx-x86_64 and osx-aarch_64 systems and can attempt builds on either or both. I am somewhat of a dilettante, so feel free to be very specific and assume I don't know stuff. I won't be offended. I use homebrew and sdk, so I should be able to install exactly what is needed.

[rabarar]

@BatchDrake I thought I replied - the issues comes from the Suscan libraries

% suscli devices
[e] suscan_bundle_get_resource_path:45: exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void*)0), ((void*)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45)
[e] suscan_bundle_get_resource_path:45: exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void*)0), ((void*)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45)
[INFO] Opening Generic RTL2832U OEM :: 00000001...
[INFO] Opening Generic RTL2832U OEM :: 00000001...
 ndx Device name                              Driver   Interface Availability 
------------------------------------------------------------------------------
[ 0] Dummy device                             null     local     available
[ 1] rtlsdr (Generic RT(...)U OEM :: 00000001 rtlsdr   local     unavailable

[BatchDrake]

@grantbarrett we are mixing up two different issues in the same thread, send me an e-mail to BatchDrake@gmail.com and I'll guide you from there.

@rabarar your issue is related to a failure locating the application bundle. How did you build / install SigDigger? Did you use the dist-dmg.sh script in the Scripts folder?

[rabarar]

I built everything from source… I didn’t use the script.

On Apr 11, 2022, at 5:47 AM, Gonzalo José Carracedo Carballal @.***> wrote:

 @grantbarrett we are mixing up two different issues in the same thread, send me an e-mail to @.*** and I'll guide you from there.

@rabarar your issue is related to a failure locating the application bundle. How did you build / install SigDigger? Did you use the dist-dmg.sh script in the Scripts folder?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[BatchDrake]

I see the issue now, I never thought anybody would build suscan outside SigDigger in macOS X, but this is clearly a limitation from my part. suscli is attempting to look for an application bundle that simply does not exist.

I already have an idea of how I'd fix this, but I will need some extra information. When you ran make install (or cmake --install) you should have seen a bunch of paths ending in suscan/config/(blablabla).yaml printed to the terminal, could you paste any of them here? I only need the ones that end in .yaml, one will suffice.

[andreascla]

I have a similar issue and happy to help out with the information you need!

All components and SigDigger itself was successfully compiled on my Mac Book Pro M1. However, when I run suscli devices I get a similar error message as above:

% suscli devices
10 May 2022 - 13:41:38   exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void*)0), ((void*)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45)
10 May 2022 - 13:41:38   exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void*)0), ((void*)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45)
 ndx Device name                              Driver   Interface Availability
------------------------------------------------------------------------------
[ 0] Dummy device                             null     local     unavailable

SigDigger does start, but when I try to replay a RAW file, I get an error message with exceptions that I think is related to this problem as well.

Anyhow, I can't see any output with paths to .yaml files. Where am I supposed to see them, when building suscan?

[BatchDrake]

Yes, during the install step. Those are the paths I am missing.

[andreascla]

Ah, I saw it now: /usr/local/share/suscan/config/autogains.yaml

[BatchDrake]

Got it, thanks! I believe I should be able to fix this in a few hours.

[andreascla]

Awesome! Let me know if you need more information or testing 👍

[BatchDrake]

Just checked it out, and the current implementation should work out of the box. I believe the problem is somewhere else. Could you run the following commands and paste the output here?

% file `which suscli`
% file /usr/local/lib/SoapySDR/modules*/*

If the second command fails, maybe the problem is related to the SoapySDR installation.

[andreascla]

% file `which suscli`
/usr/local/bin/suscli: Mach-O 64-bit executable arm64
% file /usr/local/lib/SoapySDR/modules*/*
zsh: no matches found: /usr/local/lib/SoapySDR/modules*/*

I recompiled everything on another Mac M1 and I don't get the error when running suscli devices anymore. However, the error message when replaying a raw file in SigDigger is still there:

Failed to start capture due to errors:
info: Data format detected: 32 bit float
error: Failed to open /Users/andreas/Downloads/gqrx_20220510_192204_434411800_8000000_fc.raw as raw file: Internal error : SF_INFO struct incomplete.
error: exception in "suscan_source_open_file(new)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:2492)
error: exception in "self->source = suscan_source_new(config)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:508)
error: Failed to initialize source
error: exception in "new->impl = (iface->ctor) (new, ap)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:606)

But maybe this is an unrelated issue?

[BatchDrake]

This looks like a totally unrelated (albeit surprising) issue. I'll look into it later this week.

El mar., 10 may. 2022 21:56, Andreas Claesson @.***> escribió:

% file which suscli /usr/local/bin/suscli: Mach-O 64-bit executable arm64 % file /usr/local/lib/SoapySDR/modules/ zsh: no matches found: /usr/local/lib/SoapySDR/modules/

I recompiled everything on another Mac M1 and I don't get the error when running suscli devices anymore. However, the error message when replaying a raw file in SigDigger is still there:

Failed to start capture due to errors: info: Data format detected: 32 bit float error: Failed to open /Users/andreas/Downloads/gqrx_20220510_192204_434411800_8000000_fc.raw as raw file: Internal error : SF_INFO struct incomplete. error: exception in "suscan_source_open_file(new)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:2492) error: exception in "self->source = suscan_source_new(config)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:508) error: Failed to initialize source error: exception in "new->impl = (iface->ctor) (new, ap)" (build/CMakeFiles/suscan.dir/compiler_depend.ts:606)

But maybe this is an unrelated issue?

— Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/178#issuecomment-1122802556, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVET65RO4RVTXPRXLTASDVJK5NPANCNFSM5SDZQEMQ . You are receiving this because you were assigned.Message ID: @.***>

[andreascla]

Ok great, as you probably can see, I'm trying to open a raw file captured with GQRX.

Also, I can confirm that my build of SigDigger now works fine with HackRF, so the SoapySDR lib looks ok.

[andreascla]

Ok great, as you probably can see, I'm trying to open a raw file captured with GQRX.

Do you want me to create a separate issue for this problem?

[BatchDrake]

Yes please, these are two different issues. Thanks!

[rabarar]

Took a closer look later night and it’s coming from the suscan code. You can close out the issue. I opened it with suscan. Here’s the output when I ran suscli: ./suscli devices
[e] suscan_bundle_get_resource_path:45: exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void)0), ((void)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45) [e] suscan_bundle_get_resource_path:45: exception in "dir_url = CFBundleCopyResourceURL( main_bundle, relpath, ((void)0), ((void)0) )" (build/CMakeFiles/suscan.dir/compiler_depend.ts:45)

On Mar 31, 2022, at 4:35 AM, Gonzalo José Carracedo Carballal @.***> wrote:

 Hi Rob,

Can you provide details on how you built SigDigger and all its dependencies? What branch have you cloned from? The master branch is rather old now and will be updated soon with the changes in the develop branch (which is already in feature freeze state)

On the other hand, there is a script in SigDigger sources that performs all building steps automatically, resulting in a .dmg file you can open as any other piece of software. Just clone SigDigger from develop, go to the Scripts folder and run ./dist-dmg.sh (you don't even need to clone suscan / sigutils / SuWidgets, as this script does all that for you)

Cheers,

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[rabarar]

I see no config files with yaml extensions; rather xml extensions - here’s the full make install below:

% sudo make install Consolidate compiler generated dependencies of target suscan [ 71%] Built target suscan Consolidate compiler generated dependencies of target suscan.status [ 78%] Built target suscan.status Consolidate compiler generated dependencies of target suscli [100%] Built target suscli Install the project... -- Install configuration: "Debug" -- Installing: /usr/local/lib/pkgconfig/suscan.pc -- Up-to-date: /usr/local/include/suscan/analyzer/discovery.h -- Up-to-date: /usr/local/include/suscan/analyzer/realtime.h -- Up-to-date: /usr/local/include/suscan/analyzer/msg.h -- Up-to-date: /usr/local/include/suscan/analyzer/local.h -- Up-to-date: /usr/local/include/suscan/analyzer/remote.h -- Up-to-date: /usr/local/include/suscan/analyzer/inspsched.h -- Up-to-date: /usr/local/include/suscan/analyzer/spectsrc.h -- Up-to-date: /usr/local/include/suscan/analyzer/worker.h -- Up-to-date: /usr/local/include/suscan/analyzer/estimator.h -- Up-to-date: /usr/local/include/suscan/analyzer/serialize.h -- Up-to-date: /usr/local/include/suscan/analyzer/source.h -- Up-to-date: /usr/local/include/suscan/analyzer/symbuf.h -- Up-to-date: /usr/local/include/suscan/analyzer/mq.h -- Up-to-date: /usr/local/include/suscan/analyzer/throttle.h -- Up-to-date: /usr/local/include/suscan/analyzer/analyzer.h -- Up-to-date: /usr/local/include/suscan/analyzer/inspector/inspector.h -- Up-to-date: /usr/local/include/suscan/analyzer/inspector/params.h -- Up-to-date: /usr/local/include/suscan/analyzer/inspector/interface.h -- Up-to-date: /usr/local/include/suscan/codec/codec.h -- Up-to-date: /usr/local/include/suscan/util/cbor.h -- Up-to-date: /usr/local/include/suscan/util/compat.h -- Up-to-date: /usr/local/include/suscan/util/hashlist.h -- Up-to-date: /usr/local/include/suscan/util/macos-barriers.h -- Up-to-date: /usr/local/include/suscan/util/macos-barriers.imp.h -- Up-to-date: /usr/local/include/suscan/util/confdb.h -- Up-to-date: /usr/local/include/suscan/util/cfg.h -- Up-to-date: /usr/local/include/suscan/util/object.h -- Up-to-date: /usr/local/include/suscan/util/rbtree.h -- Up-to-date: /usr/local/include/suscan/util/sha256.h -- Up-to-date: /usr/local/include/suscan/analyzer/version.h -- Up-to-date: /usr/local/include/suscan/cli/audio.h -- Up-to-date: /usr/local/include/suscan/cli/chanloop.h -- Up-to-date: /usr/local/include/suscan/cli/cli.h -- Up-to-date: /usr/local/include/suscan/cli/cmds.h -- Up-to-date: /usr/local/include/suscan/cli/datasaver.h -- Up-to-date: /usr/local/include/suscan/cli/devserv.h -- Up-to-date: /usr/local/share/suscan/config/autogains.xml -- Up-to-date: /usr/local/share/suscan/config/palettes.xml -- Up-to-date: /usr/local/share/suscan/config/frequency_allocations.xml -- Installing: /usr/local/lib/libsuscan.0.2.0.dylib objc[12797]: Class AppleTypeCRetimerRestoreInfoHelper is implemented in both /usr/lib/libauthinstall.dylib (0x203e5deb0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc4f8). One of the two will be used. Which one is undefined. objc[12797]: Class AppleTypeCRetimerFirmwareAggregateRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x203e5df00) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc548). One of the two will be used. Which one is undefined. objc[12797]: Class AppleTypeCRetimerFirmwareRequestCreator is implemented in both /usr/lib/libauthinstall.dylib (0x203e5df50) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc598). One of the two will be used. Which one is undefined. objc[12797]: Class ATCRTRestoreInfoFTABFile is implemented in both /usr/lib/libauthinstall.dylib (0x203e5dfa0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc5e8). One of the two will be used. Which one is undefined. objc[12797]: Class AppleTypeCRetimerFirmwareCopier is implemented in both /usr/lib/libauthinstall.dylib (0x203e5dff0) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc638). One of the two will be used. Which one is undefined. objc[12797]: Class ATCRTRestoreInfoFTABSubfile is implemented in both /usr/lib/libauthinstall.dylib (0x203e5e040) and /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1067bc688). One of the two will be used. Which one is undefined. 2022-04-11 08:58:41.617 xcodebuild[12797:5587951] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore 2022-04-11 08:58:41.618 xcodebuild[12797:5587951] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore -- Up-to-date: /usr/local/lib/libsuscan.dylib -- Installing: /usr/local/bin/suscan.status -- Installing: /usr/local/bin/suscli

On Apr 11, 2022, at 8:24 AM, Gonzalo José Carracedo Carballal @.***> wrote:

I see the issue now, I never thought anybody would build suscan outside SigDigger in macOS X, but this is clearly a limitation from my part. suscli is attempting to look for an application bundle that simply does not exist.

I already have an idea of how I'd fix this, but I will need some extra information. When you ran make install (or cmake --install) you should have seen a bunch of paths ending in suscan/config/(blablabla).yaml printed to the terminal, could you paste any of them here? I only need the ones that end in .yaml, one will suffice.

— Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/178#issuecomment-1094985469, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB2J6H2ZGJWN7OSPRAE7GLVEQKYLANCNFSM5SDZQEMQ. You are receiving this because you were mentioned.

[BatchDrake]

No yaml files implies Suscan 0.2 or earlier. Could you clone all repos again and rebuild everything again?