[Vm-dev] The squeak.sh wrapper an LD_LIBRARY_PATH

Tobias Pape Das.Linux at gmx.de
Fri Jan 19 19:51:33 UTC 2018


Hi Alistair 

> On 19.01.2018, at 20:48, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> 
> Hi Tobias,
> 
> On 19 January 2018 at 20:40, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> Hi Eliot,
>> 
>> Long story short at the end
>> 
>> 
>>> On 19.01.2018, at 18:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> 
>>> 
>>> Hi Tobias,
>>> 
>>> 
>>>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> So I've seen this LD_LIBRARY_PATH dance in the squeak.sh wrapper.
>>>> I would like to see an example where leaving it out fails.
>>>> My assumption is, that we can rather do something about it on the dlopen-side of the problem and make this script simpler (or even completely unnecessary).
>>> 
>>> It is vital in cases where one is using external  dynamic link libraries which themselves use other dynamic link libraries.  Also vital in cares where there are variants of e.g. lunch.so for different implementations of features such as thread-local storage.
>>> 
>>>> 
>>>> I have played around with dlopen on linux (https://github.com/krono/dltest) and my bet is that if we catch all strange names of libc on the dlopen side, change them to "libc.so.6" and just go with it, we might end up just fine.
>>> 
>>> We might.  But in my hard experience at Cadence using external libraries for license verification, xml parsing and much more, we don't.  It may seem complex but it's there for a reason, and If It Ain't Broke, Don't Fix It. Further, debugging some application because, due to it not having the right LD_LIBRARY_PATH, the VM is using a different errno to that the library ends up using (for a complete because the VM is using a thread-specific implementation but the library ends up using a static one) is really hard, and results in one implementing the LD_LIBRARY_PATH dance you see in the script.
>>> 
>>> I hope the dance makes more sense now.  Perhaps we should put more commentary in the script.  One /really/ doesn't want these kinds of things to break unless one loves migraines.
>> 
>> I think I know why the thing is there, but it still bother me. More commentary does imho not help.
>> 
>> I'd just say using LD_LIBRARY_PATH for non-debug/non-intercept purposes seems extremely uncommon to me:
>> 
>> So, on my linux, there are 2375 common binaries [1], and of these 15 only ever mention LD_LIBRARY_PATH [2]
>> Lets break them down:
>> - Programs that are used to execute other programs to alter their behavior:
>>   - eatmydata (changes the way the system fsync works)
>>   - fakeroot-{tcp,zsh} (well, fake that we are root)
>>  (I thinks LD_LIBRARY_PATH was made exactly for those purposes)
>> 
>> - Collect env vars for reporting/investigation (ie, LD_LIBRARY_PATH is just read and not used)
>>  - perlthanks
>>  - perlbug
>>  - rkhunter
>> - Shells (Well, they might have to work with LD_LIBRARY_PATH, right? they are shells )
>>  - busybox
>>  - zsh
>> - Perl : nonfunctional reference in a documentation string (both variants)
>> - Loaders (Well, they make LD_LIBRARY_PATH work, they must use it....)
>>  - x86_64-linux-gnu-ld.bfd
>>  - ldconfig
>> - icu-config: usage not unlike to squeak.sh but sole purpose is to provide Compilation flags.
> 
> I had to use LD_LIBRARY_CONFIG to get the VM to run within an Ubuntu
> snap container.  I'm afraid I don't understand the library resolution
> process well enough to really comment further, but it would be
> annoying if the VM couldn't be used within a container due to lack of
> LD_LIBRARY_CONFIG support.

I do not intend to remove support for anything. I just like to make running squeak more "standard" (whatever that means) :)
Even If we can remove the things I talked about, that does not touch the usability of any of the LD_ variables.

Best regards
	-Tobias


More information about the Vm-dev mailing list