Compilation problem.

A free software implementation of Prince of Persia 1.

Moderator: English Moderator Team

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 205
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: Compilation problem.

Post by oitofelix » March 10th, 2017, 5:26 pm

Giorgos wrote:In case you prefer another debugger, or giving any advanced commands, just tell me.
Thanks for the report. However, it only shows the specific location of the crash (for which no debugging symbols are available). Could you please issue a "bt" command to get a backtrace right after the crash?

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Giorgos
Efendi
Efendi
Posts: 15
Joined: May 29th, 2016, 1:58 am

Re: Compilation problem.

Post by Giorgos » March 10th, 2017, 5:50 pm

oitofelix wrote: Could you please issue a "bt" command to get a backtrace right after the crash?
Of course! ;)
Giving "bt", returns this:

Code: Select all

(gdb) bt
#0  0x00007fffe9590034 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#1  0x00007fffe958d573 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#2  0x00007fffe95d54a3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#3  0x00007fffe95ea17b in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#4  0x00007fffe8af0d88 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#5  0x00007fffe8ae34b4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#6  0x00007fffe8ae41d0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#7  0x00007fffe8ae45c3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#8  0x00007fffe8a6ae67 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#9  0x00007fffe8a8d544 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#10 0x00007fffe83c5c7a in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#11 0x00007fffe837587b in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#12 0x00007fffe818f99b in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#13 0x00007fffe79d19c3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#14 0x00007fffe79d1b4d in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#15 0x00007fffe79d1c2d in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#16 0x00007fffe77fc40c in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#17 0x00007fffe7934222 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#18 0x00007fffe869e332 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#19 0x00007fffe86b1d9e in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#20 0x00007fffe868a15c in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#21 0x00007fffe86b2a97 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#22 0x00007fffe869b93e in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#23 0x00007fffe869ba66 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#24 0x00007fffe959600b in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#25 0x00007fffe9407059 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#26 0x00007fffe774f612 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#27 0x00007fffffffe030 in ?? ()
#28 0x00007fffe95f9281 in ?? () from /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so
#29 0x00007fffffffe030 in ?? ()
#30 0x00007ffff7deafe8 in _dl_fini () at dl-fini.c:257
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
And now :?:
I grow old, ever learning many things. Solon.

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 205
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: Compilation problem.

Post by oitofelix » March 10th, 2017, 6:19 pm

Giorgos wrote:Of course! ;)
Thanks! :)
Giorgos wrote:Giving "bt", returns this: [...]
As GDB says, it seems the stack has been corrupted, what makes the backtrace useless.
Giorgos wrote:And now :?:
How are you exiting MININIM? Sending a SIGINT (Ctrl+C at its terminal REPL)? Pressing Ctrl+Q? Closing its window?

Are you familiar with GDB and debugging in general? Just before you exit MININIM, could you set a breakpoint at the end of function 'play_anim' and step from there until you reach the segmentation fault and then post the gdb.txt log file here?

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Giorgos
Efendi
Efendi
Posts: 15
Joined: May 29th, 2016, 1:58 am

Re: Compilation problem.

Post by Giorgos » March 10th, 2017, 6:40 pm

oitofelix wrote:Pressing Ctrl+Q?
Yes. Pressing ^Q from inside the game (while fullscreen).
oitofelix wrote: Are you familiar with GDB and debugging in general?
Ehm...well...so and so!
I'm familiar with simple tasks with gdb (I was using it at scummvm testing), but that was long ago and I never was an expert of any kind with gdb. :lol:
oitofelix wrote:Just before you exit MININIM, could you set a breakpoint at the end of function 'play_anim' and step from there until you reach the segmentation fault and then post the gdb.txt log file here?
Let me take a look at the documentation and I'll be back! :)
I grow old, ever learning many things. Solon.

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 205
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: Compilation problem.

Post by oitofelix » March 10th, 2017, 7:05 pm

Giorgos wrote:I'm familiar with simple tasks with gdb (I was using it at scummvm testing), but that was long ago and I never was an expert of any kind with gdb. :lol:
Great! MININIM doesn't require more than that. ;)
Giorgos wrote:Let me take a look at the documentation and I'll be back! :)
Thanks!

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3200
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: Compilation problem.

Post by Norbert » January 10th, 2018, 3:15 am

oitofelix wrote:
March 9th, 2017, 8:14 pm
Norbert wrote: then if I run the program it says:
-----
./mininim: error while loading shared libraries: liballegro.so.5.2: cannot open shared object file: No such file or directory
-----

