Help Test portable Linux Love2d Binary

[Nixola]

I should soon be able to test AMD proprietary and AMDGPU, in a virtual machine but using GPU passthrough, so it should mirror native exactly.
EDIT: nevermind. It looks like linux does not like booting in that virtual machine. I'll have to install it on my pendrive and actually test natively... It will take more time than I thought.

[bartbes]

NVIDIA open source (was tested in vmware but if somebody is running native nouveau, a confirmation would be a bonus)

I was very confused by that vendor string too, but I was not running vmware, it was native, and from what I can tell it was nouveau.

[pgimeno]

I've got some stuff to report.

Downloaded and tested: https://bitbucket.org/rude/love/issues/ ... d64.tar.gz

First of all, LÖVE 0.10.2 runs successfully with ./love, so all is good (checked the version just to be sure).

However, ldconfig fails because it's in /sbin and there's no path there by default, so I get an error:

Code: Select all

./love: 4: ./love: ldconfig: not found

causing the libstdc++ path to be added regardless of having a good libstdc++. Does /sbin/ldconfig work in all systems?

<EDIT>
Maybe this works:

Code: Select all

LDCONFIG=ldconfig
type "${LDCONFIG}" > /dev/null || LDCONFIG=/sbin/ldconfig
"${LDCONFIG}" -p | ...

Verified to work with bash, dash and busybox sh ('type' is an internal command in all three; 'type -p' doesn't work in dash).
</EDIT>

Tested on a Debian Jessie 8.5:

Code: Select all

+ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
+ lsb_release -a
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	Debian
Description:	Debian GNU/Linux 8.5 (jessie)
Release:	8.5
Codename:	jessie
+ uname -mrs
Linux 3.16.0-4-amd64 x86_64
+ cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
+ lspci
+ grep VGA
02:00.0 VGA compatible controller: NVIDIA Corporation Device 13c2 (rev a1)
+ glxinfo
+ grep 'OpenGL renderer string'
OpenGL renderer string: GeForce GTX 970/PCIe/SSE2
+ glxinfo
+ grep 'OpenGL vendor'
OpenGL vendor string: NVIDIA Corporation
+ glxinfo
+ grep 'version string'
server glx version string: 1.4
client glx version string: 1.4
OpenGL core profile version string: 4.4.0 NVIDIA 367.27
OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler
OpenGL version string: 4.5.0 NVIDIA 367.27
OpenGL shading language version string: 4.50 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 367.27
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

I've added a ldd in front of the main love executable, and this is the output:

Code: Select all

./love: 4: ./love: ldconfig: not found
	linux-vdso.so.1 (0x00007ffd743d2000)
	liblove.so.0 => ./usr/lib/liblove.so.0 (0x00007fd10da6a000)
	libSDL2-2.0.so.0 => ./usr/lib/libSDL2-2.0.so.0 (0x00007fd10d73b000)
	libfreetype.so.6 => ./usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fd10d49c000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd10d298000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd10d07b000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd10ce73000)
	libopenal.so.1 => ./usr/lib/x86_64-linux-gnu/libopenal.so.1 (0x00007fd10cc19000)
	libz.so.1 => ./lib/x86_64-linux-gnu/libz.so.1 (0x00007fd10ca02000)
	libmodplug.so.1 => ./usr/lib/libmodplug.so.1 (0x00007fd10c730000)
	libvorbisfile.so.3 => ./usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 (0x00007fd10c527000)
	libvorbis.so.0 => ./usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fd10c2fa000)
	libtheoradec.so.1 => ./usr/lib/x86_64-linux-gnu/libtheoradec.so.1 (0x00007fd10c0de000)
	libogg.so.0 => ./usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007fd10bed8000)
	libluajit-5.1.so.2 => ./usr/lib/libluajit-5.1.so.2 (0x00007fd10bc69000)
	libmpg123.so.0 => ./usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007fd10ba0d000)
	libphysfs.so.1 => ./usr/lib/libphysfs.so.1 (0x00007fd10b7e3000)
	libstdc++.so.6 => ./libstdc++/libstdc++.so.6 (0x00007fd10b4dc000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd10b1db000)
	libgcc_s.so.1 => ./lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd10afc5000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd10ac1a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd10df32000)

