[00:05:22] --> |Cable| has joined #gemrb
[00:55:03] --> pupnik has joined #gemrb
[01:11:26] <-- pupnik_ has left IRC (Read error: 110 (Connection timed out))
[05:29:24] --> edheldil_ has joined #GemRB
[05:40:03] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[05:40:32] --> Gekz has joined #GemRB
[05:42:17] --> Gekz_ has joined #GemRB
[05:54:19] --> Gekz` has joined #GemRB
[05:54:59] <-- edheldil_ has left IRC (Read error: 110 (Connection timed out))
[05:58:33] <-- Gekz` has left IRC (Read error: 104 (Connection reset by peer))
[05:58:59] --> Gekz` has joined #GemRB
[06:00:36] <-- Gekz has left IRC (Success)
[06:14:04] <-- Gekz_ has left IRC (Read error: 110 (Connection timed out))
[06:52:20] <-- Gekz` has left IRC (Connection reset by peer)
[07:08:48] --> lynxlynxlynx has joined #gemrb
[07:08:48] --- ChanServ gives channel operator status to lynxlynxlynx
[07:17:14] --> Gekz has joined #GemRB
[07:45:35] --> edheldil has joined #GemRB
[08:49:58] <-- |Cable| has left IRC (Remote closed the connection)
[10:49:36] --> barra_library has joined #gemrb
[10:55:00] --> dawid has joined #GemRb
[11:25:17] <Gekz> guys
[11:25:21] <Gekz> tell me when you need a new mingw build
[11:28:22] <lynxlynxlynx> next release ;)
[11:28:44] <Gekz> which is when
[11:28:46] <Gekz> WHEN
[11:28:49] <Gekz> _when_
[11:31:13] <lynxlynxlynx> when there is something to release for
[11:32:06] <lynxlynxlynx> currently we are a bit broken and there's almost nothing new except for the bg1 levelup
[11:32:18] <lynxlynxlynx> feel free to make as many builds as you want though
[11:38:08] <Gekz> I might make a script to do it
[11:38:11] <Gekz> so I dont have to think about it
[11:38:12] <Gekz> lol
[13:13:55] <-- barra_library has left IRC ("Verlassend")
[13:52:25] <-- dawid has left IRC (Read error: 110 (Connection timed out))
[14:47:13] --> barra_library has joined #gemrb
[15:05:22] <-- edheldil has left IRC (Read error: 110 (Connection timed out))
[15:06:32] --> barra_away has joined #gemrb
[15:09:57] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[15:23:15] <-- barra_library has left IRC (Read error: 110 (Connection timed out))
[15:41:59] --- barra_away is now known as barra_home
[17:08:21] --- barra_home is now known as barraAway
[17:53:19] --> |Cable| has joined #gemrb
[18:20:12] --- barraAway is now known as barra_home
[18:32:02] --> edheldil has joined #GemRB
[20:03:35] --> spike411 has joined #GemRB
[20:04:28] <spike411> Hi! I couldn't find any info on the website – has anyone successfully built GemRB for Mac OS X? I'm having trouble with OpenAL (from MacPorts) in particular.
[20:04:41] <fuzzie> yes, using cmake on 10.5
[20:05:41] <fuzzie> i don't think it was done using frameworks from macports though
[20:06:48] <fuzzie> i mean, i think it was done using the frameworks, not the openal from macports.
[20:07:02] <fuzzie> i imagine if you want to do it using macports you're going to have to hack the paths in plugins/OpenALAudio/OpenALAudio.h
[20:07:19] <fuzzie> specifically changing the framework OpenAL/ ones to the non-framework AL/ ones
[20:07:34] <fuzzie> i wonder if we can pass that in a flag from cmake somehow
[20:07:54] <spike411> Ah, yes, I'm having trouble with AL/
[20:08:11] <spike411> So AL/ is hardcoded somewhere, right?
[20:08:24] <spike411> Bad bad thing :)
[20:08:31] <fuzzie> well, if you're compiling with Apple's gcc, it should take the __APPLE_CC__ path and use OpenAL/
[20:10:48] <fuzzie> that is not a very nice way to do it :) but i don't think we have a better one
[20:11:38] <spike411> Dunno, I just ran ./autogen.sh, it complained about missing libtoolize, so I exported LIBTOOLIZE to use glibtoolize, then it complained about missing openal.pc, so I installed openal port, still complained about missing openal.pc, so I created openal.pc which is hopefully correct and points to my OpenAL… but your build system seems to ignore it and still wants it in AL/…
[20:12:13] <spike411> (installing cmake right now, see if it will go any better with this fella)
[20:12:36] <-- tombhadAC has left IRC (Read error: 110 (Connection timed out))
[20:12:46] <fuzzie> and you're using latest svn? that's kind of strange
[20:12:59] <spike411> A few hours old at most.
[20:13:15] <fuzzie> i'd expect the macports openal port to use AL/, really :)
[20:13:32] --> tombhadAC has joined #gemrb
[20:13:39] <spike411> You can't expect anything with FOSS. ;)
[20:13:40] <fuzzie> if i try building the openal plugin on OS X then it definitely tries OpenAL/
[20:14:02] <fuzzie> but i haven't actually tried building the whole thing myself, i don't have the dependencies
[20:14:16] <spike411> Well, dunno, maybe my openal.pc is wrong. Are you familiar with pkg-config?
[20:14:30] * spike411 is not, really, just tried to follow some examples.
[20:14:31] <lynxlynxlynx> cd whatever; lndir OpenAL AL
[20:14:44] <fuzzie> lynxlynxlynx: it's presumably just going to fail later in the process, then
[20:14:46] <spike411> Well, yes, that's an ugly way to do it. :)
[20:15:17] <spike411> (And my includes are in /opt/local/include/openal/)
[20:15:29] <fuzzie> in that case?
[20:16:07] <fuzzie> oh, it's HFS+, i guess
[20:16:11] <fuzzie> horrors :)
[20:16:49] <lynxlynxlynx> openal-soft does provide a pc file btw
[20:17:04] <-- pupnik has left IRC (Read error: 104 (Connection reset by peer))
[20:17:10] <fuzzie> i assume this is a native OS X framework compiled as a library
[20:17:15] <fuzzie> for optimal broken value
[20:17:52] <fuzzie> but i suspect i've misread the above: are you just having problems getting past configure? because our configure itself *is* hardcoded to do AL/ and you should indeed be using cmake if that's where it fails
[20:18:13] <fuzzie> but our configure is basically hardcoded for linux-type environments and falls over completely if you do anything weird
[20:18:17] <spike411> fuzzie: I see. Yeah, I was having trouble getting past configure.
[20:18:48] <spike411> Didn't know I was supposed to use cmake (http://linux.prinas.si/gemrb/doku.php#gnu_linux_and_unix-like <- no cmake there)
[20:19:04] <fuzzie> needs an OS X section i guess :)
[20:19:18] <spike411> Seems so.
[20:19:32] <fuzzie> works on Syllable OS, works on ReactOS, but OS X just has to be weird :(
[20:19:46] <spike411> Well… if it were not for your hardcoded AL/… :)
[20:20:00] <fuzzie> well, if you can fix it, patches accepted
[20:20:39] <spike411> Well it will probably take me OVER 9000 hours, but I could try.
[20:20:42] <fuzzie> but as far as I know, there's no 'nice' way to detect it
[20:20:48] <fuzzie> the standard path is AL/
[20:21:10] <spike411> I see. Well I'm no friends with buildsystems.
[20:21:25] <spike411> Black magic.
[20:22:06] <fuzzie> yes, i'm no friend either, normally lynxlynxlynx tries to maintain ours :)
[20:22:36] <spike411> fuzzie: The ‘nice‘ way to detect it is to use what pkg-config tells you, from what I understood.
[20:22:37] <fuzzie> i guess we don't have any cmake documentation at all
[20:22:59] <fuzzie> spike411: the trouble is, if you have a non-hacked package, pkg-config doesn't tell you anything
[20:23:34] <spike411> Sure, currently openal port does not provide .pc file, but I could try to get it there.
[20:23:37] <fuzzie> because AL/ lives in the default library search path, and so you can just #include <AL/al.h>
[20:24:22] <spike411> I see.
[20:24:22] <fuzzie> so presumably you'd need some kind of hack which detected pkg-config *was* telling you a path, and then set a flag saying "don't use AL, use this other thing instead", and that is far too complicated for my little self already
[20:24:33] <spike411> :)
[20:27:14] <fuzzie> but, yes, i see the macports port copies the files out of AL/ and moves them to OpenAL/
[20:27:48] <fuzzie> i guess the reasoning here is that Apple's framework uses OpenAL/, so the only easy way to detect it is to check for __APPLE_CC__ .. maybe we could just check for that in configure, but i think we probably have more problems
[20:33:22] <spike411> Am I just stupid or what? Does lndir not support relative paths?
[20:34:11] <fuzzie> it's relative to the destination dir
[20:34:54] <spike411> Well, source and destination are in the same directory (where I currently am…)
[20:36:47] <fuzzie> so you have to do "lndir ../source dest"
[20:36:59] <fuzzie> otherwise it looks for dest/source, i have no idea why
[20:37:12] <spike411> Yeah, it's strange.
[20:37:45] <spike411> Thanks, I've found that after some trials and re-reading man page too. :)
[20:38:15] <lynxlynxlynx> protip: use absolute paths when linking
[20:38:50] <lynxlynxlynx> prefixing with $PWD is the fastest way if you're somewhere deep
[20:39:36] <spike411> BTW, is that alright when running cmake? -- Performing Test PERMITS_OBJECT_TO_FUNCTION_CAST - Failed
[20:40:07] <lynxlynxlynx> that's why it is there
[20:40:54] <spike411> Is it? I'm used to all sorts of ‘not so serious fails’ etc. :)
[20:40:56] <lynxlynxlynx> typedef void *(* voidvoid)(void); woah
[20:43:46] <spike411> Today is not my lucky day, I guess http://paste.jabbim.cz/3894
[20:44:23] <-- edheldil has left IRC (Read error: 110 (Connection timed out))
[20:45:33] <lynxlynxlynx> odd, we check for that too
[20:46:56] <lynxlynxlynx> what did the cmake output say about the check?
[20:47:38] <spike411> Oh I see now: -- Looking for strndup - not found
[20:47:49] <spike411> Sorry about that.
[20:50:44] <lynxlynxlynx> it includes the globals.h, which should make things work
[20:52:10] <lynxlynxlynx> hmm
[20:52:19] <fuzzie> yes, that's strange, if it compiles at all then the copy in Core.cpp should be compiled
[20:52:41] <fuzzie> oh, the definitions are different.
[20:52:48] <fuzzie> the header file uses 'unsigned int', the cpp uses 'size_t'.
[20:52:54] <lynxlynxlynx> yeah
[20:53:05] <lynxlynxlynx> on a mac that isn't the same?
[20:53:18] <fuzzie> no idea :) but i would assume so
[20:53:32] <lynxlynxlynx> spike411: gemrb/plugins/Core/Core.cpp:225
[20:53:35] <fuzzie> i assume this is some 64-bit or intel issue
[20:54:16] <fuzzie> apparently it's an 'unsigned long'
[20:59:12] <spike411> I guess I'll try again tomorrow or some other time. >_< :too tired:
[20:59:37] <lynxlynxlynx> tomorrow it will be working
[20:59:47] <lynxlynxlynx> fuzzie: any preference on which one to change?
[20:59:50] <spike411> Yeah :)
[21:00:12] <fuzzie> well, the 'right' change would be the header file to size_t, but then i'd worry about breaking the build?
[21:00:26] <fuzzie> hm, i guess we use size_t all over our header files anyway
[21:01:11] <lynxlynxlynx> doesn't it cast nicely?
[21:01:23] <lynxlynxlynx> spike411: we need your broken system for testing :P
[21:01:36] <spike411> Broken? No way! :p
[21:01:47] <fuzzie> sure, it's just that size_t is the 'proper' definition of the function
[21:01:51] <lynxlynxlynx> gemrb/includes/globals.h:181 change "unsigned int" to size_t and rerun make
[21:01:53] <fuzzie> i don't think functionally it'd make any difference at all
[21:02:16] <spike411> lynxlynxlynx: I guess I should revert Core.cpp:225 then?
[21:02:29] <lynxlynxlynx> yes
[21:02:37] <lynxlynxlynx> that one didn't help? oO
[21:03:13] <spike411> Oh well… it did, kinda. But I got another error. Vorbis-related. ;)
[21:03:52] <lynxlynxlynx> just check this other one, it should get you to the same place
[21:03:54] <fuzzie> you can simply sabotage that plugin if you wish, remove the line from plugins/CMakeLists.txt
[21:03:58] <fuzzie> i mean, the vorbis one
[21:04:30] <fuzzie> do we have any coherent plan for what to fix in gemrb at the moment?
[21:05:46] <lynxlynxlynx> i don't have much time atm, but before i lost it, i was working on adding bg2-style magic resistance
[21:06:16] <lynxlynxlynx> more boring is my plan to see if anything else got broken in the cg
[21:06:32] <lynxlynxlynx> avenger is probably working on bg1 levelup
[21:06:58] <spike411> If you were interested, the Vorbis-related error: http://paste.jabbim.cz/3895 cmake check said only -- Looking for Ogg Vorbis support
[21:07:05] <lynxlynxlynx> i think a nice goal for the next release would be a bg1 runthrough
[21:08:29] <lynxlynxlynx> so it found some vorbis installation, but something is not right
[21:09:05] <spike411> Maybe cmake has some verbose/debug mode?
[21:09:24] <spike411> Seems like the rest built fine.
[21:10:11] <spike411> Maybe CMAKE_VERBOSE_MAKEFILE
[21:10:24] <lynxlynxlynx> you can use make VERBOSE=1337
[21:10:32] <spike411> >___>
[21:11:35] <CIA-22> gemrb: 03lynxlupodian * r7131 10/gemrb/trunk/gemrb/includes/globals.h: sync the strndup fallback parameter type
[21:14:37] --> dawid1 has joined #GemRb
[21:23:35] <fuzzie> i guess cmake doesn't check for vorbis being present or not
[21:24:04] <lynxlynxlynx> it does
[21:24:21] <lynxlynxlynx> FIND_LIBRARY(VORBIS_LIBRARY vorbisfile)
[21:25:02] <fuzzie> ok, where is that? i can't find it in my tree
[21:25:13] <lynxlynxlynx> CMakeLists.txt:80
[21:25:33] <fuzzie> ok, time for a new checkout, i guess. thanks
[21:26:41] <fuzzie> ok
[21:26:44] <fuzzie> i get a VORBIS_LIBRARY
[21:27:13] <fuzzie> but it comes from SDL and is libvorbis, no vorbisfile in sight
[21:28:15] <lynxlynxlynx> VORBIS_LIBRARY:FILEPATH=/usr/lib/libvorbisfile.so
[21:28:26] <fuzzie> so yes, but try removing libvorbisfile and rerunning cmake
[21:28:41] <fuzzie> i mean, maybe this is just some weird issue with my OS X install, it's pretty broken
[21:28:51] <fuzzie> Debian seems to have vorbisfile along with the standard vorbis files
[21:29:33] <spike411> I do have /opt/local/include/vorbis/vorbisfile.h
[21:29:35] <lynxlynxlynx> me too
[21:29:38] <spike411> (from MacPorts)
[21:29:47] <lynxlynxlynx> what about the so?
[21:30:19] <spike411> Well, they are dylibs.
[21:30:30] <fuzzie> that should be fine
[21:30:35] <spike411> In /opt/local/lib/libvorbis*
[21:31:37] <fuzzie> the trouble is that FIND_LIBRARY isn't sufficient, we need a FIND_PATH for the header too, and then include that
[22:19:54] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[23:03:12] <-- dawid1 has left #GemRb ("Leaving.")
[23:26:13] <-- tombhadAC has left IRC ("Verlassend")
[23:35:39] <-- barra_home has left IRC ("Verlassend")