Would love to see a Mac OS build of this!

[smdjeff]

[thelastronin]

I tried to compile it some time ago and hit a dead-end. For SuWidgets, I needed to do these changes in the makefile:

Replace clang with gcc-8, clang++ with g++-8 (GCC 8.3, Qt 5.13) Remove the "-stdlib=libc++" Replace "/usr/include" with "/usr/local/include"

To compile SuScan I replaced libtoolize with glibtoolize in autogen.sh.

But IIRC the main problem was ALSA which SigUtils depends on, and to my knowledge it can't be compiled on Mac (I hope I'm wrong)

I would love to help with testing the Mac issue, so let me know if I can help.

[BatchDrake]

Good point about SuWidgets. I'll have it in mind.

Regarding the ALSA dependency, I have some good news: I've just removed it from sigutils (it was a bogus dependency from the old source API - before SoapySDR). It should build now.

Bad news: this is not going to make SigDigger work. The ALSA dependency is still there because of the sound preview and it is necessary. One option is to modify Audio/AudioPlayback.cpp and transform the AudioPlayback.cpp class into a dummy class that does nothing, and then remove the ALSA dependency from SigDigger.pro.

I'm a little busy now implementing some extra features in SigDigger related to data decoding (mainly a frame synchronizer and a descrambler). But since I see some progress here, I may reprioritize this. Thanks!

[smdjeff]

Could you check in the ALSA dependency change? Then @thelastronin might fork and we could work on the Mac build and submit a PR back.

[BatchDrake]

Changes should be in sigutils' master branch now. Regarding SigDigger, I could conditionally disable ALSA and audio playback support for non-Linux systems. I'm going to work on this now, I'll keep you updated.

[BatchDrake]

Done, changes are in SigDigger's master. Now, if ALSA is not found and you attempt to start the audio preview, it will show a message indicating that the ALSA support is missing (while not blocking you from doing other things). Try it out!

[thelastronin]

It's weird that I didn't get any notifications for your replies, although I've enabled them for this repo and thread. Anyway, I pulled the recent changes and tried to (re)compile. I followed the doc's steps, which means compile sigutils, suscan, suwidgets in that order.

1- Sigutils compiled without any issues.

2- Suscan: I faced multiple issues and had to change many places in Makefile and configure, etc. Here are the list of the changes:

• changed gcc to gcc-9 in all the Makefiles
• replaced libtoolize with glibtoolize in autogen.sh
• changed xml2_CFLAGS in all the Makefiles to point to brew's (rather than the /usr/include)
• manually added a GLIB_COMPILE_SCHEMAS env var to point to glib-compile-schemas
• there's no support for pthread barriers on Mac, so I added a short code to analyzer/analyzer.h to fix it. I used this: https://blog.albertarmea.com/post/47089939939/using-pthreadbarrier-on-mac-os-x

These changes fixed all the compile time errors, but then I ran into link time errors ! The linker flags --whole-archive and --allow-multiple-definition are not supported on any C compilers on Mac (I tested default gcc, brew gcc-9, and llvm-gcc). Removing the former seems not to be an issue, but removing the latter runs into link time errors (duplicate symbols)

Any ideas?

[BatchDrake]

Hi!

I've just added some changes that may ease the build now. Regarding your changes:

• Instead of changing gcc to gcc-9 in Makefiles directly (which can be pretty cumbersome) I suggest you run next time:

% CC=gcc-9 ./configure 

This way Makefiles will be generated with gcc-9 directly. However, this is still a workaround. A more sensible approach would be to detect the platform in configure.ac and conditionally set a different compiler (like clang) as default option. Or even better: throw the whole Autotools-based build system away and start from scratch using CMake.

• The libtoolize problem should be fixed in Suscan's autogen.sh now. If it works for you, I'll implement the same trick in sigutils.
• Could you please describe your issue with libxml2? If the build is breaking because I'm using some unsupported part of the xml2 API in Mac, I'd prefer to adapt the existing code instead of adding more external dependencies to the code.
• GLIB_COMPILE_SCHEMAS was a bogus dependency coming from the former GTK GUI. I've just removed it, changes in master.
• The issue with barriers is unfortunate and will need some careful handling from my side. I guess I will have to create some kind of compat library in order to fix these OS-dependant issues. But in this case, I think it pays off now to rethink the whole thing having Windows in mind.

