The squeak.sh wrapper an LD_LIBRARY_PATH

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

The squeak.sh wrapper an LD_LIBRARY_PATH

Tobias Pape
 
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).

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.

Best regards
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Eliot Miranda-2
 
Hi Tobias,


> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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.

> Best regards
>    -Tobias

Cheers!
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

timrowledge
 

> On 19-01-2018, at 9:48 AM, Eliot Miranda <[hidden email]> wrote:

>   Perhaps we should put more commentary in the script.

Better yet, put a more expansive explanation on the swiki and a link to that in the script


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A prime candidate for natural deselection.


Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Tobias Pape
 

> On 19.01.2018, at 19:37, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 19-01-2018, at 9:48 AM, Eliot Miranda <[hidden email]> wrote:
>
>>  Perhaps we should put more commentary in the script.
>
> Better yet, put a more expansive explanation on the swiki and a link to that in the script
>

On that note, the swiki badly needs to make links default, that are not numbers.
Everything is lost to unremeberable numbers…

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- A prime candidate for natural deselection.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Tobias Pape
In reply to this post by Eliot Miranda-2
 
Hi Eliot,

Long story short at the end


> On 19.01.2018, at 18:48, Eliot Miranda <[hidden email]> wrote:
>
>
> Hi Tobias,
>
>
>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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.

-----------------

Although this is not _very_ representative, I don't think that squeak fits any those categories.
And neither Ruby, Python, nor Nodejs, perl, or php, who all have FFI, seem to need any of such loader dances.

