#exult@irc.freenode.net logs for 31 Jan 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:10:52] <Dominus> Grrrrrrr.... Eviltar .......grrrrrr...... wasting time on trying to build it for wii....
[00:16:59] <Eviltar> is the build target for wii also powerpc-none? also a tip, unless you're building on a ppc machine, build for unix x86 and take the tool binaries and make them read-only
[00:18:57] <Eviltar> in case you need it https://github.com/randprint/libglob
[00:19:38] <Eviltar> that should be easy to change the makefile for wii
[00:20:57] <Eviltar> but the wii toolchain might already cover those functions, i dunno I've never used it
[00:24:29] <Dominus> it's powerpc-eliab or so.
[00:24:55] <Dominus> problems with SDL-WII since those guys seem to fear anything that needs .configure...
[00:25:08] <Dominus> crippling the toolchain this way :(
[00:25:41] <Eviltar> yeah it was a little ugly getting SDL to configure right for our toolchain too, it's been the effort of a few people to have a nice SDL port now
[00:26:02] <Eviltar> maybe wiibrew needs to port our build
[00:27:20] <Eviltar> admittidly we abuse the usr/local folder for our libs but they all are found by .confgure correctly
[00:42:42] <Dominus> phew. instead of fiddling with this I tried building exult from outside the src folder and found I need to edit some makefile.am files (so far timidity and mt32emu)
[00:43:59] <Dominus> actually those are the only ones :)
[00:49:10] <Dominus> hmm, and the data files are not being done in the external folder...
[00:58:57] <-- SHODAN has left IRC (Quit: No Ping reply in 180 seconds.)
[00:59:05] --> SHODAN has joined #exult
[02:38:53] <-- Guest25591 has left IRC (Remote host closed the connection)
[02:38:54] <-- nutron has left IRC (Remote host closed the connection)
[02:54:20] <-- Dominus has left IRC (Read error: Connection reset by peer)
[02:54:31] --> Dominus has joined #exult
[02:54:31] --- ChanServ gives channel operator status to Dominus
[04:19:56] --> nutron has joined #exult
[08:33:36] <-- Kirben has left IRC (Ping timeout: 256 seconds)
[08:33:40] --> Kirben_ has joined #exult
[08:33:40] --- ChanServ gives channel operator status to Kirben_
[09:36:00] <-- sh4rm4 has left IRC (Ping timeout: 276 seconds)
[09:38:56] --> sh4rm4 has joined #exult
[10:43:51] <Dominus> wjp, to configure and make Exult outside of the source folder, there are just two real hurdles (except for timidity and mt32-emu makefile.am)
[10:44:27] <Dominus> 1. in autogen.sh, it needs
[10:44:29] <Dominus> srcdir=`dirname $0`
[10:44:29] <Dominus> test -z "$srcdir" && srcdir=.
[10:44:29] <Dominus> cd "$srcdir"
[10:45:05] <Dominus> 2. the data is not made in the external folder but in the source dir/data folder, no idea hwat to do about that
[10:47:43] <Dominus> oh and usecode compiler also doesn't like to be built elsewhere
[10:56:15] <Dominus> so for the autogen.sh change, I need help in how it should look and for both the data and ucc problem, I have no clue
[11:02:04] <Dominus> if we actually want to support building outside of the source :)
[12:43:52] <-- Kirben_ has left IRC ()
[12:58:25] --> TheCycoONE has joined #exult
[15:58:57] <Marzo> Hm. I am thinking: we already have wud and ucxt as usecode disassembly tools; is there any reason to keep ucdump around?
[15:59:32] <Marzo> (especially since the other two are much more up-to-date regarding everything that has been found, and are better integrated with Exult)
[16:00:28] <Marzo> In fact, ucdump seems to be a precursos to wud
[16:38:32] <Marzo> In fact, it seems that ucxt was made with the intent of deprecating ucdump
[16:39:07] --> Malignant_Manor has joined #exult
[16:39:39] <Malignant_Manor> Marzo: I've really doubt I have even used ucdump.
[16:40:24] <Marzo> I haven't used it, even though I used rip/wud/wuc to add custom usecode into the original for testing
[16:40:39] <Marzo> It is entirely redundant
[16:40:51] <Malignant_Manor> Mingw doesn't incude it in the build.
[16:41:10] <Marzo> And it is hacked into automake builds too
[16:42:32] <Marzo> Malignant_Manor: can you do me a favor and check if this patch (http://pastebin.com/y6rb222u) builds on Windows, and send me the warnings it prints (same conditions)
[16:44:00] <Marzo> Also: what version of GCC are you using in MinGW, and is there, and does Exult build correctly if you add -DHAVE_TR1_UNORDERED_MAP to CPPFLAGS in Makefile.mingw?
[16:44:57] <Malignant_Manor> I think my GCC is the latest stable.
[16:46:55] <Malignant_Manor> gcc version 4.7.0 (GCC)
[16:48:02] <Marzo> So it should probably build with -DHAVE_TR1_UNORDERED_MAP
[16:48:32] <Malignant_Manor> Is there a way to test if there is TR1_UNORDERED_MAP for old versions?
[16:48:44] <Malignant_Manor> There's probably not much reason for it though.
[16:49:49] <Marzo> I am just lookin for it
[16:50:29] <Marzo> And it seems that all GCC versions 4.3 and up should use either the TR1 unordered map or C++0x unordered map
[16:54:41] <Marzo> Comfirmed: GCC 4.3 and up deprecate ext/hash_set and ext/hash_map in favor of tr1/unordered_set and tr1/unordered_map
[16:55:39] <Marzo> So the check for HAVE_TR1_UNORDERED_MAP as well as GCC 4.3 and up in hash_utils.h is entirely redundant
[16:56:02] <Marzo> (and for HAVE_TR1_UNORDERED_SET on the same vein)
[16:56:20] <Malignant_Manor> The release date was March 5, 2008.
[16:57:07] <Marzo> I know
[16:58:24] <Marzo> By the way: it is -DHAVE_TR1_UNORDERED_MAP -DHAVE_TR1_UNORDERED_SET that should be added to Makefile.mingw
[16:58:48] <Malignant_Manor> Alright, I will start again.
[16:59:00] <Malignant_Manor> It looks like the check is already there.
[16:59:19] <Marzo> I think I will change the conditions in hash_utils.h to check for GCC 4.3 OR HAVE_TR1_UNORDERED_XXX instead of AND
[16:59:35] <Marzo> That way, other compilers can also benefit
[17:22:41] <Malignant_Manor> I could build Exult fine. It sure cuts down on the size of the warning file.
[17:23:49] <Marzo> After you build ES and tools, we will see if we can debug the issue with libsmooth
[17:24:41] <Malignant_Manor> I have no idea. My install is a mess because of messing with Clang (which didn't link correctly).
[17:25:16] <Marzo> By the way: you can probably cut down on build times by passing "-j N" in the make command-line (with N is the number of simultaneous commands to execute, preferably equal to or less than the number of processor cores)
[17:26:07] <Malignant_Manor> This is a P4. I don't think I have hyperthreading.
[17:26:32] <Malignant_Manor> I used to run extra jobs but ran into issues awhile ago.
[17:26:52] <Marzo> Ah, OK
[17:27:10] <Malignant_Manor> Exult is just horrible anymore on building.
[17:28:27] <Malignant_Manor> The compiler uses all the cpu so I wouldn't think adding that would matter anyway.
[17:35:07] <Malignant_Manor> I'm off two minor versions on GCC. By my install date, I should only be off by one (if MinGW had the same release date). I will go about installing the new GCC version.
[17:36:35] <Marzo> Dominus: you here?
[18:15:11] <Malignant_Manor> The current Exult SDL download seems to be for installing to MINGW instead of the Exult folder.
[18:26:00] <Dominus> hey Marzo, I am now for a little bit
[18:26:29] <Dominus> Malignant_Manor: the Exult SDL download was always for mingw not Exult folder (which is the correct way)
[18:27:07] <Malignant_Manor> I'm pretty sure that it was always for the Exult folder.
[18:27:14] <Marzo> Actually, I think it was for putting in the Exult source dir
[18:27:30] <Malignant_Manor> That was per the outdated instructions.
[18:27:47] <Malignant_Manor> The MINGW/MSYS directions need reworked.
[18:28:01] <Marzo> See the 'install' target in Makefile.mingw
[18:28:09] <Marzo> cp SDL/lib/SDL.dll $(U7PATH)
[18:28:38] <Dominus> ah, yes, I see the Readme.win32 instructions now
[18:28:40] <Malignant_Manor> I still have the libsmooth_randomize.dll error.
[18:28:42] <Marzo> Also 'debug', 'dist'
[18:29:05] <Dominus> I think I never bothered much with this since I rollde my own SDL built back then
[18:29:28] <Malignant_Manor> I'll have to see if I have the Exult Studio crash issue that we fixed earlier.
[18:30:12] <Dominus> Malignant_Manor: feel free to correct the instructions. I'm glad that I don't have to bother with Mingw/msys hell anymore (though I think that got better)
[18:30:55] <Dominus> otoh I'm burdened with Apple's gcc/llvm-gcc/clang that is loosely based on gcc 4.2 :)
[18:31:42] <Marzo> Dominus: I will give you something for you to test and see if it works
[18:32:27] <Marzo> But first: open config.h and find the following variables: HAVE_EXT_HASH_MAP, HAVE_EXT_HASH_SET, HAVE_HASH_MAP, HAVE_HASH_SET, HAVE_TR1_UNORDERED_MAP, HAVE_TR1_UNORDERED_SET
[18:32:42] <Marzo> Put their lines here
[18:33:14] <Marzo> (bonus points if you do for both clang and GCC)
[18:33:21] <Marzo> :-p
[18:34:31] <Dominus> does a little built without studio suffice?
[18:34:50] <Marzo> Yes
[18:35:20] <Marzo> Actually, just running ./configure, make and aborting as soon as it starts compiling anything is enough to update config.h
[18:36:03] <Dominus> #define HAVE_EXT_HASH_MAP 1
[18:36:26] <Dominus> HAVE_EXT_HASH_SET 1
[18:37:03] <Marzo> And nothing for the others?
[18:37:13] <Dominus> /* #undef HAVE_HASH_MAP */
[18:37:17] <Malignant_Manor> Exult Studio crashes.
[18:37:27] <Dominus> /* #undef HAVE_HASH_SET */
[18:37:47] <Dominus> #define HAVE_TR1_UNORDERED_MAP 1
[18:37:55] <wjp> ./configure should generate config.h itself
[18:37:56] <Dominus> #define HAVE_TR1_UNORDERED_SET 1
[18:38:06] <Dominus> that was with clang
[18:40:13] <Dominus> with llvm-gcc everything is undef
[18:40:28] <Marzo> Weird
[18:41:44] <Dominus> I built against old SDKs to be more compatible
[18:41:57] <Dominus> maybe that plays a part
[18:43:51] <Dominus> and the old llvm-gcc I'm using for building ppc has all defined except for HAVE_HASH_MAP
[18:44:07] <wjp> hm, our use of those predates OS X, so that's a bit surprising
[18:45:17] <Marzo> I find it weird because compile should be failing with llvm-gcc if everything is undef
[18:45:47] <Dominus> I think it was about to fail, when I look at whenI stopped it
[18:46:03] <Marzo> hash_utils.h should be trying to include <hash_map> and failing, as ./configure didn't find it
[18:46:04] <wjp> but can't msys just run configure nowadays?
[18:46:19] <wjp> with a bit of luck there's no need for a specific mingw Makefile at all
[18:46:20] <Dominus> msys could run configure for years now
[18:46:43] <Marzo> I think the last time I tried, there were conflicting stuff that I had no idea how to fix
[18:46:50] <Marzo> I could try my hand at it now
[18:46:51] <Dominus> I used to build the needed libs and dosbox via configure
[18:47:06] <Marzo> (conflicting stuff in Exult, I mean)
[18:47:20] <Marzo> I would just have to setup a msys dev environment
[18:47:26] <Marzo> (in a virtual machine)
[18:47:37] <Dominus> but back then mingw/msys didnT play well at times and acting up with the wrong combination :)
[18:47:45] <Marzo> In any case, I am asking stuff about Mac OS X to Dominus
[18:49:25] <Marzo> Dominus: can you check to make sure Exult builds in llvm-gcc?
[18:49:48] <Marzo> (the one in which every variable I asked about was undef in)
[18:49:58] <Dominus> in a while got to run. it compiled against sdk 10.8 (when you asked for the warnings)
[18:50:30] <Marzo> Hm
[18:51:12] <Dominus> and no it doesn't compile against sdk 10.6
[18:51:16] <Dominus> bbl
[18:51:21] <Marzo> Aha
[19:27:33] <Marzo> Malignant_Manor: can you check if this new version still compiles? http://pastebin.com/wqCEGkxd
[19:27:59] <Marzo> This should be the last one; after this, we can try to see why libsmooth is failing to link
[19:28:03] <Marzo> (in MinGW)
[19:29:03] <Malignant_Manor> In a minute
[19:29:31] <Malignant_Manor> The sdl issue was I had sdl 1.5 that I had compiled myself.
[19:30:01] <Marzo> Ah, so this is why it was failing?
[19:30:03] <Malignant_Manor> (Not the libsmooth one. The SDL bing for a MINGW install
[19:30:26] <Marzo> Oh, you mean the ES crash
[19:31:15] <Malignant_Manor> No, [18:15:11] <Malignant_Manor> The current Exult SDL download seems to be for installing to MINGW instead of the Exult folder.
[19:31:50] <Marzo> Ah
[19:33:37] <Malignant_Manor> Actually, yes on libsmooth
[19:35:44] <Marzo> So it was failing because of this?
[19:35:57] <Marzo> If so, I'd love the full warnings file for the tools
[19:36:01] <Malignant_Manor> Unless it was because of something else I was messing with.
[19:36:05] <Marzo> (just in case)
[19:36:38] <Malignant_Manor> I was messing with installing autoconfig, etc
[19:41:40] <Malignant_Manor> libxml is still from 2004 and that is what was causing the crash before.
[19:42:44] <Marzo> Didn't you replace it already?
[19:43:01] <Malignant_Manor> I reinstalled GCC
[19:44:16] <Marzo> Ah
[19:52:28] <Marzo> Thanks
[19:57:13] <Marzo> OK, so all the non-WinAPI old-style casts are gone except for ES; time now to tackle ES
[19:57:17] <Marzo> Will commit the changes
[19:57:32] <Marzo> (after carefully double-checking everything)
[20:08:36] <Marzo> wjp: what is your opinion on removing ucdump as being a redundant tool? We already have wud and ucxt for that purpose, both of which are much less outdated than ucdump
[20:14:42] <wjp> no objections
[20:15:42] <Marzo> Will make the necessary changes then
[21:28:19] <Dominus> marzo, it seems you broke my ppc built
[21:28:49] <Marzo> Leave it in the logs; I am going out right now, and will be back in a couple of hours or so
[21:28:57] <Marzo> (the error message, I mean)
[21:29:04] <Dominus> http://pastebin.com/2Si5YUCN
[21:29:12] <Dominus> have fun :)
[21:29:38] <Marzo> Can you also post the output of ./configure?
[21:29:49] <Dominus> yup, will do
[21:30:16] <Dominus> will have to do it again, since I made configure quiet :)
[21:32:22] <Marzo> "/usr/include/c++/4.2.1/tr1/hashtable" Hm. I think I have an idea
[21:33:44] <Marzo> In hash_utils.h line 29: replace it by
[21:33:45] <Marzo> # if defined(HAVE_TR1_UNORDERED_MAP) && defined(__GNUC__) && (__GNUC__ >= 4) && ( __GNUC_MINOR__ >= 3)
[21:34:04] <Marzo> And similar for line 53
[21:34:47] <Marzo> And in configure.ac lines 236 and 237, delete the "[break]"
[21:35:19] <Marzo> (You may have to put "[]" instead)
[21:38:47] <Dominus> Marzo: that worked
[21:38:57] <Dominus> compile went through to the end and linked
[21:39:39] <Marzo> Go ahead and commit it after testing also in llvm-gcc
[21:39:48] <-- Colourless has left IRC (Ping timeout: 276 seconds)
[21:39:50] <Dominus> will do
[21:40:04] <Dominus> thanks
[21:40:30] <Marzo> I am making UCXT's output compatible with WUC, and will be eliminating ucdump as entirely redundant
[21:40:45] <Marzo> Maybe even wud will go the way of the dodo
[21:41:00] <Marzo> But that is for when I get back
[21:41:10] <Dominus> kill kill kill
[21:43:31] <Dominus> hmm, llvm-gcc still doesn't work for 64bit build and SDK 10.6 - will investigate this looks more like an apple problem or me making odd stuff
[21:45:20] --> Colourless has joined #exult
[21:45:21] <-- Colourless has left IRC (Changing host)
[21:45:21] --> Colourless has joined #exult
[21:45:21] --- ChanServ gives channel operator status to Colourless
[21:45:29] <Malignant_Manor> Is WUC a usecode compiler? I'ved never used it.
[21:45:39] <Marzo> It is a usecode assembler
[21:45:53] <Malignant_Manor> There's no documentation that I see.
[21:46:49] <Malignant_Manor> The only people who know about it are probably the only ones who will use it.
[21:47:22] <Marzo> Which is good
[21:47:45] <Dominus> marzo, don't worry about my other llvm-gcc problem, seems Apple broke compiling with new llvm-gcc against old SDKs
[21:47:49] <Malignant_Manor> It's basically no one using it.
[21:47:59] <Dominus> with old llvm-gcc it works fine
[21:48:06] <Marzo> I have been thinking of doing a usecode disassembler that does basic block analysis and data synthesis to generate UCC-compatible working usecode
[21:48:35] <Marzo> s/disassembler/decompiler
[21:48:36] <Dominus> as for killing those old tools, it's actually good to get rid of them since from time to time people show up that tried to use them instead of the new tools
[21:48:56] <Marzo> When I do that, and when I add a original-compatible mode for UCC, even wuc can go the way of the dodo
[21:49:15] <Malignant_Manor> So it will have output like UCXT but without the attend crap.
[21:49:26] <Marzo> Yes
[21:49:49] <Marzo> I intend it to be like my old VB program of the same purpose, but much, much better
[21:50:28] <Marzo> Been thinking and writing a few stuff over the past few years, so I know I can do it
[21:50:41] <Marzo> Just have to stop procrastinating...
[21:50:46] <Marzo> Anyway, be back later
[21:50:56] <Dominus> see you
[21:52:37] <Dominus> Malignant_Manor: I'm going to be absent from saturday until friday next week. I appoint you beta tester and release manager in the meantime!!!
[21:53:03] <Malignant_Manor> So nothing will get done
[21:53:21] <Dominus> aw, I have full confidence in you!
[21:54:41] <Malignant_Manor> I don't really feel like playing through Ultima 7
[21:55:25] <Dominus> :)
[22:05:24] <Dominus> Blitzgeruest!
[22:05:34] <Dominus> oh, sorry, wrong window
[22:19:21] <Dominus> Marzo: with llvm-gcc 32bit with SDK 10.8 http://pastebin.com/PKhXyqNG
[22:19:23] <Dominus> error
[22:20:37] <Dominus> (actually 64bit)
[22:24:47] <Dominus> clang still compiles fine
[22:26:31] <Dominus> except for these warnings in ucdisasm and newfile_gump http://pastebin.com/hWPgqzD8
[22:28:16] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[22:34:37] <Dominus> 32bit clang works fine, too (32bit llvm same error as above - no surprise) except for two warnings about ENDIANes in timidity and mt32emu
[22:34:38] <Dominus> http://pastebin.com/FhHtXUj8
[22:47:20] --> Kirben has joined #exult
[22:47:21] --- ChanServ gives channel operator status to Kirben
[22:49:45] <Malignant_Manor> Kirben: There seems to be a crash in Exult Studio because of libxml2 being outdated in exult_dev_win32.zip.
[22:54:07] <Malignant_Manor> Updating it with http://lrn.no-ip.info/other/mingw/mingw32/libxml2/2.8.0-2/ causes dependencies on libz-1.dll, liblzma-5.dll, and libxml2-2.dll
[22:55:30] <-- sh4rm4 has left IRC (Ping timeout: 276 seconds)
[22:57:11] <Kirben> Where does Exult Studio crash?
[22:57:40] <Malignant_Manor> It crashes on start.
[22:59:14] <Kirben> Custom build? a major issue with GCC under mingw is it tend to break compatbility with older builds. GCC 4.7.x in particular.
[22:59:44] <Dominus> both via start menu and via going into map editor mode in exult?
[23:00:17] <Malignant_Manor> This is with a fresh GCC 4.7.2 with the Exult downloads from the readme.
[23:00:35] <Malignant_Manor> It also happened with GCC 4.7.0.
[23:01:08] <Dominus> so it happens with your own build but not the snapshot?
[23:01:17] <Malignant_Manor> Yeah
[23:01:26] <Kirben> That explains it, my libs were built with GCC 4.6.2.
[23:01:40] <Dominus> and as kirben wrote "a major issue with GCC under mingw is it tend to break compatbility with older builds. GCC 4.7.x in particular."
[23:03:11] <Malignant_Manor> maybe I can try mingw-get install msys-xml and see how that goes. Then I could add that to the readme if it works.
[23:04:49] <Kirben> I will just update the win32 compile guide to manual links for GCC 4.6.2.
[23:05:08] <-- SugarCube has left IRC (Ping timeout: 256 seconds)
[23:08:05] <Kirben> GCC under mingw has frequent bugs/issues, and can completely break compability (requiring all libs to be recompiled), so I rarely use the latest GCC version for Mingw, unless it offers major advantages.
[23:09:01] <Dominus> ah, yes, that sounds like the problems I ran into when I was on Windows. Only I didn't know that my problems were caused by this :(
[23:10:05] <Malignant_Manor> Okay
[23:10:07] --> sh4rm4 has joined #exult
[23:10:25] <Marzo> Dominus: did you commit the changes I last told you to do?
[23:10:47] <Dominus> no, since I ran into the llvm issue, I thought I'd better wait
[23:10:49] <Marzo> And Kirben: if you listen to sh4rm4, you will see that GCC 4.7.x seems to be having troubles not only on Windows
[23:11:09] <Malignant_Manor> Thanks, Kirben
[23:11:44] <Kirben> I recall issues reported with GCC 4.7.0 under mingw, with dosbox in particular failing to work. Not sure if the next build fixed issues under mingw.
[23:12:12] <Dominus> Marzo: should I go ahead and commit?
[23:12:41] <Marzo> Dominus: Hold on a bit, I will give you something to test in a few of minutes
[23:12:50] <Dominus> k
[23:18:05] --> SugarCube has joined #exult
[23:21:02] <Marzo> Dominus: here: http://pastebin.com/0ByLbVF1
[23:21:02] <Marzo> This is a synch with Pentagram's rev 2452
[23:21:47] * Dominus slaps his head....
[23:22:44] <Malignant_Manor> mingw-get install msys-libxml2 crashes too.
[23:23:26] <Malignant_Manor> I guess I will go use the download from earlier.
[23:23:41] <Dominus> Marzo: this did the endian problem away nicely
[23:28:24] <Marzo> You can commit all of it
[23:35:15] <Dominus> marzo, any idea on the llvm issue? Possible problem is that just the other day, xcode was updated and along with it the unix dev tools, including the llvm-gcc
[23:35:32] <Dominus> one can't be sure that apple hasn't made it worse :)
[23:35:41] <Marzo> What issue is that again?
[23:35:59] <Dominus> http://pastebin.com/PKhXyqNG
[23:36:09] <Dominus> when building with llvm and SDK 10.8
[23:36:27] <Dominus> you have to scroll down since I included configure output
[23:45:50] <Dominus> thanks, Kirben. Maybe add a note about the mixing of builds for different gcc will cause crashes, especially with gcc 4.7.x
[23:46:14] <Marzo> Dominus: try changing line 396 to this:
[23:46:15] <Marzo> out << str.c_str();
[23:47:01] <Marzo> (in files/utils.h)
[23:56:52] <Dominus> marzo, sorry, no. that didn't help
[23:57:08] <Dominus> but different line now
[23:57:34] <Marzo> Which error?
[23:57:46] <Dominus> http://pastebin.com/EfeQu5Hp
[23:58:12] <Marzo> Well, lets do it the right way then
[23:58:27] <Marzo> Undo what I told you to do
[23:58:42] <Eviltar> don't know if it is a helpful suggestion, but teamviewer is fantastic for helping remotely
[23:59:12] <Marzo> Hm. WriteStr is used once in a single place
[23:59:16] <Dominus> Eviltar: marzo would go nuts here with my build setup
[23:59:31] <Marzo> So do this: delete the entire WriteStr function