SDRplay Community Forum

As I had some problems making gr-osmosdr I have installed SDR-J instead. Installing the Linux API was ok, libmirsdrapi-rsp.so does exist in /usr/local/lib/. However, SDR-J can not find it. Does anyone here have an idea what could be wrong?

Peter

Hi Peter,

Try linking the .so to /usr/local/lib/libmirsdrapi-rsp-x86_64-1.1.so as that's what the manual refers to. The source code available is for Windows so doesn't tell us very much. Let me know if you are still struggling and I'll ask Jan directly to confirm.

Best regards,

SDRplay Support

I've had good luck with SDR-J. It has been a while since I installed, it, but I recall I had to manually link the library as sdrplay suggested.

You might also need to do an "sudo ldconfig -a" on the directory where you have the Miric's libraries installed if anything is changed after the installation program was run.

...Doug AH6DL

Hi Peter,

The above method will solve you problem but it is not advised to make a link as it could lead to problems during upgrade.

The simplest way is to type (in bash shell)

export LD_LIBRARY_PATH=/usr/local/lib

assuming /usr/local/lib contains your library.

To make it permanent you can edit ~/.bash_profile and add the following lines

LD_LIBRARY_PATH=/usr/local/lib
export $LD_LIBRARY_PATH

73
Amish

Peter,

I believe what I did to solve the problem of missing libraries was to create /etc/ld.so.conf.d/local.conf and put in the local directories that weren't being looked at by ldconfig. This is with Fedora, your directory structure may differ.

My /etc/ld.so.conf.d/local.conf. Notice the last line, that's because ldconfig does not search recursively; not what I expected.

Amish, I think setting LD_Path_Library in .bashrc or similar conf file is also not advised because it could mess with the libraries other apps or utilities are expecting to find. I read the recommendation is to start with a wrapper file that sets the environment for just that application.

73, digger

Hi Digger,

We are perhaps missing the basic design of these different directory structure. The file is deliberately put in /usr/local/lib so that ldconfig does not find it. The developer of the library decides where to put it.

Also setting the environment variable will not effect the existing library path. This is the only option when you do not have superuser permisssion.

We may be using Linux as a single user setup, but remember Linux is designed to support multiusers and we do not want to change the environment of the other users.

Hey Amish,

Sorry, but looking at http://tldp.org/HOWTO/Program-Library-H ... aries.html and http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE23 that's not how I interpret the use of /usr/local/l and ld.conf.

In part /usr/local/ is meant to isolate files from the distributions files to make them "safe from being overwritten when the system software is updated."
It's not to isolate them from the systems users. One of *nix strong points is it's built as a multi-user system to start with and that's exactly why I would make locally installed packages available to all users.

Also I'm basing what I said about LD_LIBRARY_PATH on a search of the internet. One of the often sited articles https://blogs.oracle.com/ali/entry/avoi ... y_path_the doesn't even recommend using a wrapper.

But in the end most of us at home are using *nix as a single user system and sometimes the only way we seem to get things to work is with baling wire and chewing gum.

73,
digger

Thanks a lot for your replies.

Peter