LSB not preinstalled on Arch, causing missing file errors

[tslilc]

I'm not entirely sure what to do about this, as plainly distro_fixes.sh depends upon it. Perhaps add it to the list of system requirements, or warn that the OS checking has failed?

[lethosor]

It should be possible to fall back to another way of detecting Arch, although I haven't investigated.

[tslilc]

Also, as a side note, on my 64bit Arch I had to remove the bundled libstdc++.so.6 (or rename it, or exclude it from LD) as it was not able to load the ATI r600_dri.so I had on my system, for whatever reason. I'll look into OS detection more thoroughly.

EDIT: ... and while we're at it, I can't seem to convince PyLNP that there are any `hacks' available in the DFHack tab. I'm still working on tracking that down. In any event, thank you for your responsiveness.

[tslilc]

After some hunting around, it seems that /usr/lib/os-release is owned by the filesystem package in Arch, and there is also a copy in /etc/ (well, a symlink pointing to the former). Moreover, os-release is allegedly a 'standard' so perhaps we could change distro_fixes.sh to look at that file?

Perhaps something like, after the fedora check,

elif [-e /etc/os-release ]; then
  OS=$(grep \^NAME\= /etc/os-release | cut -d\= -f 2- | tr -d \")
  VER=$(grep \^VERSION\= /etc/os-release | cut -d\= -f 2- | tr -d \")
else;
  dlog "WARN" "OS not successfully detected"
fi;

[miffedmap]

/etc/release Is a recent-ish feature of distros introduced by the systemd people with their typical asshole attitude: http://0pointer.de/blog/projects/os-release It is available on many large distros these days though, so by all means add support for it.

We'll end up with foo_with_lsb and foo_without_lsb for everything, which is a pain, but then lsb might not be installed and otoh the distro may be too old to have /etc/os-release so can't be helped.

[lethosor]

@tslilc what are $OS and $VER set to on your machine after running that? Also, does DF work if you preload a working libstdc++ (via LD_PRELOAD) while keeping DF's copy in the libs directory?

[tslilc]

@lethosor: Well, $VER is never going to make sense for Arch (blank in the case of the sample code), and as for $OS it has the value Arch Linux. I meant to say that we'll likely have to adapt the subsequent if tree (which maybe we can turn into a case statement to leverage fallthrough on distro names) to whatever os-release will spit out. The more I think about this, the less of a good idea it seems :/

As for preloading, sure, that works fine too, the relevant line in distro_fixes.sh looks like

export PRELOAD_LIB="${PRELOAD_LIB:+$PRELOAD_LIB:}/usr/lib32/libz.so:/usr/lib32/libstdc++.so.6";

So I suppose that the Arch one should always look like this (also, /lib32/ -> /usr/lib32/ as a matter of preference as /lib* are symlinks in Arch anyway)

I'm happy to (re)write the OS detection thing, if you like, just tell me what you're going for.

[lethosor]

How does the script in this branch look?

Edit: I made the script preload libstdc++ on Arch as well. I'm not sure what you mean about preferring /usr/lib32 over /lib32, since the script prefers the former (and does so explicitly on Arch).

[tslilc]

That looks good, I have tested it with and without LSB and can confirm that it works for me. Thank you for your work! I'm satisfied that this issue (as well as the libstdc++) has been resolved.

EDIT: I'm not sure what I meant either, I really thought it read /lib32 instead of /usr/lib32. Disregard that.

[XVicarious]

@tslilc I'll open another ticket about this, but the reason that nothing shows up in the DFHack tab is because it isn't configured in PyLNP.json.

[lethosor]

Looks like this was fixed, but please reopen this report if not.