Package Details: libtcod 1.5.1-6

Git Clone URL: https://aur.archlinux.org/libtcod.git (read-only)
Package Base: libtcod
Description: Roguelike graphics/utility library
Upstream URL: https://bitbucket.org/libtcod/libtcod
Licenses: BSD
Submitter: feufochmar
Maintainer: feufochmar
Last Packager: feufochmar
Votes: 23
Popularity: 0.102298
First Submitted: 2012-08-31 18:06
Last Updated: 2015-08-27 18:28

Latest Comments

feufochmar commented on 2015-08-27 18:47

I've changed the source for the bitbucket one.
I've also uploaded a development version of this package or AUR (libtcod-hg).

feufochmar commented on 2015-08-27 17:31

@elimik31: I've unflagged the package out-of-date, since its use is not for indicating a broken or changing source link. Also, as this package builds from sources so it is not affected by the potential problems of the binary versions.
For your suggestion, it's maybe something this package should do, to avoid what happened recently. I'll probably update the package to do this.

elimik31 commented on 2015-08-27 14:10

I marked this package out-of-date, but now I think it probably was a mistake. It was due to the following message on [roguecentral](http://roguecentral.org/doryen/libtcod/):

> This website is no longer the home of libtcod. You can get the source and report issues on bitbucket : https://bitbucket.org/libtcod/libtcod
>
> The forum is still open and will be available as long as needed : forum
>
> The old material is still available but there’s no guaranty that the binary builds will still work with nowadays compilers. You’d better compile the library from the bitbucket sources.

However, the current build on bitbucket is unstable yet and the latest stable build is 1.5.1, which is identical to the one on roguecentral, which is used in this PKGBUILD. However, for the future it would be probably better to compile the source code from the latest stable tag on bitbucket.

elimik31 commented on 2015-08-27 14:09

On roguecentral (http://roguecentral.org/doryen/libtcod/) it says:
I marked this package out-of-date, but now I think it probably was a mistake. It was due to the following message on roguecentral (http://roguecentral.org/doryen/libtcod/):

> This website is no longer the home of libtcod. You can get the source and report issues on bitbucket : https://bitbucket.org/libtcod/libtcod
>
> The forum is still open and will be available as long as needed : forum
>
> The old material is still available but there’s no guaranty that the binary builds will still work with nowadays compilers. You’d better compile the library from the bitbucket sources.

However, the current build on bitbucket is unstable yet and the latest stable build is 1.5.1, which is identical to the one on roguecentral, which is used in this PKGBUILD. However, for the future it would be probably better to compile the source code from the latest stable tag on bitbucket.

feufochmar commented on 2015-05-06 21:30

The website (http://roguecentral.org) is down currently. There is an issue on libtcod bugtracker, I don't know when this will be corrected.
If you go on the old website (http://doryen.eptalys.net) there is a page telling you to go to the new website, but this can be disabled by adding a "?utm_source=twitterfeed&utm_medium=twitter" at the end of every url (don't ask me why, I found that when googling for another link). So you can temporary use the following link to get the source :
http://doryen.eptalys.net/?file_id=26?utm_source=twitterfeed&utm_medium=twitter

I have also uploaded a version of the source package there :
http://feuforeve.fr/vrac/libtcod-1.5.1-linux.tar.gz

I won't change the package right now, as this website issue may just be temporary.

olivil commented on 2015-05-05 14:45

Source link is broken..

Is there any other source for this package?

feufochmar commented on 2014-11-01 18:51

Source link update.

octopositron commented on 2014-11-01 03:53

Marked as out-dated as URL of the source has changed to http://roguecentral.org/doryen/?file_id=26

feufochmar commented on 2013-07-31 16:40

Replaced 'libgl' by 'glu' in dependencies.

magikmw commented on 2013-07-30 15:04

Please add 'glu' as dependency. Without it libtcod won't build.

veox commented on 2012-10-14 22:26

Ah, yes, that was it, not -multilib. :)

feufochmar commented on 2012-10-03 18:11

Thanks tycho. I reproduce the problem when I uncomment MAKEFLAGS (it is commented by default).
I added the option !makeflags to the PKGBUILD to tell makepkg to ignore the variable.

tycho commented on 2012-10-03 10:21

I figured out why it kept doing the "file truncated" nonsense. In my case it was probalistic whether or not it happened. Apparently the libtcod makefiles aren't well-written and don't handle parallel makes very well, so it would try to link against libraries that were not yet fully written to disk. So either add MAKEFLAGS="-j1" to the PKGBUILD or comment MAKEFLAGS in /etc/makepkg.conf.

veox commented on 2012-09-19 21:35

Hmm, binutils just might be it. I'm using the same versions of all packages, but binutils is binutils-multilib.
Don't want to replace it just like that to see, since I need itj pretty often.
I say let's leave it at that.

feufochmar commented on 2012-09-19 10:24

veox : I also use pacman 4.0.3-3 and yaourt 1.1-1 and I don't reproduce your problem.
Your problem seems to be a link problem. You have a problem with ld invoked by collect2. See http://gcc.gnu.org/onlinedocs/gccint/Collect2.html
Can you check that the ld you are using is the one from binutils ?
Also, I'm up to date and using the following packages :
- gcc 4.7.1-6
- binutils 2.22-10
- glibc 2.16.0-4
- linux-api-headers 3.5.1-1

feufochmar commented on 2012-09-19 09:54

I've updated the PKGBUILD to remove the manual extraction of the sources.

veox commented on 2012-09-18 21:31

P.S. Also, you do not need to manually extract the sources.

veox commented on 2012-09-18 21:08

...but the upstream makefile only has the changes you have in your patchfile.

Since this builds for you, and actually for me, too, I'll just dump my procedure here in case someone encounters the same misconfiguration. ;)

To be more specific, I'm using yaourt-1.1-1 here, but this also happens if using makepkg-4.0.3-3 directly.

The error message is (preceded by two lines to build libtcodxx.so and libtcodgui.so):

./libtcod.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make: *** [libtcodxx.so] Error 1
make: *** Waiting for unfinished jobs....
./libtcod.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make: *** [libtcodgui.so] Error 1

libtcod.so file size is 400163 bytes.

I can build it manually, no problem:

cd src/libtcod-1.5.1
make -f makefiles/makefile-linux64 clean release TEMP=$PWD/../tmp

libtcod.so file size is the same.

It is using the 64-bit version makefile, I have verified that.

veox commented on 2012-09-18 20:31

OK, I'll try the upstream makefile now.

feufochmar commented on 2012-09-05 18:01

Strange. I am also on x86_64, and I have no problem to compile it :-/
The source package contains a 32 bit precompiled libs, and has a broken 64 bit makefile (that's why I added a patch). There are two makefile for linux (makefiles/makefile-linux is for 32 bit, makefiles/makefile-linux64 is for 64 bit)
The 64 bit makefile has been corrected upstream in the mercurial repository. Could you try to build the package with the last makefile from the mercurial repository ?
Also, the PKGBUILD do a "make clean release" (and not just a "make release") to force the rebuild.

veox commented on 2012-09-04 16:00

P.S. 64-bit here. Also, I was able to compile 'debug' instead of 'release' without problem.

veox commented on 2012-09-04 12:59

Cannot build. Error message:

./libtcod.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make: *** [libtcodxx.so] Error 1
make: *** Waiting for unfinished jobs....
./libtcod.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make: *** [libtcodgui.so] Error 1

libtcod.so is built, present in $srcdir/libtcod-1.5.1, size 400163.

I was able to build this package by manually issuing the make command, with a little voodoo. So I guess this might be a PKGBUILD/Makefile/path issue.