Where do C# executables running on an Ubuntu Linux 16.04 Lenovo Thinkstation desktop which use source code that DLLImport's shared objects (so's) look for shared objects at runtime? Even if the shared object libxyz.so resides in same subdirectory as the C# executable's subdirectory, I found that it is necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behavior. Why is this the case?We noticed that during the installation of many third-party Linux software products, the installation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATH containing that subdirectory. Why is that the case? Also, if we wish to run the  C# executable as a point and click mono-service, how do we globally specify LD_LIBRARY_PATH, until the computer reboots,  without resorting to opening an Ubuntu Linux 16.04 terminal? Is there a more elegant way than passing LD_LIBRARY_PATH as an envp argument to execle?
Where do C# executables running on an Ubuntu Linux 16.04 desktop which use source code that DLLImport's shared objects look for them at runtime?
compiling;environment variables;dynamic linking;shared library;c#
I'll try to answer all three parts of this question for you[Why is it] necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behaviorinstallation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATHLinked libraries are referenced from a known set of locations. Typically these are system directories so that privileged code can use them safely (they can't be overwritten by users).Once you understand this you realise that the set of known locations cannot not include .. You can see the set of known locations by examining the text file /etc/ld.so.conf. If you edit it you must run ldconfig to update its correpsonding binary database.The set of known locations can be extended per application by using an instance of LD_LIBRARY_PATH, which takes a colon-separated list of directories to search. If you use this though, the kernel discards all privileges from a program - so you can't use it to cheat passwd or sudo, for example.how do we globally specify LD_LIBRARY_PATH, until the computer reboots [...] Is there a more elegant way than passing LD_LIBRARY_PATH as an envp argument to execle?Setting it globally would be a really bad idea as it would break sudo, passwd, and other privileged programs. I don't see why you can't set LD_LIBRARY_PATH in a shell script per application, though. You don't need to start it as a terminal program as it doesn't write anything significant to a terminal#!/bin/bash#APP_DIR=/path/to/applicationAPP_DIR_LIB=$APP_DIR/libAPP_DIR_EXE=$APP_DIR/someprogram.exeexport LD_LIBRARY_PATH=$APP_LIB_DIR${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}exec $APP_DIR_EXE $@echo Ooops >&2exit 1I've used $@ so that any arguments passed to the script are applied to the executable itself.I don't know how you would start or stop a mono service so I can't help you with the specifics of that. If you update your question I'll see if there's anything I can add here.