espes
-
Posts
15 -
Joined
-
Last visited
Posts posted by espes
-
-
http://trac.wildfiregames.com/browser/ps/t...shes/structural
It looks like your SVN checkout didn't complete.
-
Sorry to be condescending, but you're meant to be "good at C++". If you google'd the error, you would find hundreds of posts related to the problem; on OS X, malloc.h in in a different location. Modify ilur.c to include "sys/malloc.h".
-
Take that up with the Valgrind people, it's not yet completely compatible with OS X. You don't need it, anyway.
Also,
Take care that libdevil 1.6.8-rc2 (the version in macports) is not compatible with GCC 4.3, you'll need to install 1.7.8. Get it from http://openil.sourceforge.net/download.php. Then extract the archive, and run ./configure --enable-ILU --enable-ILUT, make, and sudo make install. -
See http://trac.wildfiregames.com/ticket/265
/**
* LIBXML_THREAD_ENABLED:
*
* Whether the thread support is configured in
*/
#if 1
#if defined(_REENTRANT) || defined(__MT__) || \
(defined(_POSIX_C_SOURCE) && (_POSIX_C_SOURCE - 0 >= 199506L))
#define LIBXML_THREAD_ENABLED
#endif
#endif -
It's not so much freezing as just not accepting any input or updating the window. I think it's still running underneath.
-
I'm curious whether Atlas works on Mac when compiled with gcc 4.3. It used to have problems caused by wxwidgets. If you run pyrogenesis_dbg -editor, does it start up and can you interact with it?
It's pretty broken for me. It completely freezes up upon launch
-
It's a bug in Apple's OpenAL.
You could try upgrading OpenAL. I worked around it by including a modified header.
-
I think the libdevil sources included are meant for windows.
I suppose the most of the included libraries could be made to be built and used. Why not? They're already there for Windows.
-
Wow, your patch set's quite bigger than mine.
I'll do a write-up tomorrow afternoon along with macports portfiles and binaries (It's a bad idea to install things without package management, and I patched spidermonkey and libDevIL instead of working around them)
Oh, and somebody start a ticket regarding valgrind. It should be optional.
-
Make a diff and open up a ticket. I don't know how active devs are on this forum.
-
It's delightful to see 0 A.D. running on OSX - congratulations!
I've hopefully fixed the snd_mgr trouble (OpenAL's ALC string types differ between platforms, ugh). Please PM me if it's still broken (unfortunately I can only test on Windows).
Since I don't seem to have the privileges to PM you, yeah... snd_mgr was working fine, the fix broke it for me.
../../../source/lib/res/sound/snd_mgr.cpp: In function 'LibError alc_init()':
../../../source/lib/res/sound/snd_mgr.cpp:259: error: invalid conversion from 'ALCubyte*' to 'const ALCchar*'
../../../source/lib/res/sound/snd_mgr.cpp:259: error: initializing argument 1 of 'ALCdevice* alcOpenDevice(const ALCchar*)'
../../../source/lib/res/sound/snd_mgr.cpp: In function 'LibError snd_dev_prepare_enum()':
../../../source/lib/res/sound/snd_mgr.cpp:689: error: invalid conversion from 'ALCubyte*' to 'const ALCchar*'
../../../source/lib/res/sound/snd_mgr.cpp:689: error: initializing argument 2 of 'ALCboolean alcIsExtensionPresent(ALCdevice*, const ALCchar*)'
make[1]: *** [obj/lowlevel_Debug/snd_mgr.o] Error 1ALC's strings may differ between different distros of OpenAL, not just the Mac build (I'm just using the default Mac version, and it uses ALCchar's)
...
Yeah, the ALC from macports uses ALubyte's, it's probably a version thing.
..
Yeah, it was supposed to change from ALCubyte's to ALCchar's with the version 1.1 headers, though they both identify themselves as 1.1 >:-(
...
nevermind, I created a ticket
-
I don't mean to be a bother, but could you post the pasteit of your il.h ? It'd just be easier than going through the diff.
uhh... apply the diff? You don't have to go through it...
Great! thank you so much for the link. I found it, installed and it works properly.
It's dirty install things without package managements. Rather, throw together a quick macports Portfile
# $Id$
PortSystem 1.0
name enet
version 1.2
categories net
maintainers foobar
description UDP network communication layer
long_description ENet is a thin, simple and robust network communication layer on top of UDP featuring optional reliable, in-order delivery of packets.
homepage http://enet.bespin.org
platforms darwin
master_sites http://enet.bespin.org/download/
distfiles enet-1.2.tar.gz
checksums enet-1.2.tar.gz \
md5 e0d9f468d8c6f6bfd07083b3b40f5e69 \
sha1 8da3d1665e64b9f037a3e4d48d3477a846ba44e7 \
rmd160 1b68ceb791eecfeebb99762f334eacac2461eb19 \
use_autoconf yes
build.targetI suspect it has something to do with spider monkey? What do you guys think?
Like I said before, "there's a typedef conflict with spidermonkey, you'll need to patch up jsotypes.h later."
I modified my jsotypes.h to read:
#ifndef _UINT64
typedef JSUint64 uint64;
#define _UINT64
#endifThat's what I did, but now that I think about it, there's probably a better way to fix it.
What do we think about this error?
No idea, that didn't happen to me. :\
-
Oh, and it turns out that libxml2 was compiling right, the crash was just a FCollada assertion failure that was breaking (since I removed the CoreServices debugger call earlier as it was creating a undefined symbol for some reason). I commented out the sigtrap, and yay.
-
You need libDevIL. Though there's a issue in the 1.6.8 version, I had to frankenstein together 1.6.8 and 1.7.0 includes to get it working.
Also, there's a typedef conflict with spidermonkey, you'll need to patch up jsotypes.h later.
It's compiling and launching for me (with a bunch of edits, here's my diff)
My problem now is that I cannot get libxml2 working with threading. I compile it with "--enable-threads", but "LIBXML_THREAD_ENABLED" is still not set, and it crashes and burns when starting a game. Anyone have any ideas?
OSX Build Error **solved**
in Game Development & Technical Discussion
Posted
Wasn't this going to be solved by having a spidermonkey tree compiled with the game?