I'm not denying that there are reasons that the LD_LIBRARY_PATH was put in.
Certainly there was a need. But I would really like to see a concrete example.
To be frank, I'd really love it if we could get rid of the shell script altogether (especially since we actually have two virtually identical ones).
It is prone to paths with spaces, very linux-centric, and depends on the concrete output of ldd.
(Again, I don't say that there was no reason to it to have it , in the first place).

----------------

Long story short: I'd love to see an actual problem-generating config (libs, deps of libs or so), so I can understand that stuff better :)



Best regards
        -Tobias





[1]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f | wc -l
[2]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f -exec grep LD_LIBRARY_PATH {} \+
/usr/bin/icu-config:LDLIBRARYPATH_ENVVAR="LD_LIBRARY_PATH"
Binary file /usr/bin/perl5.24.1 matches
Binary file /usr/bin/x86_64-linux-gnu-ld.bfd matches
/usr/bin/eatmydata:   LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
/usr/bin/eatmydata:   export LD_LIBRARY_PATH LD_PRELOAD
/usr/bin/perlthanks:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
/usr/bin/perlbug:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
Binary file /usr/bin/perl matches
/usr/bin/fakeroot-tcp:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s HUP $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
/usr/bin/fakeroot-tcp:if test -n "$LD_LIBRARY_PATH"; then
/usr/bin/fakeroot-tcp:  PATHS="$PATHS:$LD_LIBRARY_PATH"
/usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
/usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
Binary file /usr/bin/zgz matches
/usr/bin/rkhunter: # Finally we check the LD_LIBRARY_PATH. This check may be
/usr/bin/rkhunter: if [ -n "${LD_LIBRARY_PATH}" ]; then
/usr/bin/rkhunter: LD_LIBRARY_PATH_SAVED="${LD_LIBRARY_PATH}"
/usr/bin/rkhunter: LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
/usr/bin/rkhunter: export LD_LIBRARY_PATH
/usr/bin/rkhunter: unset LD_LIBRARY_PATH
/usr/bin/rkhunter: LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
/usr/bin/rkhunter: export LD_LIBRARY_PATH
/usr/bin/rkhunter: display --to LOG --type WARNING SHARED_LIBS_PATH_BAD "${LD_LIBRARY_PATH}"
/usr/bin/fakeroot-sysv:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s TERM $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
/usr/bin/fakeroot-sysv:if test -n "$LD_LIBRARY_PATH"; then
/usr/bin/fakeroot-sysv:  PATHS="$PATHS:$LD_LIBRARY_PATH"
/usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
/usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
Binary file /bin/zsh matches
Binary file /bin/busybox matches
Binary file /sbin/ldconfig matches
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Alistair Grant
 
Hi Tobias,

On 19 January 2018 at 20:40, Tobias Pape <[hidden email]> wrote:

>
> Hi Eliot,
>
> Long story short at the end
>
>
>> On 19.01.2018, at 18:48, Eliot Miranda <[hidden email]> wrote:
>>
>>
>> Hi Tobias,
>>
>>
>>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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.

Cheers,
Alistair




> -----------------
>
> Although this is not _very_ representative, I don't think that squeak fits any those categories.
> And neither Ruby, Python, nor Nodejs, perl, or php, who all have FFI, seem to need any of such loader dances.
>
> I'm not denying that there are reasons that the LD_LIBRARY_PATH was put in.
> Certainly there was a need. But I would really like to see a concrete example.
> To be frank, I'd really love it if we could get rid of the shell script altogether (especially since we actually have two virtually identical ones).
> It is prone to paths with spaces, very linux-centric, and depends on the concrete output of ldd.
> (Again, I don't say that there was no reason to it to have it , in the first place).
>
> ----------------
>
> Long story short: I'd love to see an actual problem-generating config (libs, deps of libs or so), so I can understand that stuff better :)
>
>
>
> Best regards
>         -Tobias
>
>
>
>
>
> [1]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f | wc -l
> [2]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f -exec grep LD_LIBRARY_PATH {} \+
> /usr/bin/icu-config:LDLIBRARYPATH_ENVVAR="LD_LIBRARY_PATH"
> Binary file /usr/bin/perl5.24.1 matches
> Binary file /usr/bin/x86_64-linux-gnu-ld.bfd matches
> /usr/bin/eatmydata:   LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
> /usr/bin/eatmydata:   export LD_LIBRARY_PATH LD_PRELOAD
> /usr/bin/perlthanks:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
> /usr/bin/perlbug:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
> Binary file /usr/bin/perl matches
> /usr/bin/fakeroot-tcp:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s HUP $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
> /usr/bin/fakeroot-tcp:if test -n "$LD_LIBRARY_PATH"; then
> /usr/bin/fakeroot-tcp:  PATHS="$PATHS:$LD_LIBRARY_PATH"
> /usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
> /usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
> Binary file /usr/bin/zgz matches
> /usr/bin/rkhunter:      # Finally we check the LD_LIBRARY_PATH. This check may be
> /usr/bin/rkhunter:                      if [ -n "${LD_LIBRARY_PATH}" ]; then
> /usr/bin/rkhunter:                              LD_LIBRARY_PATH_SAVED="${LD_LIBRARY_PATH}"
> /usr/bin/rkhunter:                                      LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
> /usr/bin/rkhunter:                                      export LD_LIBRARY_PATH
> /usr/bin/rkhunter:                                      unset LD_LIBRARY_PATH
> /usr/bin/rkhunter:                              LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
> /usr/bin/rkhunter:                              export LD_LIBRARY_PATH
> /usr/bin/rkhunter:                                      display --to LOG --type WARNING SHARED_LIBS_PATH_BAD "${LD_LIBRARY_PATH}"
> /usr/bin/fakeroot-sysv:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s TERM $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
> /usr/bin/fakeroot-sysv:if test -n "$LD_LIBRARY_PATH"; then
> /usr/bin/fakeroot-sysv:  PATHS="$PATHS:$LD_LIBRARY_PATH"
> /usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
> /usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
> Binary file /bin/zsh matches
> Binary file /bin/busybox matches
> Binary file /sbin/ldconfig matches
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Tobias Pape
 
Hi Alistair

> On 19.01.2018, at 20:48, Alistair Grant <[hidden email]> wrote:
>
>
> Hi Tobias,
>
> On 19 January 2018 at 20:40, Tobias Pape <[hidden email]> wrote:
>>
>> Hi Eliot,
>>
>> Long story short at the end
>>
>>
>>> On 19.01.2018, at 18:48, Eliot Miranda <[hidden email]> wrote:
>>>
>>>
>>> Hi Tobias,
>>>
>>>
>>>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Alistair Grant
 
Hi Tobias,

On 19 January 2018 at 20:51, Tobias Pape <[hidden email]> wrote:

>
> Hi Alistair
>
>> On 19.01.2018, at 20:48, Alistair Grant <[hidden email]> wrote:
>>
>>
>> Hi Tobias,
>>
>> On 19 January 2018 at 20:40, Tobias Pape <[hidden email]> wrote:
>>>
>>> Hi Eliot,
>>>
>>> Long story short at the end
>>>
>>>
>>>> On 19.01.2018, at 18:48, Eliot Miranda <[hidden email]> wrote:
>>>>
>>>>
>>>> Hi Tobias,
>>>>
>>>>
>>>>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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.

OK, I misunderstood what you are proposing.  Thanks for the clarification!

Cheers,
Alistair
Reply | Threaded
Open this post in threaded view
|

Re: The squeak.sh wrapper an LD_LIBRARY_PATH

Eliot Miranda-2
In reply to this post by Tobias Pape
 
Hi Tobias,

On Fri, Jan 19, 2018 at 11:40 AM, Tobias Pape <[hidden email]> wrote:

Hi Eliot,

Long story short at the end


> On 19.01.2018, at 18:48, Eliot Miranda <[hidden email]> wrote:
>
>
> Hi Tobias,
>
>
>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <[hidden email]> 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.

-----------------

Although this is not _very_ representative, I don't think that squeak fits any those categories.
And neither Ruby, Python, nor Nodejs, perl, or php, who all have FFI, seem to need any of such loader dances.

I'm not denying that there are reasons that the LD_LIBRARY_PATH was put in.
Certainly there was a need. But I would really like to see a concrete example.

OK.  So you can find the issue by googling for lib/tls/libc.  Some lines have both /lib/libc.so.6 and /lib/tls/libc.so.6.  In fact there are lots of variations on these naming schemes and I think there may be even more variants that simply between /lib and /lib/tls (for thread-local storage).  In any case, one's VM may be linked against either one, and one's libraries need to use the same one, otherwise one has two different, incompatible libc.so.6 libraries loaded and chaos can ensue.  So the solution is, on start-up, to find out which libc the Vm is binding to, and to install a LD_LIBRARY_PATH in the environment that will ensure that loaded libraries will pick up the same one.  Of course the same goes for any library that is in more than one place and in use by the Vm and libraries; libc.so is simply the most likely library.

 
To be frank, I'd really love it if we could get rid of the shell script altogether (especially since we actually have two virtually identical ones).

We only need one.  But historically there are two.  I didn't make that decision.  I merely maintained the situation.  Sorry.
 
It is prone to paths with spaces, very linux-centric, and depends on the concrete output of ldd.

Indeed.  It is in fact a hack around a bug in linux.  Why linux allows this situation to occur in the first place is beyond me; it seems insane.  But my employer needed a solution and so the initial case statement was developed and extended until some kind soul replaced it with the one liner that's there now ok, two lines, (one line to extract it, another to install it). 

(Again, I don't say that there was no reason to it to have it , in the first place).

----------------

Long story short: I'd love to see an actual problem-generating config (libs, deps of libs or so), so I can understand that stuff better :)

Find a linux that has both /lib/libc.so.N and /lib/tls/libc.so.N and you'll have your sandbox :-)
 
Best regards
        -Tobias





[1]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f | wc -l
[2]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f -exec grep LD_LIBRARY_PATH {} \+
/usr/bin/icu-config:LDLIBRARYPATH_ENVVAR="LD_LIBRARY_PATH"
Binary file /usr/bin/perl5.24.1 matches
Binary file /usr/bin/x86_64-linux-gnu-ld.bfd matches
/usr/bin/eatmydata:   LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
/usr/bin/eatmydata:   export LD_LIBRARY_PATH LD_PRELOAD
/usr/bin/perlthanks:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
/usr/bin/perlbug:        qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);
Binary file /usr/bin/perl matches
/usr/bin/fakeroot-tcp:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s HUP $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
/usr/bin/fakeroot-tcp:if test -n "$LD_LIBRARY_PATH"; then
/usr/bin/fakeroot-tcp:  PATHS="$PATHS:$LD_LIBRARY_PATH"
/usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
/usr/bin/fakeroot-tcp:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
Binary file /usr/bin/zgz matches
/usr/bin/rkhunter:      # Finally we check the LD_LIBRARY_PATH. This check may be
/usr/bin/rkhunter:                      if [ -n "${LD_LIBRARY_PATH}" ]; then
/usr/bin/rkhunter:                              LD_LIBRARY_PATH_SAVED="${LD_LIBRARY_PATH}"
/usr/bin/rkhunter:                                      LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
/usr/bin/rkhunter:                                      export LD_LIBRARY_PATH
/usr/bin/rkhunter:                                      unset LD_LIBRARY_PATH
/usr/bin/rkhunter:                              LD_LIBRARY_PATH="${LD_LIBRARY_PATH_SAVED}"
/usr/bin/rkhunter:                              export LD_LIBRARY_PATH
/usr/bin/rkhunter:                                      display --to LOG --type WARNING SHARED_LIBS_PATH_BAD "${LD_LIBRARY_PATH}"
/usr/bin/fakeroot-sysv:  trap 'FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" /bin/ls -l / >/dev/null 2>&1; while kill -s TERM $PID 2>/dev/null; do sleep 0.1; done' EXIT INT
/usr/bin/fakeroot-sysv:if test -n "$LD_LIBRARY_PATH"; then
/usr/bin/fakeroot-sysv:  PATHS="$PATHS:$LD_LIBRARY_PATH"
/usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}
/usr/bin/fakeroot-sysv:  FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS"  LD_PRELOAD="$LIB" "$@"
Binary file /bin/zsh matches
Binary file /bin/busybox matches
Binary file /sbin/ldconfig matches

_,,,^..^,,,_
best, Eliot