Notably, the included libstdc++ has been used, and most other libraries are used from the current dir, except:
linux-vdso.so.1 (?)
/lib/x86_64-linux-gnu/libdl.so.2
/lib/x86_64-linux-gnu/libpthread.so.0
/lib/x86_64-linux-gnu/librt.so.1
/lib/x86_64-linux-gnu/libm.so.6
/lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2 (?)

HTH

[knuxyl]

i tested love-0.10.2-amd64 on Xubuntu 16.04.1 x86-64 with this output from uname -a
4.4.0-46-generic #67-Ubuntu SMP Thu Oct 20 15:05:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
and it loaded perfect without any output in terminal (standard love no game animated screen)

will this allow for easier cross-distro use for love2d?

great job everyone

[J-Reed]

NVIDIA open source (was tested in vmware but if somebody is running native nouveau, a confirmation would be a bonus)

I was very confused by that vendor string too, but I was not running vmware, it was native, and from what I can tell it was nouveau.

As extra confirmation, I tried on another box I have which is NVIDIA and got the Super Toast screen using love-0.10.2-amd64 and it shows "nouveau" instead of "vmware"...

Code: Select all

$ cat /etc/*-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=2
DISTRIB_CODENAME=betsy
DISTRIB_DESCRIPTION="LMDE 2 Betsy"
PRETTY_NAME="Linux Mint LMDE"
NAME="Linux Mint LMDE"
ID=linuxmint

$ lspci | grep VGA
02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev a2)

$ glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: Gallium 0.4 on NVAA

$ glxinfo | grep "OpenGL vendor"
OpenGL vendor string: nouveau

[bartbes]

However, ldconfig fails because it's in /sbin and there's no path there by default, so I get an error:

Code: Select all

./love: 4: ./love: ldconfig: not found

causing the libstdc++ path to be added regardless of having a good libstdc++. Does /sbin/ldconfig work in all systems?

<EDIT>
Maybe this works:

Code: Select all

LDCONFIG=ldconfig
type "${LDCONFIG}" > /dev/null || LDCONFIG=/sbin/ldconfig
"${LDCONFIG}" -p | ...

Verified to work with bash, dash and busybox sh ('type' is an internal command in all three; 'type -p' doesn't work in dash).
</EDIT>

Thanks for the heads up, I will look into this.

Notably, the included libstdc++ has been used, and most other libraries are used from the current dir, except:
linux-vdso.so.1 (?)
/lib/x86_64-linux-gnu/libdl.so.2
/lib/x86_64-linux-gnu/libpthread.so.0
/lib/x86_64-linux-gnu/librt.so.1
/lib/x86_64-linux-gnu/libm.so.6
/lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2 (?)

That's sounds about right, the vdso is a kernel thing, so not portable (and I don't think it's on the filesystem anyway), the runtime linker was skipped on purpose (that's ld-linux*), and the others are all part of libc, which I also skipped on purpose.

[Rucikir]

How cool is that ?
VERY COOL

[pgimeno]

and the others are all part of libc, which I also skipped on purpose.

I'm wondering about this.

First, are the problems with the included libstdc++ related to a mismatched libc? Would including libc solve them?

Second, how frequent is it to not have libstdc++ installed? That possibility seems remote to me. Could the check ask the user to install it instead of providing one? It seems to me like a fairly reasonable thing to ask to Linux users.

[bartbes]

First, are the problems with the included libstdc++ related to a mismatched libc? Would including libc solve them?

No, apparently the open source AMD drivers require libstdc++, and on some systems require a newer libstdc++ version. If there's a libstdc++ installed, I'm assuming it's at least as new as the one I'm shipping.

[easy82]

Here's another one with NVidia (love-0.10.2-amd64.tar.gz):

cat /etc/*-release

Code: Select all

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.3
DISTRIB_CODENAME=rosa
DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
NAME="Ubuntu"
VERSION="14.04.2 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.2 LTS"
VERSION_ID="14.04"

uname -mrs

Code: Select all

Linux 3.16.0-38-generic x86_64

lspci | grep VGA

Code: Select all

01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1)

glxinfo | grep "OpenGL renderer string"

Code: Select all

OpenGL renderer string: GeForce GTX 760/PCIe/SSE2

glxinfo | grep "OpenGL vendor"

Code: Select all

OpenGL vendor string: NVIDIA Corporation