Problem with missing environment variable for scanner.pl started by slimserver.pl

[flipflip]

Hello

I hope that I am in the right forum..

I am the author of SSODS which allows to run Slimserver on a Synology Diskstation (a NAS). DS hereafter.

Since the DS ships with a very minimal Linux system, I have to install (compile) Perl myself to make Slimserver run.

I installed perl and all necessary libraries in an unusual location which is /volume1/SSODS. The libraries are in /volume1/SSODS/lib.

Slimserver is started through a shell script which sets necessary environment variables for perl. Something like this:

export PATH=/volume1/SSODS/bin
export LD_LIBRARY_PATH=/volume1/SSODS/lib

perl /volume1/SlimServer/slimserver.pl (and --cachedir ... etc.)


That works great, slimserver.pl is started and it finds the custom mysql in the path (/volume1/SSODS/bin/mysqld).

Now, when slimserver starts the scanner.pl program it starts a new perl process for it. But for that process the LD_LIBRARY_PATH variable is no longer available and so XML::Parser::Expat cannot find the /volume1/SSODS/lib/libexpat.so library. scanner.pl complains and quits.

I understand, that this separate perl process is started using Proc::Background::new(...). In that function the variable is available. The following command i inserted there prints out the variable as expected.

printf "LD_LIBRARY_PATH=".$ENV{"LD_LIBRARY_PATH"}."\n "

Output: LD_LIBRARY_PATH=/volume1/SSODS/lib

Now I made a fake scanner.pl which contains the above line. Now in this process the variable is gone. The screen says:

Output: LD_LIBRARY_PATH=

Then I tried to set the variable in the original scanner.pl in the BEGIN block as follows:

$ENV{'LD_LIBRARY_PATH'} = '/volume1/SSODS/lib';

Well, the variable is there after that (checked with a printf) but perl still cannot load XML::Parser::Expat.

I reckon, that the variable has to be available before the perl process starts.

Hence the following work-around works:

I renamed the scanner.pl to scanner2.pl and replaced scanner.pl with the following code:

-------------------------------------------
@args = ("/usr/bin/env", "LD_LIBRARY_PATH=/volume1/SSODS/lib", "/volume1/SSODS/bin/perl", "/volume1/SlimServer/scanner2.pl", @ARGV);

system(@args);
-------------------------------------------

Now it works! :-)

If i put the following code in the modified scanner.pl i see some env variables (PATH, HTTP_REQUEST and other HTTP_something). I wonder where these come from.

foreach $var (sort keys %ENV ) {
print "$var=\"$ENV{$var}\"\n";
}

Now to the questions:

Where do I have to pass the LD_LIBRARY_PATH variable to the second perl process for the scanner?

Somewhere in Proc::Background?

Somewhere in Slimserver?

I was looking around, starting at Slim::Music::Import::launchScan() but did not find anything.

Should I modify launchScan() so that it starts the process via env like in my fake scanner.pl?


Regards,
flip

[Dan Sully]

Is there an /etc/ld.so.conf on the Synology?

If so, modify that to add the paths where the .so files are.

-D
--
"Hey, careful, man, there's a beverage here!"

[flipflip]

Is there an /etc/ld.so.conf on the Synology?

No, there isn't. I'll try what happens when I create one (after dinner.. :-).

Thanks,

flip

[Dan Sully]

* flipflip shaped the electrons to say...

>
>Dan Sully;138511 Wrote:
>> Is there an /etc/ld.so.conf on the Synology?
>
>No, there isn't. I'll try what happens when I create one (after
>dinner.. :-).

Ok.. you may need to run 'ldconfig -v' after that.

-D
--
Do not panic, do not panic! We are trained professionals!
Now, stay calm. We are going around the leaf.

[flipflip]

Okay, that worked perfectly.

Many thanks, Dan!

Actually I know about /etc/ld.so.conf and ldconfig. I investigated in the wrong direction..

At least I learned a bit about slimserver.. and Perl. Usually I code in c and matlab. It's definitively time to start using perl.. :-)

Regards,

flip

[mr_hyde]

Hello flip,

i observed the same problem after a new intstallation of SS 6.5.0 on the DS106. I only symlinked the libexpat.so.1 into the /lib and the problem was gone. I don't know what is the better solution, but it seems to be easier.

mr_hyde

[flipflip]

Yes, since /lib is in the default search path that works as well.

The new SSODS will modify /etc/ld.so.conf.

[flipflip]

I have a new solution for this which I find very elegant:

You either compile (link) the programs using:

-Wl,-rpath,/mystuff/lib

(and aditionally also -Wl,-dynamic-linker,/mystuff/lib/ld-linux.so.2 if you have your own libc)

Or you modify the rpath (and interpreter if necessary) in the binary, using a hex editor (haxxorz), sed or something (elite haxxorz) or patchelf from http://nix.cs.uu.nl/patchelf.html (me).

flip

[flipflip]

I have a new solution for this which I find very elegant:

You either compile (link) the programs using:

-Wl,-rpath,/mystuff/lib

(and aditionally also -Wl,-dynamic-linker,/mystuff/lib/ld-linux.so.2 if you have your own libc)

Or you modify the rpath (and interpreter if necessary) in the binary, using a hex editor (haxxorz), sed or something (elite haxxorz) or patchelf from http://nix.cs.uu.nl/patchelf.html (me).

flip