What's new

Entware Okay to install entware update?

Thanks for diving into this further, @Martinski...

So to be clear, each of our scripts need to have LD_LIBRARY_PATH="" or unset LD_LIBRARY_PATH directly after the #!/bin/sh in order to fix this, or get it into compliance with whatever this change was?
The unset LD_LIBRARY_PATH statement is all you need; it can be placed either before or after the "export PATH=..." line - it makes no difference either way.

What happens if this runs on an older installation of Entware? Or is this benign no matter what version you're on?
With older Entware binaries that still use the RPATH embedded library search mechanism, the LD_LIBRARY_PATH is never used anyway because RPATH takes precedence. So yes, the added line is completely harmless.

I also explicitly include a PATH statement near the top of each script. Does this have any effect on this change, or would it need to require any modification to help with compatibility?
The PATH and LD_LIBRARY_PATH environment variables have different purposes. The PATH variable gives the shell a list of directories to search for executable programs when you don't provide the full path. OTOH, the LD_LIBRARY_PATH variable gives the dynamic linker a list of directories to search for shared libraries that are dynamically linked to executable binaries.

HTH.
 
@Martinski @Viktor Jaep

Random thought from a non-coder - would it be more efficient going forward (assuming it works) for the presence checking / insertion of the unset LD_LIBRARY_PATH statement into /jffs/scripts/service-event to be part of the Entware install done via AMTM - rather than being done by every script (that needs it)?

Probably missing something as usual ...

:D
 
Last edited:
@Martinski @Viktor Jaep

Random thought from a non-coder - would it be more efficient going forward (assuming it works) for the presence checking / insertion of the unset LD_LIBRARY_PATH statement into /jffs/scripts/service-event to be part of the Entware install done via AMTM - rather than being done by every script (that needs it)?
That would have been ideal IF every single script always used /jffs/scripts/service-event but that's not the case, nor should it be.

Shell scripts can also be launched in other ways. For example, some failures have been reported when a script (which at some point runs an Entware binary), is executed via the built-in cron job scheduler, likely because it inherits the native system environment, which exports the LD_LIBRARY_PATH variable.

In any case, it doesn’t hurt if the statement is added to the service-event script, but it wouldn’t solve the potential problem for every single script or for every execution path. Adding the "unset" statement to the script itself solves this particular issue WRT Entware binaries, no matter how the script gets launched.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top