Regarding your problems in linking time, I removed those flags (they were useless nonetheless) and changed the linking order of a couple of libraries. Do you mind pulling from master and trying to build again?

Thank you very much!

[thelastronin]

Hi Thanks for the changes.

Could you please describe your issue with libxml2?

The issue was that the path to the correct libxml2 include folder was not properly set in the Makefile and I had to change it manually to be able to compile.

So I pulled the new code and tried to compile: There is again a link time error for duplicate symbols related to pthread_barrier functions. As I'm not an expert in C/C++ and it's 1:30 AM here, I just made those 3 functions as inline and managed to compile and install suscan as well (I should probably figure out a better way than inlining them) Then I tried to compile SuWidgets. I had to change clang to gcc-9, clang++ to g++-9 and remove -stdlib=libc++ to be able to proceed with compile, but I got a link time error at the end! It's long, so I only copy the head and tail of the error:

Undefined symbols for architecture x86_64: "std::ctype::_M_widen_init() const", referenced from: ..... ..... SymView::save(QString const&, SymView::FileFormat) in SymView.o SymView::save(QString const&, SymView::FileFormat) (.cold) in SymView.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. "___cxa_throw_bad_array_new_length", referenced from: Waterfall::getScreenIntegerFFTData(int, int, float, float, long long, long long, float*, int*, int*, int*) (.cold) in Waterfall.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [libsuwidgets.1.0.0.dylib] Error 1 make: *** [release] Error 2

P.S: I'm gonna continue and post with my other account from now on (@mehdideveloper), as it's easier to get notifications on that.

[mehdideveloper]

I'm not sure if it helps or not, but I also tried with gcc-4.9 and gcc-5 and got the same link time error

[BatchDrake]

Interesting, could you share make's output? I would like to know which symbols are being linked twice.

El lun., 30 sept. 2019 13:50, Mehdi [email protected] escribió:

I'm not sure if it helps or not, but I also tried with gcc-4.9 and gcc-5 and got the same link time error

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/12?email_source=notifications&email_token=AAEVET3H3QITWAU5KJFVHLTQMHRXLA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75L6IQ#issuecomment-536526626, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEVET2JA5M2LCK5ACNQAODQMHRXLANCNFSM4IOW57CQ .

[mehdideveloper]

Hey. An update: I managed to compile SuWidgets too :) So I had to change 2 other things in the Makefile as well: 1- I changed LINKER from clang++ to g++-9 2- I had to replace all the macx-clangs in Makefile.release to macx-g++

Now it compiles but I have to change the installation path from /usr/include to /usr/local/include so it does not need root. Will update you soon

[mehdideveloper]

So I compiled and installed SuWidgets. Now trying to compile SigDigger and I get

make: *** No rule to make target ColorChooserButton.h', needed by ui_Config.h'. Stop.

[BatchDrake]

That should be fixed more than a month ago, could you pull latest SuWidgets from master, build, install and try again?

Thanks,

El lun., 30 sept. 2019 14:25, Mehdi [email protected] escribió:

So I compiled and installed SuWidgets. Now trying to compile SigDigger and I get

make: *** No rule to make target ColorChooserButton.h', needed by ui_Config.h'. Stop.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/12?email_source=notifications&email_token=AAEVET7HL4YZIQ6HRHRKZF3QMHV25A5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75OTVI#issuecomment-536537557, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEVET47BY7674WDGUHF433QMHV25ANCNFSM4IOW57CQ .

[mehdideveloper]

@BatchDrake Well I've pulled everything today, so I am using the latest. So I fixed that error as well with some dirty hacks. So here are the changes I've made so far to the Makefile for SigDigger:

1- Replaced all the clang and clang++ with gcc-9 and g++-9 (also for LINK) 2- Removed -stdlib=stdc++ 3- Changed all /usr/include/SuWidgets to /usr/local/include/SuWidgets 4- I commented two lines of $(QMAKE) -o Makefile SigDigger.pro because otherwise each time running make would run qmake and overwrite my changes to Makefile 5- I replaced all macx-clang with macx-g++ 6- Then I still had the above error, so instead of investigating the root cause, I just pasted all the header files from /usr/local/include/SuWidgets to SigDigger directory to make sure at least I can compile. 7- It seems MSG_NOSIGNAL is not supported on Mac! so I defined it as 0 in UDP/SocketForwarder.cpp (again a dirty hack just to be able to move forward with compiling)

Now I have at least a working app! I attached an screenshot. So I should try it with SDRs (I would do that tonight and will let you know the results)

Thanks for your help. FYI here's versions I've used (if that helps): gcc: Homebrew GCC 9.2.0 OSX: macOS 10.14.6 Qt: 5.13.1 (homebrew) fftw: 3.3.8

[smdjeff]

Got a PR for these?

On Mon, Sep 30, 2019, 7:53 AM Mehdi [email protected] wrote:

@BatchDrake https://github.com/BatchDrake Well I've pulled everything today, so I am using the latest. So I fixed that error as well with some dirty hacks. So here are the changes I've made so far to the Makefile for SigDigger:

1- Replaced all the clang and clang++ with gcc-9 and g++-9 (also for LINK) 2- Removed -stdlib=stdc++ 3- Changed all /usr/include/SuWidgets to /usr/local/include/SuWidgets 4- I commented two lines of $(QMAKE) -o Makefile SigDigger.pro because otherwise each time running make would run qmake and overwrite my changes to Makefile 5- I replaced all macx-clang with macx-g++ 6- Then I still had the above error, so instead of investigating the root cause, I just pasted all the header files from /usr/local/include/SuWidgets to SigDigger directory to make sure at least I can compile. 7- It seems MSG_NOSIGNAL is not supported on Mac! so I defined it as 0 in UDP/SocketForwarder.cpp (again a dirty hack just to be able to move forward with compiling)

Now I have at least a working app! I attached an screenshot. So I should try it with SDRs (I would do that tonight and will let you know the results)

Thanks for your help. FYI here's versions I've used (if that helps): gcc: Homebrew GCC 9.2.0 OSX: macOS 10.14.6 Qt: 5.13.1 (homebrew) fftw: 3.3.8 [image: Screen Shot 2019-09-30 at 3 48 54 PM] https://user-images.githubusercontent.com/12119776/65885149-66c27700-e39a-11e9-9d08-2a614431d2c8.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/12?email_source=notifications&email_token=AAJXMTZ2IAWHDTSA2EMTAETQMIAGTA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75W4FA#issuecomment-536571412, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJXMTZGHIRJARESZJLEFPLQMIAGTANCNFSM4IOW57CQ .

[BatchDrake]

Holy cow, I didn't expect to see results so soon. Congratulations! 👏