I could probably figure out what the problem is there (maybe a symbolic link would fix it), but I'm busy with other things.
Perhaps that's because you have your distribution's Allegro installed alongside MININIM's fork. Try

Code: Select all

sudo apt-get remove liballegro5-dev liballegro-image5-dev \
  liballegro-audio5-dev liballegro-acodec5-dev liballegro-dialog5-dev
Then don't forget to run

Code: Select all

sudo ldconfig
.
It took me a while, but I've now tried this.
It doesn't fix the problem.
oitofelix wrote:
March 9th, 2017, 8:14 pm
Norbert wrote:Regardless, if we both can't make it work out of the box with the available instructions, it needs work.
Well, there are an infinitude of possible configurations for GNU/Linux systems out there. This is life when it comes to building software. I can't possibly foresee every possible corner case in which the build procedure can fail. As experience shows, build recipes are just general guidance to point people committed to the task of building from source to the right direction at best. There is absolutely no guarantee, implicit or otherwise, that they will work for you out of the box if you follow them rigorously. You should just consider yourself lucky, in case they do. That's not to say however that I won't help users building MININIM or that MININIM's building documentation can't be improved.
I may disagree with your stance here. I normally don't run into the kind of problems that I run into with MININIM when manually compiling packages. While there are a lot of possible configurations for GNU/Linux systems, my Mint installation is fairly standard, and the distro is part of the prominent group of Debian/Ubuntu-based systems; even relies on Ubuntu's repositories. I don't think your statement that you "can't possibly foresee every possible corner case" is applicable in this instance; also, I wouldn't ask (or expect) you to. My experience with manually compiling packages is not that one "should just consider yourself lucky, in case [instructions/building work(s)]". If I can't simply follow the instructions, even for a huge package such as Wine, then I'm unlucky.

There's something I've been meaning to ask you. The page at GitHub about the 201701051749 release says "oitofelix released this on Dec 28, 2016". I can imagine you decided to push out this release earlier than expected, but I'm wondering why the version number that includes datetime 2017-01-05_17:49 wasn't changed to match the release date.

Anyway, today I wanted to test the legitimacy of the uploaded MININIM replays I linked to here, saw you made some replay related commits on January 5th of 2017, and therefore opted to manually compile a recent MININIM. (Also, the Windows version crashes in my Wine.)

I decided to clone Allegro. Following MININIM's documentation, I tried...

Code: Select all

$ sudo apt-get build-dep allegro5
Reading package lists... Done
E: Unable to find a source package for allegro5
...which failed; as did cmake and make:

Code: Select all

$ cmake
Usage

  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

Specify a source directory to (re-)generate a build system for it in the
current working directory.  Specify an existing build directory to
re-generate its build system.

Run 'cmake --help' for more information.

$ make
make: *** No targets specified and no makefile found.  Stop.
I made progress with...

Code: Select all

mkdir build
cd build
cmake ..
make
...and (thus) later "cd ../..".

MININIM compiled, but, unfortunately, I ran into the same shared library error as I did in March:

Code: Select all

$ ./mininim 
./mininim: error while loading shared libraries: liballegro.so.5.2: cannot open shared object file: No such file or directory
I decided to run...

Code: Select all

$ sudo xargs rm < allegro5/build/install_manifest.txt
$ sudo apt-get install liballegro5-dev
...and tried both 201701122309 and the bleeding edge master. Configure ended with:

Code: Select all

[...]
checking for ALLEGRO... no
checking for ALLEGRO... yes
checking for ALLEGRO_IMAGE... no
checking for ALLEGRO_IMAGE... no
configure: error: MININIM requires Allegro 5.0.9 (or superior) image addon
(Strange that it mentions both ALLEGRO and ALLEGRO_IMAGE twice, with the former saying "no" and then "yes".)
I have a suggestion here. I started checking...

Code: Select all

$ sudo dpkg -s liballegro5-dev|grep Version
Version: 2:5.0.11-2
...because the error message appears to address "Allegro 5.0.9".
The suggestion is to modify configure.ac to use:

Code: Select all

AC_MSG_ERROR([MININIM requires Allegro-image $allegro_minver (or superior)]))])
instead of:

Code: Select all

AC_MSG_ERROR([MININIM requires Allegro $allegro_minver (or superior) image addon]))])
The same goes for the messages about Allegro-audio, Allegro-acodec and Allegro-dialog.

But yeah, now make says ALLEGRO_MENU and such are unknown.
Oh well, 2.15am local time. Time for bed. :P

Post Reply