build error: libsdrplay not found

Question

build error: libsdrplay not found

fyngyrz opened this issue 5 years ago · 33 comments

build error: libsdrplay not found.

As provided, this will not build.

Answer 1 · 2020-05-08T07:35:48.000Z

It looks like this Soapy package is only going to work with v2 of the SDRPlay SPI, which means those of us with brand new RSPdx units will miss out for a while...

Looking at https://github.com/pothosware/SoapySDRPlay/blob/master/FindLibSDRplay.cmake, it's looking for mir_sdr_api.h, etc... whereas the new api is present as /usr/local/include/sdrplay_api.h

Answer 2 · 2020-05-08T07:37:56.000Z

See here for the v3 version: https://github.com/SDRplay/SoapySDRPlay

It's still in development but you can raise issues there is you find any.

SDRplay

Answer 3 · 2020-05-08T07:44:42.000Z

I'm not sure closing the issue is the best idea - it's going to make it hard for anyone with the same issue to find this link.

Perhaps keep the issue open until the v3 changes have been merged into this repo, but change the issue title to "RSPdx / v3 API support" ?

Answer 4 · 2020-05-08T07:53:44.000Z

I've updated the Readme to explain about the V3 version

Answer 5 · 2020-11-30T18:35:01.000Z

See here for the v3 version: https://github.com/SDRplay/SoapySDRPlay

It's still in development but you can raise issues there is you find any.

SDRplay

@SDRplay Hi. I am not sure understand this. Is that "development" repo supposed to be the new "SoapySDRPlay" in "pothosware"? Why is the git history not based on a common commit? (there are fewer commits in https://github.com/SDRplay/SoapySDRPlay on master than on the repo in pothosware. Whats the idea behind this?

Answer 6 · 2020-11-30T18:37:27.000Z

https://github.com/pothosware/SoapySDRPlay is based on API 2.13

https://github.com/SDRplay/SoapySDRPlay is based on API 3.07

so there isn't a lot of code in common.

Answer 7 · 2020-11-30T18:43:02.000Z

@SDRplay API version of what exactly?

Answer 8 · 2020-11-30T18:49:09.000Z

The RSP hardware API

Answer 9 · 2020-12-01T00:20:22.000Z

https://github.com/pothosware/SoapySDRPlay is based on API 2.13

https://github.com/SDRplay/SoapySDRPlay is based on API 3.07

In an effort to not confuse people, should support for the "API 2.13" be dropped and links updated? Is SDRplay/SoapySDRPlay the new official home? Or could we merge both trees into the same repo that builds one or the other, (or even both) based on the API installed?

Answer 10 · 2020-12-05T15:58:58.000Z

@SDRplay what repo should I build if I am packaging this into a windows installer? Should I move to the 3.07 API?

Answer 11 · 2020-12-05T16:22:10.000Z

API 2.13 is no longer being developed and it doesn't support the RSPdx or the RSPduo in master/slave or dual tuner mode.

So going forward I would recommend all installs to be based on API 3.07

Best regards,

Andy

Answer 12 · 2020-12-05T16:34:46.000Z

@SDRplay any suggestion about how to transition away from this repo?

I could delete pothosware/SoapySDRPlay or rename it to SDRPlayOLD or SDRPlay2.0
Combine the repo into SDRplay/SoapySDRPlay so 2.0 API build would exist as a deprecated subdirectory in the new one, just in case someone wanted to build it
Or move SDRplay/SoapySDRPlay here and replace the contents of pothosware/SoapySDRPlay

At the end of the day I dont care where the repo lives but I need to make some consistency for users, build systems, various urls on the website. No sense in linking to a defuct project. Thoughts?

Answer 13 · 2020-12-05T16:50:42.000Z

I think ultimately it makes sense for SoapySDRPlay to reside in pothosware. Setting up the API 3.07 version in a different repo seemed to make sense to avoid any issues with the pothosware flow.

I don't really have any preference as long as it is clear to people with what is where. @fventuri has done the lion share of the work, so I think he should comment on how to move this forward.

Answer 14 · 2020-12-05T17:54:15.000Z

I like the idea of having have two separate repos (one more or less identical to the current one under SDRplay and the other one with the legacy 2.X from pothosware renamed as @guruofquality suggested); this way we can keep the code bases (and issues reported by the users) separate as much we can.

Once this is in place, how would I fix bugs or make improvements to that driver? By forking under my own account ('fventuri') and submitting a pull request? (I am perfectly OK with this approach; just trying to figure out how things will work in the future).

Franco

Answer 15 · 2020-12-05T18:11:12.000Z

Heres what I can do:

I will rename this repo to SoapySDRPlay2x
move SDRplay/SoapySDRPlay to me @guruofquality (and then I can move it here)
I will invite you to the dev group, you get repo access @fventuri

Answer 16 · 2020-12-05T19:43:10.000Z

@fventuri invite sent

If everyone is happy with the plan, @SDRplay if you kickoff the repo move of SDRplay/SoapySDRPlay, I will kickoff the rename at the same time so its all at once

Answer 17 · 2020-12-05T20:33:15.000Z

Thanks @guruofquality - I just accepted the invite, and I am OK with the plan.
It might be late for @SDRplay now, since he is in the UK.

Franco

Answer 18 · 2020-12-08T15:03:54.000Z

@SDRplay bump

:-D

Answer 19 · 2020-12-08T15:11:10.000Z

Sorry @guruofquality, we've just been discussing it internally. Everything is all good. Just let me know what you need me to do.

Best regards,

Andy

Answer 20 · 2020-12-08T21:31:46.000Z

@guruofquality @SDRplay I won't interfere, but just as an outsider, this is my comment.

I think you can just have both of the source trees in this very same repo and just have two branches.Technically they don't even need to have the same ancestor to be two different branches. But then decide on a "stable" branch name. api_ver_2x for example and just keep the api ver 3 development in master og make a breach for that as well and just do fast forward from master when tagging a release. All I am looking for is, what I should pull for whatever version of libsdrplay I have installed.

Answer 21 · 2020-12-08T23:25:56.000Z

Very good points @nickoe

I usually tend to think of branches as improvements or fixes to a well defined code base - in this case though I don't view version 3.X of the SDRplay API as an incremental improvement over version 2.Y (or viceversa), because they have a somewhat different way of selecting the RSPs (which is very noticeable in the case of the RSPduo model), sample rate, bandwidths, etc.

Another factor that in my opinion weights in favor of different repositories is having two completely different 'issues' queues, both for me as a developer (because I know in advance that the 'issues' on the SoapySDRPlay repo refer to API version 3.X), but also for a customer with a problem, because, when looking for a solution to a problem, they would not get a list of issues that possibly intermingles problems with version 2 of the SDRplay API and problems with version 3 of the SDRplay API.

Also it would possibly help with handling and reviewing any pull request, because we would know right away if it refers to version 2.X of SoapySDRPlay (which some people here might be more familiar with), as opposed to version 3.Y of SoapySDRPlay (which a different group of people might be more familiar with).

This all said, these are not strong opinions on my side, and I am definitely open to discuss them to find the best approach that suits everyone.

Franco

Answer 22 · 2020-12-09T08:06:44.000Z

@fventuri Thank you for your openness. My opinions are not strong either.

Just a note about github. If the current pothosware/SoapySDRPlay repo at is renamed to pothosware/SoapySDRPlay2 in github, the current (soon old) will redirect to that. And then the SDRplay/SoapySDRPlay can be moved to pothosware/SoapySDRPlay3 and it is way more visible for packagers and users alike.

Answer 23 · 2020-12-09T14:15:10.000Z

Sounds good to me. When I get the transfer request in my inbox I will do both of those moves/renames and update the wiki URLs

Answer 24 · 2020-12-09T14:17:32.000Z

Just want to make sure I understand - there will still be https://github.com/pothosware/SoapySDRPlay though right? This runs through every bit of documentation and videos that we've ever done. It still needs to exist - even if it just points to somewhere else.

Answer 25 · 2020-12-09T14:40:46.000Z

Thats a good point, the rename would make githubs URL redirects of pothosware/SoapySDRPlay redirect to pothosware/SoapySDRPlay2. And I think at the end of the day we want pothosware/SoapySDRPlay to exist and to be the recent maintained repo that people look for (the v3 repo).

That said, I will be happy to cooperate with whatever the names should be and follow the instructions :-)

Answer 26 · 2020-12-10T12:55:56.000Z

So, if I understand correctly, the plan would consist of two phases:

in the first phase we would have two actual GitHub repos called 'pothosware/SoapySDRPlay2' and 'pothosware/SoapySDRPlay3'. In this phase 'pothosware/SoapySDRPlay' would just redirect to 'pothosware/SoapySDRPlay2' (the legacy one); would 'SDRplay/SoapySDRPlay' be completely gone, or be a redirect to 'pothosware/SoapySDRPlay'? (TBH I am not sure how these redirect works in GitHub)
in the second phase, sometime in the future, when @SDRplay tells us they are ready, @guruofquality would switch 'pothosware/SoapySDRPlay' to redirect to 'pothosware/SoapySDRPlay3' instead (and of course at that point, all the instructions, documentation, and videos would have to be updated to tell the customers to download and use version 3.X of the SDRplay API for Linux/Mac)

Does that sound about right?

Franco

Answer 27 · 2020-12-10T14:15:12.000Z

We don't want to make the API 3 version harder to find - it needs to be the one pointed to, so pothosware/SoapySDRPlay should go to pothosware/SoapySDRPlay3 - all agreed?

Answer 28 · 2020-12-10T22:53:56.000Z

Works for me @SDRplay , so unless there are objections this would be the plan:

'pothosware/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay2'
'SDRplay/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay3'
'pothosware/SoapySDRPlay' will be a redirect to 'pothosware/SoapySDRPlay3'

If we are all in agreement, I'd say let's go ahead and do it.

Franco

Answer 29 · 2020-12-10T23:09:44.000Z

'pothosware/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay2'

'SDRplay/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay3'

'pothosware/SoapySDRPlay' will be a redirect to 'pothosware/SoapySDRPlay3'

Just a small detail: I think you can only make github redirect if you move in the webinterface, so I you you need these operations; in this order.

'pothosware/SoapySDRPlay' move to 'pothosware/SoapySDRPlay2'
'SDRplay/SoapySDRPlay' move to 'pothosware/SoapySDRPlay'
'pothosware/SoapySDRPlay' move to 'pothosware/SoapySDRPlay3' to make it redirect to 3.

Answer 30 · 2020-12-16T02:45:14.000Z

@nickoe thanks, thats what I was going to do, I dont think you can actually setup the redirects manually, you have to move projects to get the effect.

@SDRplay im ready when you are. We will end up with pothosware/SoapySDRPlay2 and pothosware/SoapySDRPlay3, where pothosware/SoapySDRPlay redirects to pothosware/SoapySDRPlay3 (following @nickoe instructions).

Answer 31 · 2020-12-27T18:47:28.000Z

@guruofquality @SDRplay Any update to this such that we can make the life easier for packagers?

Answer 32 · 2020-12-28T15:42:35.000Z

The move and rename is complete, do let me know of any permissions or url issues. Thanks!

Answer 33 · 2021-01-02T15:58:23.000Z

@guruofquality Thank you very much. I think it makes it easier to navigate.