Hi Ingo, that's almost certainly a question for the SDR# developers, not the osmocom mailing list: they very likely compiled that lib themselves. Also, that's just naming. You can name library files however you like. Also, even if it had the same name, it wouldn't guarantee any compatibility: When linking against a shared library (a DLL in windows parlance), you need a compatible ABI, and you only achieve that by using * the same version of source code * a compatible compiler * the same compilation/linking settings So, I'm almost certain that no matter what you're trying to achieve, you're auf dem Holzweg with this one. Best regards, Marcus On Tue, 2019-08-13 at 22:22 +0200, Ingo.Wolf@gmx.de wrote:
In the actual rtl-sdr windows builds there is an librtlsdr.dll, while sdr# seems to need an rtlsdr.dll like in the quoted link.
When was rtlsdr.dll changed to librtlsdr.dll ?
-----Ursprüngliche Nachricht----- Von: "Harald Welte" <laforge@gnumonks.org> Gesendet: Dienstag, 13. August 2019 22:15 An: Ingo.Wolf@gmx.de Cc: osmocom-sdr@lists.osmocom.org Betreff: Re: sdr# version rtlsdr Hi Ingo,
On Tue, Aug 13, 2019 at 03:48:34PM +0200, Ingo.Wolf@gmx.de wrote:
http://osmocom.org/attachments/download/2242/RelWithDebInfo.zip
is this the last version with rtlsdr.dll?
no, the latest windows binary builds are the weekly automatic builds available from http://ftp.osmocom.org/binaries/windows/rtl-sdr/
sdr# package doesn't contain rtlsdr.dll, but some script to download it from: http://osmocom.org/attachments/download/2242/RelWithDebInfo.zip from your site, may be some licensing issue, not for getting some current one. Am 14.08.2019 um 07:51 schrieb Müller, Marcus (CEL):
Hi Ingo,
that's almost certainly a question for the SDR# developers, not the osmocom mailing list: they very likely compiled that lib themselves.
Also, that's just naming. You can name library files however you like.
Also, even if it had the same name, it wouldn't guarantee any compatibility: When linking against a shared library (a DLL in windows parlance), you need a compatible ABI, and you only achieve that by using
* the same version of source code * a compatible compiler * the same compilation/linking settings
So, I'm almost certain that no matter what you're trying to achieve, you're auf dem Holzweg with this one.
Best regards, Marcus
On Tue, 2019-08-13 at 22:22 +0200, Ingo.Wolf@gmx.de wrote:
In the actual rtl-sdr windows builds there is an librtlsdr.dll, while sdr# seems to need an rtlsdr.dll like in the quoted link.
When was rtlsdr.dll changed to librtlsdr.dll ?
-----Ursprüngliche Nachricht----- Von: "Harald Welte" <laforge@gnumonks.org> Gesendet: Dienstag, 13. August 2019 22:15 An: Ingo.Wolf@gmx.de Cc: osmocom-sdr@lists.osmocom.org Betreff: Re: sdr# version rtlsdr Hi Ingo,
On Tue, Aug 13, 2019 at 03:48:34PM +0200, Ingo.Wolf@gmx.de wrote:
http://osmocom.org/attachments/download/2242/RelWithDebInfo.zip
is this the last version with rtlsdr.dll? no, the latest windows binary builds are the weekly automatic builds available from http://ftp.osmocom.org/binaries/windows/rtl-sdr/
Hi Ingo, On Wed, Aug 14, 2019 at 08:28:19PM +0200, Ingo Wolf wrote:
sdr# package doesn't contain rtlsdr.dll,
but some script to download it from:
http://osmocom.org/attachments/download/2242/RelWithDebInfo.zip
from your site, may be some licensing issue, not for getting some current one.
Then SDR# is insisting to use a snapshot from 2014 rather than something that's remotely current. As indicated, there are automatic current builds made available. I suggest you suggest to the SDR# developers to port their software / scripts / whatever to use recent versions rather than 5 year old ones. There's little we can do about it. We just develop and publish the library, primarily in source code form, but also as binary packages for a variety of systems. Which versions people decide to use is entirely up to them. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (4)
-
Harald Welte -
Ingo Wolf -
Ingo.Wolf＠gmx.de
-
Müller, Marcus (CEL)