<div dir="ltr">Hi Tobias,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 19, 2018 at 11:40 AM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eliot,<br>
<br>
Long story short at the end<br>
<span class=""><br>
<br>
> On 19.01.2018, at 18:48, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
> Hi Tobias,<br>
><br>
><br>
>> On Jan 19, 2018, at 7:57 AM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>><br>
>> Hi all,<br>
>><br>
>> So I've seen this LD_LIBRARY_PATH dance in the squeak.sh wrapper.<br>
>> I would like to see an example where leaving it out fails.<br>
>> 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).<br>
><br>
> 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.<br>
><br>
>><br>
>> I have played around with dlopen on linux (<a href="https://github.com/krono/dltest" rel="noreferrer" target="_blank">https://github.com/krono/<wbr>dltest</a>) 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>I think I know why the thing is there, but it still bother me. More commentary does imho not help.<br>
<br>
I'd just say using LD_LIBRARY_PATH for non-debug/non-intercept purposes seems extremely uncommon to me:<br>
<br>
So, on my linux, there are 2375 common binaries [1], and of these 15 only ever mention LD_LIBRARY_PATH [2]<br>
Lets break them down:<br>
- Programs that are used to execute other programs to alter their behavior:<br>
- eatmydata (changes the way the system fsync works)<br>
- fakeroot-{tcp,zsh} (well, fake that we are root)<br>
(I thinks LD_LIBRARY_PATH was made exactly for those purposes)<br>
<br>
- Collect env vars for reporting/investigation (ie, LD_LIBRARY_PATH is just read and not used)<br>
- perlthanks<br>
- perlbug<br>
- rkhunter<br>
- Shells (Well, they might have to work with LD_LIBRARY_PATH, right? they are shells )<br>
- busybox<br>
- zsh<br>
- Perl : nonfunctional reference in a documentation string (both variants)<br>
- Loaders (Well, they make LD_LIBRARY_PATH work, they must use it....)<br>
- x86_64-linux-gnu-ld.bfd<br>
- ldconfig<br>
- icu-config: usage not unlike to squeak.sh but sole purpose is to provide Compilation flags.<br>
<br>
-----------------<br>
<br>
Although this is not _very_ representative, I don't think that squeak fits any those categories.<br>
And neither Ruby, Python, nor Nodejs, perl, or php, who all have FFI, seem to need any of such loader dances.<br>
<br>
I'm not denying that there are reasons that the LD_LIBRARY_PATH was put in.<br>
Certainly there was a need. But I would really like to see a concrete example.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br></blockquote><div><br></div><div>We only need one. But historically there are two. I didn't make that decision. I merely maintained the situation. Sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is prone to paths with spaces, very linux-centric, and depends on the concrete output of ldd.<br></blockquote><div><br></div><div>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). </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Again, I don't say that there was no reason to it to have it , in the first place).<br>
<br>
----------------<br>
<br>
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 :)<br></blockquote><div><br></div><div>Find a linux that has both /lib/libc.so.N and /lib/tls/libc.so.N and you'll have your sandbox :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Best regards<br>
-Tobias<br>
<br>
<br>
<br>
<br>
<br>
[1]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f | wc -l<br>
[2]: $ find /usr/bin /bin /sbin /usr/sbin /usr/local/bin -type f -exec grep LD_LIBRARY_PATH {} \+<br>
/usr/bin/icu-config:<wbr>LDLIBRARYPATH_ENVVAR="LD_<wbr>LIBRARY_PATH"<br>
Binary file /usr/bin/perl5.24.1 matches<br>
Binary file /usr/bin/x86_64-linux-gnu-ld.<wbr>bfd matches<br>
/usr/bin/eatmydata: LD_LIBRARY_PATH=${LD_LIBRARY_<wbr>PATH:+"$LD_LIBRARY_PATH:"}/<wbr>usr/lib/libeatmydata<br>
/usr/bin/eatmydata: export LD_LIBRARY_PATH LD_PRELOAD<br>
/usr/bin/perlthanks: qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);<br>
/usr/bin/perlbug: qw(PATH LD_LIBRARY_PATH LANG PERL_BADLANG SHELL HOME LOGDIR LANGUAGE);<br>
Binary file /usr/bin/perl matches<br>
/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<br>
/usr/bin/fakeroot-tcp:if test -n "$LD_LIBRARY_PATH"; then<br>
/usr/bin/fakeroot-tcp: PATHS="$PATHS:$LD_LIBRARY_<wbr>PATH"<br>
/usr/bin/fakeroot-tcp: FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}<br>
/usr/bin/fakeroot-tcp: FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"<br>
Binary file /usr/bin/zgz matches<br>
/usr/bin/rkhunter: # Finally we check the LD_LIBRARY_PATH. This check may be<br>
/usr/bin/rkhunter: if [ -n "${LD_LIBRARY_PATH}" ]; then<br>
/usr/bin/rkhunter: LD_LIBRARY_PATH_SAVED="${LD_<wbr>LIBRARY_PATH}"<br>
/usr/bin/rkhunter: LD_LIBRARY_PATH="${LD_LIBRARY_<wbr>PATH_SAVED}"<br>
/usr/bin/rkhunter: export LD_LIBRARY_PATH<br>
/usr/bin/rkhunter: unset LD_LIBRARY_PATH<br>
/usr/bin/rkhunter: LD_LIBRARY_PATH="${LD_LIBRARY_<wbr>PATH_SAVED}"<br>
/usr/bin/rkhunter: export LD_LIBRARY_PATH<br>
/usr/bin/rkhunter: display --to LOG --type WARNING SHARED_LIBS_PATH_BAD "${LD_LIBRARY_PATH}"<br>
/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<br>
/usr/bin/fakeroot-sysv:if test -n "$LD_LIBRARY_PATH"; then<br>
/usr/bin/fakeroot-sysv: PATHS="$PATHS:$LD_LIBRARY_<wbr>PATH"<br>
/usr/bin/fakeroot-sysv: FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" ${SHELL:-/bin/sh}<br>
/usr/bin/fakeroot-sysv: FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"<br>
Binary file /bin/zsh matches<br>
Binary file /bin/busybox matches<br>
Binary file /sbin/ldconfig matches</blockquote></div><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>