-1

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?

closed as off-topic by MelBurslan, Gilles, cas, garethTheRed, daisy May 20 '16 at 6:44

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Your question is more programming related than UNIX related and there is a very appropriate sister site for this, called Stackoverflow and your question is probably already has AN ANSWER over that way. – MelBurslan May 19 '16 at 19:43
  • 1
    @MelBurslan, I just read the "AN ANSWER" you pointed me to. It answers 60% of my questions which are not all programming questions. The other 40% of my questions is about how to get away without exporting LD_LIBRARY_PATH. The Mono foundation document talks about a launcher shell script attached to the C# executable. What is the naming convention for the launcher shell script? Thank you. – Frank May 19 '16 at 19:55
  • @MelBurslan, I got an launcher shell script working for starting a mono-service with our C# executable because of your help today. Do I need another launcher shell script working for stopping the mono-service with our C# executable? Or , May I use the same launcher shell script for both starting and stopping a mono-service for a specific C# executable? Thanks. – Frank May 19 '16 at 20:57
  • I'm not familiar with C#. With native code, the feature you're looking for would be a rpath, specified at link time during build. Standard libraries are in system directories which are always traversed, that's how libc.so.6 is found. – Gilles May 19 '16 at 21:55
  • Given that the solution to your problem is more likely to be related to the programming language you're using than to the environment you're installing into, I'm voting to migrate this question to Stack Overflow. – Gilles May 19 '16 at 21:57
1

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 behavior

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

Linked 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/application
APP_DIR_LIB="$APP_DIR/lib"
APP_DIR_EXE="$APP_DIR/someprogram.exe"

export LD_LIBRARY_PATH="$APP_LIB_DIR"${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
exec "$APP_DIR_EXE" "$@"

echo "Ooops" >&2
exit 1

I'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.

  • I consider your answer to be excellent(A+). I'll patiently wait for your update on stopping a service with point and click. – Frank May 20 '16 at 8:32
  • Why doesn't mysql installation on linux require user to specify LD_LIBRARY to find its' runtime shared oject dependenciies? – Frank May 20 '16 at 14:00
  • @Frank because MySQL is a packaged application that stores its libraries in one of the "well known places". – roaima May 20 '16 at 14:05
  • Thank you for your answer. If I wish my application to be a packaged application, how do I prepare it so that it stores its libraries in one of the well known places? – Frank May 20 '16 at 14:32
  • @Frank I think that's now outside the scope of this question/answer. You'll need to ask that one as a new question, please, remembering to specify your distribution. (Oh, the answer might well already exist, so do check first.). Feel free to cross-reference back to this question for the background. – roaima May 20 '16 at 14:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.