I think this totally justifies installing a MacOS VM and start working on a port based on all the progress you came up with. I will probably write a task list after adapting the build tree, comprising things like audio support and network forwarding. If you want, I could assign you any task you find interesting to implement (you'd be included in the authors tab ofc).

[mehdideveloper]

@smdjeff I will submit a PR, but it needs some pre-requisites: 1- I should test the software to make sure none of my changes actually affect runtime and are OK (like setting the MSG_NOSIGNAL to 0) 2- I have done so many changes in all the 4 repos (sigutils, suscan, suwidgets and sigdigger) So I should find the best way to send a universal patch (not something that works in my machine) I will need some help from @BatchDrake for the above points. Like, any specific runtime test criteria I should have in mind?

So let me test it with some SDRs tonight to see if it works as expected.

@BatchDrake Thanks, yes I would love to work on this further. BTW I get errors for audio preview because of ALSA. Take a look at the attached screenshot (don't worry about the empty waterfall :) It's an AirSpy without any antenna attached, though I'm not sure why the app title says default source)

[smdjeff]

Can you do a fork then so I can work with your diff?

On Mon, Sep 30, 2019, 8:39 AM Mehdi [email protected] wrote:

@smdjeff https://github.com/smdjeff I will submit a PR, but it needs some pre-requisites: 1- I should test the software to make sure none of my changes actually affect runtime and are OK (like setting the MSG_NOSIGNAL to 0) 2- I have done so many changes in all the 4 repos (sigutils, suscan, suwidgets and sigdigger) So I should find the best way to send a universal patch (not something that works in my machine) I will need some help from @BatchDrake https://github.com/BatchDrake for the above points. Like, any specific runtime test criteria I should have in mind?

So let me test it with some SDRs tonight to see if it works as expected.

@BatchDrake https://github.com/BatchDrake Thanks, yes I would love to work on this further. BTW I get errors for audio preview because of ALSA. Take a look at the attached screenshot (don't worry about the empty waterfall :) It's an AirSpy without any antenna attached, though I'm not sure why the app title says default source)

[image: Screen Shot 2019-09-30 at 4 32 48 PM] https://user-images.githubusercontent.com/12119776/65888911-9d02f500-e3a0-11e9-9179-23a73ef9df97.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/12?email_source=notifications&email_token=AAJXMTZLQNAFCR4GUWOCWSTQMIFQ3A5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD754CZA#issuecomment-536592740, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJXMT7V5YT7W4XHQLQGO2LQMIFQ3ANCNFSM4IOW57CQ .

[BatchDrake]

@mehdideveloper sigutils and suscan tests are currently broken, and I'd prefer to address that issue later. For now, I will content myself with a few manual tests opening multiple inspector tabs at a time, and see whether your pthread_barrier implementation works. If everything seems fine (i.e. the capture does not freeze or something), you can send me a pull request so I can review it. Once everything is ready, I will merge your changes to a development branch and we can start shaping a full MacOS X port, even having ports to other OSes in mind.

Regarding your screenshot, if you were able to find a SDR device and capture some samples from it, the worst part is over :) The ALSA error was expected, as for now there is no audio support in MacOS whatsoever. We can start with it after I merge your changes.

Thanks!

[mehdideveloper]

@smdjeff Sure. I cloned fresh repos on another MacBook and observed some differences when compiling; I should investigate those. For example in the first MacBook I didn't change any INCLUDE directories in sigutil's Makefile, but in the second I had to manually add include path for fftw3 and libsndfile to testutils/Makefile to fix compiler errors which is weird. So either my changes are not universal, or I have done changes in the first one which I don't remember.

@BatchDrake I have attached two more screenshots; As you see I can have multiple inspector windows working in parallel without problems. I think there's something wrong with the spectrum though. I've attached a gqrx screenshot and as you see I should see the signals in the panadapter (I haven't played with all SigDigger's settings. This is default. Am I doing anything wrong? FYI there's an antenna attached to AirSpy)

Bests

[mehdideveloper]

@BatchDrake Please ignore my comment on pan-adapter. Enabling Hardware AGC fixed it

[BatchDrake]

@mehdideveloper I see that you set the LNB frequency to 88000000 (the small LCD display on top of LOCAL), but I don't think you are using any upconverter here. That LNB LCD simply specifies a fixed frequency offset that is added to the selected frequency (the bigger LCD) in order to calculate the actual tuner frequency that is passed to SoapySDR. This is useful with hardware like NooElec's Ham It Up, which translates the shortwave band around 125 MHz (and therefore you want to set the LNB frequency to 125000000). In this case, are actually tuning to 88 + 88 = 176 MHz.

Also, you may want to do some manual gain adjustments using the gain controls below (although they are disabled if you enable hardware AGC). For AirSpy (and hopefully more radios in the future), there are gain presets that allow you to set many VGAs at a time, favoring either linearity or sensitivity. It should be right above the Capture recorder in the Source tab.

[mehdideveloper]

@BatchDrake Ok so the first error showed itself and it's related to pthread. The only thing I know that I have changed in this laptop since 2 days ago is updating the macOS to the latest incremental patch (not a big update) released by Apple. Today I tried to run SigDigger to try different SDRs and after showing the startup dialog picture for a very short time (like less than a second), the app crashed. I can email you the whole call stack if that's helpful, but here's the crashed thread:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information: abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff733f42c6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff734afbf1 pthread_kill + 284 2 libsystem_c.dylib 0x00007fff7335e6a6 abort + 127 3 libgcc_s.1.dylib 0x0000000101fde2af uw_init_context_1.cold + 5

I compiled SigDigger again but no difference in results. I will compile everything (all the dependencies) from scratch again and test it.

[BatchDrake]

This is odd, and seems to be happening somewhere inside gcc's runtime. Those calls to pthread_kill are being invoked from abort, so I wouldn't worry about them for now.

Try compiling everything from scratch (especially Suscan) using -O0 -ggdb in the CFLAGS and CXXFLAGS of every Makefile (not sure whether this will work in Mac). If it does, run SigDigger from gdb and after the crash, enter the following in gdb's prompt:

(gdb) thread apply all bt

This should give me a portrait of the overall thread state.

El mié., 2 oct. 2019 19:30, Mehdi [email protected] escribió:

@BatchDrake https://github.com/BatchDrake Ok so the first error showed itself and it's related to pthread. The only thing I know that I have changed in this laptop since 2 days ago is updating the macOS to the latest incremental patch (not a big update) released by Apple. Today I tried to run SigDigger to try different SDRs and after showing the startup dialog picture for a very short time (like less than a second), the app crashed. I can email you the whole call stack if that's helpful, but here's the crashed thread:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information: abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff733f42c6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff734afbf1 pthread_kill + 284 2 libsystem_c.dylib 0x00007fff7335e6a6 abort + 127 3 libgcc_s.1.dylib 0x0000000101fde2af uw_init_context_1.cold + 5

I compiled SigDigger again but no difference in results. I will compile everything (all the dependencies) from scratch again and test it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BatchDrake/SigDigger/issues/12?email_source=notifications&email_token=AAEVETZE37FZ5EPANBD6UH3QMTLCJA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFRUFQ#issuecomment-537598486, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEVET5FJBTDJTDZ36GQE2LQMTLCJANCNFSM4IOW57CQ .

[mehdideveloper]

@BatchDrake I rebuilt everything with those flags. I've pasted the output of debugger at the end of this comment (it's the output of bt all from lldb) I found out some other things about building that I should write down here for future reference:

• There is a problem with fftw3_CFLAGS and some other flags in some Makefiles which although set to a correct path, I get compile-time errors for not finding some header files and I have to manually add the path to CFLAGS to work. It's strange. Examples: 1- sigutils/testutil/Makefile and sigutils/src/Makefile: Although fftw3_CFLAGS is set to " -I/usr/local/Cellar/fftw/3.3.8_1/include" , I get a "No such file or directory" so I have to add it to CFLAGS to make it work ! Same for SNDFILE_CFLAGS 2- suscan/util/Makefile: fftw3_CFLAGS and xml2_CFLAGS 3- suscan/codec/Makefile : fftw3_CFLAGS

• I don't know why I got linker errors for pthread_barrier inline functions in analyzer/analyzer.h. Changing them to static fixed this problem.

• FYI make install in SigDigger tries to make a directory which is forbidden in Mac: mkdir: cannot create directory ‘/opt’: Permission denied

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff733f42c6 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff734afbf1 libsystem_pthread.dylib`pthread_kill + 284
    frame #2: 0x00007fff7335e6a6 libsystem_c.dylib`abort + 127
    frame #3: 0x0000000101d3d2af libgcc_s.1.dylib`uw_init_context_1.cold + 5
    frame #4: 0x0000000101d3af37 libgcc_s.1.dylib`_Unwind_Resume + 55
    frame #5: 0x000000010e289725 libairspySupport.so`SoapyAirspy::SoapyAirspy(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&) + 2229
    frame #6: 0x000000010e286f92 libairspySupport.so`makeAirspy(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&) + 34
    frame #7: 0x00000001008d993f libSoapySDR.0.8.dylib`std::__1::__deferred_assoc_state<SoapySDR::Device*, std::__1::__async_func<SoapySDR::Device* (*)(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&), std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > > >::__execute() + 31
    frame #8: 0x00007fff704f49d4 libc++.1.dylib`std::__1::__assoc_sub_state::wait() + 46
    frame #9: 0x00000001008d4009 libSoapySDR.0.8.dylib`SoapySDR::Device::make(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&) + 1561
    frame #10: 0x00000001008f3678 libSoapySDR.0.8.dylib`SoapySDRDevice_make + 40
    frame #11: 0x00000001003f13ed libsuscan.0.dylib`suscan_source_device_populate_info(dev=0x000000010f872ad0) at source.c:189:3
    frame #12: 0x00000001003f44b2 libsuscan.0.dylib`suscan_source_config_from_object(object=0x000000010bfdac30) at source.c:1316:11
    frame #13: 0x000000010008a0d3 SigDigger`Suscan::Source::Config::Config(this=0x00007ffeefbfc3a0, obj=0x00007ffeefbfc3f0) at Source.cpp:120:3
    frame #14: 0x0000000100007c66 SigDigger`SigDigger::AppConfig::deserialize(this=0x000000010f872530, conf=0x00007ffeefbfc7b0) at AppConfig.cpp:74:5
    frame #15: 0x0000000100041202 SigDigger`SigDigger::PersistentWidget::loadSerializedConfig(this=0x00000001020f3b00, object=0x00007ffeefbfc7b0) at PersistentWidget.cpp:40:28
    frame #16: 0x0000000100009de8 SigDigger`SigDigger::Application::run(this=0x00007ffeefbff600, config=0x00007ffeefbfc7b0) at Application.cpp:51:39
    frame #17: 0x0000000100015b37 SigDigger`SigDigger::Loader::handleDone(this=0x00007ffeefbff5b0) at Loader.cpp:185:17
    frame #18: 0x000000010009f7e6 SigDigger`SigDigger::Loader::qt_static_metacall(_o=0x00007ffeefbff5b0, _c=InvokeMetaMethod, _id=2, _a=0x000000010bf5b980) at moc_Loader.cpp:229:31
    frame #19: 0x0000000101634df2 QtCore`QObject::event(QEvent*) + 770
    frame #20: 0x000000010096d0f2 QtWidgets`QWidget::event(QEvent*) + 4706
    frame #21: 0x0000000100ad3e13 QtWidgets`QSplashScreen::event(QEvent*) + 147
    frame #22: 0x0000000100930aaf QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
    frame #23: 0x0000000100931ecc QtWidgets`QApplication::notify(QObject*, QEvent*) + 588
    frame #24: 0x000000010160af14 QtCore`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
    frame #25: 0x000000010160c161 QtCore`QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 817
    frame #26: 0x00000001024c9769 libqcocoa.dylib`___lldb_unnamed_symbol654$$libqcocoa.dylib + 313
    frame #27: 0x00000001024c896f libqcocoa.dylib`___lldb_unnamed_symbol647$$libqcocoa.dylib + 1967
    frame #28: 0x000000010160b477 QtCore`QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 39
    frame #29: 0x0000000100ad38e4 QtWidgets`QSplashScreen::showMessage(QString const&, int, QColor const&) + 132
    frame #30: 0x0000000100015e16 SigDigger`SigDigger::Loader::showMessage(this=0x00007ffeefbff5b0, message=0x00007ffeefbfcf98) at Loader.cpp:217:29
    frame #31: 0x0000000100015862 SigDigger`SigDigger::Loader::handleChange(this=0x00007ffeefbff5b0, state=0x000000010bf61950) at Loader.cpp:155:20
    frame #32: 0x000000010009f7bc SigDigger`SigDigger::Loader::qt_static_metacall(_o=0x00007ffeefbff5b0, _c=InvokeMetaMethod, _id=0, _a=0x000000010bf78160) at moc_Loader.cpp:227:33
    frame #33: 0x0000000101634df2 QtCore`QObject::event(QEvent*) + 770
    frame #34: 0x000000010096d0f2 QtWidgets`QWidget::event(QEvent*) + 4706
    frame #35: 0x0000000100ad3e13 QtWidgets`QSplashScreen::event(QEvent*) + 147
    frame #36: 0x0000000100930aaf QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
    frame #37: 0x0000000100931ecc QtWidgets`QApplication::notify(QObject*, QEvent*) + 588
    frame #38: 0x000000010160af14 QtCore`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
    frame #39: 0x000000010160c161 QtCore`QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 817
    frame #40: 0x00000001024c9769 libqcocoa.dylib`___lldb_unnamed_symbol654$$libqcocoa.dylib + 313
    frame #41: 0x00000001024c896f libqcocoa.dylib`___lldb_unnamed_symbol647$$libqcocoa.dylib + 1967
    frame #42: 0x000000010160b477 QtCore`QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 39
    frame #43: 0x0000000100ad38e4 QtWidgets`QSplashScreen::showMessage(QString const&, int, QColor const&) + 132
    frame #44: 0x0000000100015e16 SigDigger`SigDigger::Loader::showMessage(this=0x00007ffeefbff5b0, message=0x00007ffeefbfd738) at Loader.cpp:217:29
    frame #45: 0x0000000100015862 SigDigger`SigDigger::Loader::handleChange(this=0x00007ffeefbff5b0, state=0x00000001020ba2f0) at Loader.cpp:155:20
    frame #46: 0x000000010009f7bc SigDigger`SigDigger::Loader::qt_static_metacall(_o=0x00007ffeefbff5b0, _c=InvokeMetaMethod, _id=0, _a=0x0000000102057cd0) at moc_Loader.cpp:227:33
    frame #47: 0x0000000101634df2 QtCore`QObject::event(QEvent*) + 770
    frame #48: 0x000000010096d0f2 QtWidgets`QWidget::event(QEvent*) + 4706
    frame #49: 0x0000000100ad3e13 QtWidgets`QSplashScreen::event(QEvent*) + 147
    frame #50: 0x0000000100930aaf QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 271
    frame #51: 0x0000000100931ecc QtWidgets`QApplication::notify(QObject*, QEvent*) + 588
    frame #52: 0x000000010160af14 QtCore`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
    frame #53: 0x000000010160c161 QtCore`QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 817
    frame #54: 0x00000001024c9769 libqcocoa.dylib`___lldb_unnamed_symbol654$$libqcocoa.dylib + 313
    frame #55: 0x00000001024c9ee8 libqcocoa.dylib`___lldb_unnamed_symbol666$$libqcocoa.dylib + 40
    frame #56: 0x00007fff4735ade3 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    frame #57: 0x00007fff4735ad89 CoreFoundation`__CFRunLoopDoSource0 + 108
    frame #58: 0x00007fff4733e74b CoreFoundation`__CFRunLoopDoSources0 + 195
    frame #59: 0x00007fff4733dd15 CoreFoundation`__CFRunLoopRun + 1189
    frame #60: 0x00007fff4733d61e CoreFoundation`CFRunLoopRunSpecific + 455
    frame #61: 0x00007fff4659c1ab HIToolbox`RunCurrentEventLoopInMode + 292
    frame #62: 0x00007fff4659bee5 HIToolbox`ReceiveNextEventCommon + 603
    frame #63: 0x00007fff4659bc76 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #64: 0x00007fff4493477d AppKit`_DPSNextEvent + 1135
    frame #65: 0x00007fff4493346b AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
    frame #66: 0x00007fff4492d588 AppKit`-[NSApplication run] + 699
    frame #67: 0x00000001024c8c85 libqcocoa.dylib`___lldb_unnamed_symbol647$$libqcocoa.dylib + 2757
    frame #68: 0x000000010160636f QtCore`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 431
    frame #69: 0x000000010160b582 QtCore`QCoreApplication::exec() + 130
    frame #70: 0x00000001000932a9 SigDigger`main(argc=1, argv=0x00007ffeefbff760) at main.cpp:39:17
    frame #71: 0x00007fff732b93d5 libdyld.dylib`start + 1
  thread #5
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff734ac636 libsystem_pthread.dylib`_pthread_wqthread + 458
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #8
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff734ac6e6 libsystem_pthread.dylib`_pthread_wqthread + 634
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #10
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x6874656d00000000
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #11
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x4a53b7d000005000
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #12
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff734ac6e6 libsystem_pthread.dylib`_pthread_wqthread + 634
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #13
    frame #0: 0x00007fff733efbfe libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff734ac636 libsystem_pthread.dylib`_pthread_wqthread + 458
    frame #2: 0x00007fff734ac3fd libsystem_pthread.dylib`start_wqthread + 13
  thread #14
    frame #0: 0x0000000000000000
  thread #15, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff733ee22a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff733ee76c libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff4733e94e CoreFoundation`__CFRunLoopServiceMachPort + 328
    frame #3: 0x00007fff4733debc CoreFoundation`__CFRunLoopRun + 1612
    frame #4: 0x00007fff4733d61e CoreFoundation`CFRunLoopRunSpecific + 455
    frame #5: 0x00007fff4493c4a2 AppKit`_NSEventThread + 175
    frame #6: 0x00007fff734ad2eb libsystem_pthread.dylib`_pthread_body + 126
    frame #7: 0x00007fff734b0249 libsystem_pthread.dylib`_pthread_start + 66
    frame #8: 0x00007fff734ac40d libsystem_pthread.dylib`thread_start + 13```

[BatchDrake]

Alright, I think I've isolated the issue. This is breaking somewhere inside SoapySDR during the creation of an AirSpy device object. It may be related to an issue in the device config serialization.

Could you send me a copy of all files under $HOME/.suscan, then rename this folder to something else and try again?

Thanks,

[mehdideveloper]

@BatchDrake I renamed the folder and it worked again!! Please find attached my ~./suscan. By the way I found a weird issue you may find interesting: I tried to rebuild everything on another Macbook and then I faced linker errors. It's interesting because this Macbook is identical to the other (same OS version, same gcc version, same fftw3 version etc) The only difference is that I have GNURadio and Volk on the new Macbook, and I even removed all -lvolk instances from Makefiles to replicate the first system's config as much as possible. Here's part of the output when building sigutils:

ld: warning: ignoring file ../testutil/.libs/libtestutil.a, file was built for archive which is not the architecture being linked (x86_64): ../testutil/.libs/libtestutil.a
ld: warning: ignoring file ../sigutils/.libs/libsigutils.a, file was built for archive which is not the architecture being linked (x86_64): ../sigutils/.libs/libsigutils.a
Undefined symbols for architecture x86_64:
  "_su_agc_feed", referenced from:
      _su_test_agc_transient in sutest-agc.o
      _su_test_agc_steady_rising in sutest-agc.o
      _su_test_agc_steady_falling in sutest-agc.o
  "_su_agc_finalize", referenced from:
      _su_test_agc_transient in sutest-agc.o
      _su_test_agc_steady_rising in sutest-agc.o
      _su_test_agc_steady_falling in sutest-agc.o
....
....
....
....
"_su_test_ctx_resize_buf", referenced from:
      _su_test_cdr_block in sutest-block.o
  "_su_test_run", referenced from:
      _main in sutest-main.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [sutest] Error 1
make: *** [all-recursive] Error 1

Thanks

suscan_config.zip

[mehdideveloper]

I tried anything that I could think of, but I can't figure out why the same exact linker command results in different behaviours on these 2 systems.

[BatchDrake]

I tried anything that I could think of, but I can't figure out why the same exact linker command results in different behaviours on these 2 systems.

Perhaps it is not the linker what is wrong, but the files generated before the linker gets called (like ../testutil/.libs/libtestutil.a). I would start by comparing these libraries in both systems and see what is so different between them ("archive" should not be an architecture, to begin with).

I'm installing a MacOS VM now and I will follow your steps so far, I'll keep you updated.

[mehdideveloper]

You're right. There's a difference between libtestutil.a in 2 systems. Here's the output of otool -L on them:

First system (working):

Archive : testutil/.libs/libtestutil.a testutil/.libs/libtestutil.a(libtestutil_la-common.o): testutil/.libs/libtestutil.a(libtestutil_la-poolhelper.o): testutil/.libs/libtestutil.a(libtestutil_la-sigbufpool.o):

Second system (linker error):

Archive : testutil/.libs/libtestutil.a testutil/.libs/libtestutil.a( 0): testutil/.libs/libtestutil.a(libtestutil_la-poolhelper.o): testutil/.libs/libtestutil.a(libtestutil_la-sigbufpool.o):