-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Would love to see a Mac OS build of this! #12
Comments
I tried to compile it some time ago and hit a dead-end. Replace clang with gcc-8, clang++ with g++-8 (GCC 8.3, Qt 5.13) 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. |
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! |
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. |
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. |
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! |
It's weird that I didn't get any notifications for your replies, although I've enabled them for this repo and thread. 1- Sigutils compiled without any issues. 2- Suscan:
These changes fixed all the compile time errors, but then I ran into link time errors ! Any ideas? |
Hi! I've just added some changes that may ease the build now. Regarding your changes:
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
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! |
Hi
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:
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. |
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 |
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 <notifications@github.com> 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
<#12?email_source=notifications&email_token=AAEVET3H3QITWAU5KJFVHLTQMHRXLA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75L6IQ#issuecomment-536526626>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVET2JA5M2LCK5ACNQAODQMHRXLANCNFSM4IOW57CQ>
.
|
Hey. An update: I managed to compile SuWidgets too :) Now it compiles but I have to change the installation path from |
So I compiled and installed SuWidgets. Now trying to compile SigDigger and I get
|
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 <notifications@github.com> 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
<#12?email_source=notifications&email_token=AAEVET7HL4YZIQ6HRHRKZF3QMHV25A5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75OTVI#issuecomment-536537557>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVET47BY7674WDGUHF433QMHV25ANCNFSM4IOW57CQ>
.
|
@BatchDrake Well I've pulled everything today, so I am using the latest. 1- Replaced all the clang and clang++ with gcc-9 and g++-9 (also for LINK) Now I have at least a working app! I attached an screenshot. Thanks for your help. |
Got a PR for these?
…On Mon, Sep 30, 2019, 7:53 AM Mehdi ***@***.***> 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
<#12?email_source=notifications&email_token=AAJXMTZ2IAWHDTSA2EMTAETQMIAGTA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75W4FA#issuecomment-536571412>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJXMTZGHIRJARESZJLEFPLQMIAGTANCNFSM4IOW57CQ>
.
|
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). |
@smdjeff 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. |
Can you do a fork then so I can work with your diff?
…On Mon, Sep 30, 2019, 8:39 AM Mehdi ***@***.***> 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
<#12?email_source=notifications&email_token=AAJXMTZLQNAFCR4GUWOCWSTQMIFQ3A5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD754CZA#issuecomment-536592740>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJXMT7V5YT7W4XHQLQGO2LQMIFQ3ANCNFSM4IOW57CQ>
.
|
@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! |
@smdjeff Sure. @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 |
@BatchDrake Please ignore my comment on pan-adapter. Enabling Hardware AGC fixed it |
@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. |
@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.
I compiled SigDigger again but no difference in results. I will compile everything (all the dependencies) from scratch again and test it. |
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 <notifications@github.com> 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
<#12?email_source=notifications&email_token=AAEVETZE37FZ5EPANBD6UH3QMTLCJA5CNFSM4IOW57C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFRUFQ#issuecomment-537598486>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEVET5FJBTDJTDZ36GQE2LQMTLCJANCNFSM4IOW57CQ>
.
|
@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
|
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 Thanks, |
@BatchDrake I renamed the folder and it worked again!!
Thanks |
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 I'm installing a MacOS VM now and I will follow your steps so far, I'll keep you updated. |
You're right. There's a difference between First system (working):
Second system (linker error):
|
I just wanted to let you know that I installed MacOS X and cloned all repos last weekend, and now I'm ready to start debugging these issues. Can't give you a proper schedule yet, but I'll probably look into this before the end of this week :) |
That's good news. Looking forward to it. Let me know if you needed more testing on my side |
Quick update: I've updated to MacOS Catalina and compiled sigutils and suscan (branch feature/mac-support) from scratch. Compiler was clang 11.0.0. I had to install pkgconfig, autoconf, automake, SoapySDR, libsndfile and fftw via brew. Only big change: the pc file for libxml-2.0 was wrong (it pointed to a nonexistent include dir) and had to change it by hand, system-wide. Apart from that, I was able to compile sigutils and suscan seamlessly. The big obstacle now is that somehow Xcode's C++ complex API is broken? I'm trying to build SuWidgets and I'm getting a bunch of errors from undeclared functions (cabsf, cargf, cimagf...) that are in fact declared in complex.h (and the include guard is not the problem). I also tried to compile this program:
using clang++ and again, undeclared identifiers. I'm still investigating this. |
Well that's why I used the gcc-9 from brew |
Problem is, although I can rely on gcc-9 for compiling as some sort of workaround, it is somewhat messy. I'll try to find a solution for this before giving up. |
I have bad news and good news. The bad news is that, according to this thread https://stackoverflow.com/questions/10540228/c-complex-numbers-in-c, exposing C's The good news is that |
After thoroughly thinking about this, I concluded that it is better off if we just fix it in sigutils (which is where the common complex API is defined) and add sigutils as a dependency to SuWidgets. Simpler, cleaner, and easier to maintain. The reference issue is BatchDrake/sigutils#8 Since I will be rather busy these days advancing in other projects, I don't think I can deal with this soon. It is not extremely difficult though, so if you want to get involved I can assign the issue to you and give you the necessary details to get started. |
Hey. Yes please assign it to me. We can continue to discuss the details there |
I've already added you as a collaborator in sigutils. Accept the request and I'll give you some guidelines. Thank you! :D |
No description provided.
The text was updated successfully, but these errors were encountered: