Build on Ubuntu 16.04: libtiff4 at build; libGLEW at runtime

Build on Ubuntu 16.04: libtiff4 at build; libGLEW at runtime

Postby BeanAcres » 09 Sep 2018, 00:14

Hi folks,

I am attempting to revisit the subject of SuperTux development ;-) - a couple of years ago my daughter had some new badguy ideas that she drew some pictures and descriptions for; we posted them at the time but have not been active on it really since then.

A while back I had a successful ST debug build that I could step through in gdb. I'd started learning the basic class layout and runtime stages of SuperTux.

In the interim I've updated my machine to Ubuntu 16.04. I am having some trouble building ST from either an official source release or one of the nightly builds.

Apologies in advance for the amount of detail below.

I am a bit rusty with C++ and build concerns, so please forgive if I'm missing something obvious. At the final (link) phase things error out with:

{l Code}: {l Select All Code}
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2_image.so: undefined reference to `TIFFGetField@LIBTIFF_4.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2_image.so: undefined reference to `TIFFClose@LIBTIFF_4.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2_image.so: undefined reference to `TIFFClientOpen@LIBTIFF_4.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2_image.so: undefined reference to `TIFFReadRGBAImage@LIBTIFF_4.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2_image.so: undefined reference to `TIFFSetErrorHandler@LIBTIFF_4.0'


I did some digging and I believe I successfully installed libtiff4 according to these posts:

https://github.com/yvt/openspades/issues/580
https://askubuntu.com/questions/449571/dependency-is-not-satisfiable-libtiff4-when-trying-to-install-lightworks-on-ubu

Here is my result from "sudo apt list --installed | grep tiff:

{l Code}: {l Select All Code}
libtiff-tools/xenial-updates,xenial-security,now 4.0.6-1ubuntu0.4 amd64 [installed,automatic]
libtiff4/now 3.9.7-2ubuntu1 amd64 [installed,local]
libtiff5/xenial-updates,xenial-security,now 4.0.6-1ubuntu0.4 amd64 [installed]
libtiff5-dev/xenial-updates,xenial-security,now 4.0.6-1ubuntu0.4 amd64 [installed]
libtiffxx5/xenial-updates,xenial-security,now 4.0.6-1ubuntu0.4 amd64 [installed]


My latest build attempt used the following command line for cmake:

{l Code}: {l Select All Code}
chuck@Beans-E6400:~/SuperTux-v0.5.1-1000-ga100d02f0-Source/build$ cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=DEBUG -DlibGLEW_LIBRARY=/usr/lib/x86_64-linux-gnu/libGLEW.so.1.13 .. -Dlibtiff4_LIBRARY=/usr/lib/x86_64-linux-gnu/libtiff.so.4.3.6 ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
--   date_time
--   locale
-- Found ZLIB: /opt/anaconda3/lib/libz.so (found version "1.2.8")
-- Found PNG: /opt/anaconda3/lib/libpng.so (found version "1.6.27")
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for one of the modules 'sdl2>=2.0.1'
-- Checking for one of the modules 'SDL2_image>=2.0.0'
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so 
-- Found OpenAL: /usr/lib/x86_64-linux-gnu/libopenal.so 
-- Looking for vorbis_bitrate_addblock in vorbis
-- Looking for vorbis_bitrate_addblock in vorbis - found
-- Found OggVorbis: /usr/lib/x86_64-linux-gnu/libvorbisfile.so;/usr/lib/x86_64-linux-gnu/libvorbis.so;/usr/lib/x86_64-linux-gnu/libogg.so
-- Could NOT find PhysFS (missing:  PHYSFS_LIBRARY PHYSFS_INCLUDE_DIR)
-- Looking for PHYSFS_getPrefDir
-- Looking for PHYSFS_getPrefDir - not found
-- Found CURL: /opt/anaconda3/lib/libcurl.so (found version "7.52.1")
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Performing Test HAVE_ICONV_CONST
-- Performing Test HAVE_ICONV_CONST - Failed
-- Check size of void*
-- Check size of void* - done
-- Size of void* is 8
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    libGLEW_LIBRARY
    libtiff4_LIBRARY


-- Build files have been written to: /home/chuck/SuperTux-v0.5.1-1000-ga100d02f0-Source/build


As evidenced by that last warning, it seems I didn't quite do it right when trying to tell cmake where to find libGLEW and libtiff4. I gave it a go anyway but without success.

The libGLEW is there because in the past I had been able to build ST from either the 5.0 or 5.1 release source tarballs, but ran into this error when running the resulting "suptertux2":

{l Code}: {l Select All Code}
/home/chuck/SuperTux-v0.5.0-Source/build/supertux2: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory


I just verified with the above-referenced old 5.0 build that this error still occurs. I did some googleing and the following link was interesting:

https://www.linuxquestions.org/questions/slackware-14/where-to-find-glew-so-2-1-a-4175613831/

I seem to have a newer-than-expected libGLEW though:

{l Code}: {l Select All Code}
apt list | grep glew

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

glew-utils/xenial 1.13.0-2 amd64
libglew-dbg/xenial 1.13.0-2 amd64
libglew-dev/xenial,now 1.13.0-2 amd64 [installed]
libglew1.13/xenial,now 1.13.0-2 amd64 [installed]
libglewmx-dbg/xenial 1.13.0-2 amd64
libglewmx-dev/xenial 1.13.0-2 amd64
libglewmx1.13/xenial,now 1.13.0-2 amd64 [installed]


... so I figured perhaps I should try to provide the path to that .so as as well. In the meantime the libtiff4 dependency problem has been added.

Anyway, I've searched the forum here but have not had any luck, nor anything obvious on the wiki. Thanks in advance for any tips.

Best regards,
Chuck Lutz
BeanAcres
 
Posts: 7
Joined: 25 Jun 2016, 15:20

Re: Build on Ubuntu 16.04: libtiff4 at build; libGLEW at run

Postby mteufel » 09 Sep 2018, 10:15

Hi,

I am a bit surprised as to your attempts to install libtiff; I never had to do this manually, it might be a dependency of our dependencies though. I would suggest you to first ensure you have all the dependencies installed. Unfortunately our documentation on building is really bad at the moment (there are various different documents suggesting different things).

On Ubuntu, you will need the following packages to be installed (it is important to note that you need the -dev versions here, otherwise you'll be missing some information necessary for the compiler):
{l Code}: {l Select All Code}
cmake build-essential libogg-dev libvorbis-dev libglew-dev libopenal-dev libboost-all-dev libsdl2-dev libsdl2-image-dev

Additionally you will need a recent compiler, our automated build uses GCC 8 or Clang 6 from a PPA on Ubuntu 14.04. I am not sure if Ubuntu 16.04 ships recent enough versions of either of those.

Then the following command in your build/ directory should be enough (there is no need to specify the paths to the libraries, it will find them automatically) to get a working SuperTux binary:
{l Code}: {l Select All Code}
cmake .. -DCMAKE_BUILD_TYPE=Debug


If you still encounter problems after following these instructions, please provide a full build log and do not use different versions of the source code (you apparently tried a development version from https://download.supertux.org/ and the v0.5.0 release, as the paths in your post suggest).
SuperTux developer
mteufel
 
Posts: 139
Joined: 03 Jan 2016, 09:27

Re: Build on Ubuntu 16.04: libtiff4 at build; libGLEW at run

Postby BeanAcres » 20 Sep 2018, 03:40

Hi again,

Thanks for the help. Somehow I got it to build for the SuperTux-v0.5.0-Source release, but not SuperTux-v0.5.1-Source or SuperTux-v0.5.1-1000-ga100d02f0-Source (I tried with all three).

My system seems happy with the state of the dev packages you listed:

{l Code}: {l Select All Code}
chuck@Beans-E6400:~/SuperTux-v0.5.1-Source/build$ !1861
sudo apt-get install cmake build-essential libogg-dev libvorbis-dev libglew-dev libopenal-dev libboost-all-dev libsdl2-dev libsdl2-image-dev
[sudo] password for chuck:
Reading package lists... Done
Building dependency tree       
Reading state information... Done
build-essential is already the newest version (12.1ubuntu2).
libglew-dev is already the newest version (1.13.0-2).
libogg-dev is already the newest version (1.3.2-1).
libboost-all-dev is already the newest version (1.58.0.1ubuntu1).
libopenal-dev is already the newest version (1:1.16.0-3).
libsdl2-dev is already the newest version (2.0.4+dfsg1-2ubuntu2).
cmake is already the newest version (3.5.1-1ubuntu3).
libvorbis-dev is already the newest version (1.3.5-3ubuntu0.2).
libsdl2-image-dev is already the newest version (2.0.1+dfsg-2+deb9u1build0.16.04.1).
The following package was automatically installed and is no longer required:
  gcc-5-base:i386
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 185 not upgraded.


I managed to get g++-8.1 via a PPA. I noticed that cmake was still choosing the default on my system (g++ 5.4.0 in /user/bin/g++) and I found a trick to set CC and CXX before kicking off cmake, so I did that and it seems to find the correct version of the compiler.

I've included a capture of the build output for the nightly source release I'd tried (I am not much familiar with cmake yet; I could not find any obvious automatically-captured build log in the output). I included the cmake output, before the full make output. I see that the commit pile for ST lately is quite big, so I figure best to get reacquainted with the code using a new version :-)

I don't think I sent this earlier; here is what shows up for all things "libsdl":

{l Code}: {l Select All Code}
chuck@Beans-E6400:~$ apt list --installed | egrep libsdl

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libsdl-gfx1.2-5/xenial,now 2.0.25-5 amd64 [installed,automatic]
libsdl-image1.2/xenial-updates,xenial-security,now 1.2.12-5+deb9u1build0.16.04.1 amd64 [installed,automatic]
libsdl-mixer1.2/xenial,now 1.2.12-11build1 amd64 [installed,automatic]
libsdl-net1.2/xenial,now 1.2.8-4 amd64 [installed,automatic]
libsdl-pango1/xenial,now 0.1.2-6 amd64 [installed,automatic]
libsdl-perl/xenial,now 2.546-2build1 amd64 [installed,automatic]
libsdl-ttf2.0-0/xenial,now 2.0.11-3 amd64 [installed,automatic]
libsdl1.2debian/xenial,now 1.2.15+dfsg1-3 amd64 [installed,automatic]
libsdl2-2.0-0/xenial,now 2.0.4+dfsg1-2ubuntu2 amd64 [installed,automatic]
libsdl2-dev/xenial,now 2.0.4+dfsg1-2ubuntu2 amd64 [installed]
libsdl2-image-2.0-0/xenial-updates,xenial-security,now 2.0.1+dfsg-2+deb9u1build0.16.04.1 amd64 [installed,automatic]
libsdl2-image-dev/xenial-updates,xenial-security,now 2.0.1+dfsg-2+deb9u1build0.16.04.1 amd64 [installed]
libsdl2-ttf-2.0-0/xenial,now 2.0.14+dfsg1-1 amd64 [installed,automatic]


One thing to mention - I do have a few versions of Anaconda on my system; I vaguely recall that at times this can cause some issues, but I found no libsdl2-anything in their package list, so I'm not sure that an accidental selection of the wrong libsdl2 could be caused by that...

Thanks again!
Chuck
Attachments
SuperTux-v0.5.1-1000-ga100d02f0-Source_build_log.txt
(87.77 KiB) Downloaded 20 times
BeanAcres
 
Posts: 7
Joined: 25 Jun 2016, 15:20

Re: Build on Ubuntu 16.04: libtiff4 at build; libGLEW at run

Postby w_laenger » 20 Sep 2018, 16:13

To install new development libraries and other packages on Ubuntu, you can temporarily change the package sources:
Open /etc/apt/sources.list with a text editor with root rights, replace "precise" (16.04) with "cosmic" (the newest 18.10) and save. (this should do the same (untested): sudo sed -i "s/precise/cosmic/g" /etc/apt/sources.list)
Run sudo apt update
Install the packages you need or need to update, e.g. sudo apt install gcc, and try to compile supertux
When every required package is installed or updated, change "cosmic" back to "precise" in the aforementioned file. (e.g.: sudo sed -i "s/cosmic/precise/g" /etc/apt/sources.list)
Edit: Note that this is not recommended, you may accidentally install new versions of packages that you don't want and you could get dependency problems.

This worked for me, before doing it I couldn't compile supertux on Lubuntu 18.04 (I think because of libboost's old version).
Last edited by w_laenger on 22 Sep 2018, 08:53, edited 1 time in total.
w_laenger
 
Posts: 4
Joined: 20 Sep 2018, 15:58

Re: Build on Ubuntu 16.04: libtiff4 at build; libGLEW at run

Postby mteufel » 21 Sep 2018, 11:02

BeanAcres {l Wrote}:One thing to mention - I do have a few versions of Anaconda on my system; I vaguely recall that at times this can cause some issues, but I found no libsdl2-anything in their package list, so I'm not sure that an accidental selection of the wrong libsdl2 could be caused by that...

That is actually the problem since Anaconda installs different, non-Ubuntu-related versions of libtiff.

w_laenger {l Wrote}:To install new development libraries and other packages on Ubuntu, you can temporarily change the package sources: […]

This is terrible advice. First of all, if you don't remember to change it back to the old release, you're upgrading the entire system the next apt system update. Second, apt actually does provide a way to mix releases but using that is actually not recommended either (it can break your system). However, this isn't an Ubuntu support platform.

w_laenger {l Wrote}:I think because of libboost's old version

Our automated builds happily use Trusty's default boost package. We use PPAs for GCC and Clang (https://github.com/SuperTux/supertux/blob/master/.travis.yml#L109-L132).
SuperTux developer
mteufel
 
Posts: 139
Joined: 03 Jan 2016, 09:27

Re: Build on Ubuntu 16.04: libtiff4 at build; libGLEW at run

Postby BeanAcres » 23 Sep 2018, 18:29

Hi all,

Thanks for the inputs - I actually ended up making a "drastic" step which unfortunately won't help answer my original problem - my system was overdue for some updating anyway, so I let the Ubuntu updater update the system to 18.04. Yes, I know this changes the conditions of the original problem :-)

After this I could build the 5.1 source. I haven't yet tried that nightly build I was working with, but I'll get to it.

My daughter is having some troubles trying to learn how to use the new level editor (she's having trouble erasing things), so for now I'm shifting my focus to that. I will have to learn it myself first :-)

Thanks,
Chuck
BeanAcres
 
Posts: 7
Joined: 25 Jun 2016, 15:20

Who is online

Users browsing this forum: No registered users and 1 guest

cron