Linking fails when building the latest dev version on Ubuntu 16.04

[slime73]

Original report by Kyrio (Bitbucket: Kyrio, GitHub: Kyrio).

---

According to this report, the following bug might have more to do with GCC. However, since it doesn't appear when I build LÖVE 0.10.1, I thought it might be useful to report it.

Here is the error message displayed by the linker when I try to build LÖVE from the latest commit (53ede14) on Ubuntu 16.04, 64-bit, gcc 5.3.1:

#!make

*** Warning: Linking the executable love against the loadable module
*** liblove.so is not portable!
libtool: link: g++ -o .libs/love love.o  ./.libs/liblove.so -lluajit-5.1 -lmpg123 -lphysfs
/usr/bin/ld: .libs/love: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

Looks like a bug with (the ubuntu distribution of?) gcc, affecting the newer versions of stb_image. See also the relevant stb_image bug.

Possible workarounds include:

• Adding the libraries mentioned in the ubuntu bug
• Reverting to an old version of stb_image

[slime73]

Original comment by Kyrio (Bitbucket: Kyrio, GitHub: Kyrio).

---

Thanks for the help! For now I'm working on 0.10.1 but I'll report it here if I manage to build the default branch using one of those workarounds.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

Looks like @Rude added a workaround, but only if you build with CMake (for now): 7bcb758

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

I'll wait to see if ubuntu fixes it, but if not I'll add a workaround before release.

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

Make stb_image only use SSE2 on x86_64, or when an override has been set (fixes #1173)

Turns out, this is a gcc bug: detecting sse2 support cannot be done in shared
libraries. For now we'll assume 32-bit x86 builds are intended to also run on
devices without SSE2 (how old!). In the future we might decide we only support
machines that support SSE2, if we secretly don't already.

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

Since I can't reproduce this (easily) myself, I can only assume this fixes it, so if anyone wants to test, that'd be great. (I'm fairly sure, though.)

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

The cmake-specific workaround should probably be changed now, right?

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

Oops. I even explicitly set out to do so, yet managed to forget just before comitting.