Build error on OS X 10.7.5, XCode 4

[ssteinerX]

Tried to build on OS X, got this at the end (after resolving three dependencies, cmake, xerces-c, lua, with homebrew).

http://pastebin.com/5VqLSGwz

Clues, anyone?

If those dependencies (and probably some I already had installed) could be listed in the docs, along with homebrew instructions, that would be really handy...

Thanks,

S

P.S. Would it be possible to reduce the number of images that need to be placed in the Key CAPTCHA?  Seven seems a bit excessive...

s

[softcoder]

Do you have experience with cmake? We already have a user who builds the mac builds for us who does not have these problems (weltall)

The cmake output states it did not find: ftgl, glew and the vorbis file library. Pasting the full cmake output would have helped as it would likely have pointed out the libs not found.

[ssteinerX]

Sorry, no experience with cmake at all.

It did choke on a couple of other dependencies which I fixed (as noted in original message).

Full output here:

https://gist.github.com/4465064

[ssteinerX]

I think this is really more of a documentation issue...

I'd be happy to add instructions for setting up homebrew (the best package manager these days for developers -- far more reliable and lightweight than Fink and MacPorts).

So far, I have these dependencies that are unlikely to be installed on OS X. 

cmake
xerces-c
lua

It seems there are some more...

Let's just gather'em up and add it to the build docs!

S

[softcoder]

We have a dependency setup script for various Linux distros located in mk/linux/setupBuildDeps.sh (and the documentation is here: https://docs.megaglest.org/MG/Linux_Compiling)

libsdl1.2-dev libxerces-c2-dev libalut-dev libgl1-mesa-dev libglu1-mesa-dev libvorbis-dev libwxbase2.8-dev libwxgtk2.8-dev libx11-dev liblua5.1-0-dev libjpeg-dev libpng12-dev libcurl4-gnutls-dev libxml2-dev libircclient-dev libglew-dev libftgl-dev libvlc-dev libfribidi-dev

[ssteinerX]

brew install ftgl
brew install glew
brew install libvorbis

And now I'm down to this:

https://gist.github.com/4465139

[ssteinerX]

Once we figure out what looks like one more error, how about we make a similar one for OS X.

Most people wouldn't have 1/35,565th what I already have on my system so my 6 missing dependencies would probably be about the minimum.

I'd be happy to work this out and help get it into the docs.

It looks like it may be wxWindows related which is always a nightmare on OS X.

S

[softcoder]

The main game does not use wxwidgets (only the map editor and g3d model viewer). To build only the game call cmake with these additional options:

Code: [Select]

cmake -DBUILD_MEGAGLEST_MODEL_IMPORT_EXPORT_TOOLS=OFF -DBUILD_MEGAGLEST_MODEL_VIEWER=OFF -DBUILD_MEGAGLEST_MAP_EDITOR=OFF ../

[ssteinerX]

Ok, when we've got this solved, I'll make a proposed doc change with that command line in it.

For now, that gives me this:

https://gist.github.com/4465173

[softcoder]

Are you trying to compile trunk? If so this seems like an old cmake file, try:

rm CMakeCache.txt
then rerun cmake

[ssteinerX]

Yes, it's a trunk checkout.

Gist contains svn checkout command, svn up output, and result seems to be the same:

https://gist.github.com/4470629

[softcoder]

This file had out dated info on Mac OsX, I committed a fix to svn, please try.

[ssteinerX]

Got further.

https://gist.github.com/4472224

Thanks for your help on this. 

When I get this building, my 8 year old says my first priority is to make LAN play more robust as we've been disconnected at some time during game play every time we've tried...

Thanks again,

S

[ssteinerX]

UPDATE:

   I tried downloading and linking the latest, greatest libircclient (which is .03 versions ahead of the included one, BTW) and had equally nasty compile errors and 'make install' was reported, in their bug tracker, not to work dating back to 2009... 

  Makes me nervous that it hasn't actually been installable since 2009 despite being updated in 2012...

  Not sure how much this feature is used, but it might be reasonable to shelve it until we can update to a current IRC client...

  Unless, of course, it works everywhere but OS X, in which case more research will be needed  .

S

[softcoder]

Ok now its no longer cmake failing. You will need to figure out the compile errors yourself for your environment. The code does build on Mac (we have a mac package on megaglest.org) so you will need to check your environment to see why its not working. I noticed you did not install libircclient and that the buidl is using our embedded cpy of the library, you may have better results installing a copy of libircclient and allowing cmake to use it.

Thanks

[ssteinerX]

Yes, I see that libircclient is causing the trouble and, as I said above, I did try installing the latest version but the usual `make install` fails and apparently has failed since 2009 (!) when it was reported.  I fiddled around with it and it doesn't compile either.

I'd love to chat with whoever builds the Mac distribution...remember, you gave me the commands to exclude large chunks of the build just to get this far.

I have a pretty straight-forward, standard Mac development system (one of my day jobs is Mac programming) so it should 'just work' in this environment.

I'm delighted to help figure this out further but if it builds for someone else, finding out what's different between our environments will be way more productive long-term for the project than having me just slog this out...

Thanks,

S

[softcoder]

Glad that you're wanting to persevere. As long as you are willing to keep trying join us on irc on freenode on the channel #megaglest

Thanks

[ssteinerX]

Posted on IRC, but here's what I get using the new flag:

ssteinerX: https://gist.github.com/4490013

[softcoder]

I've updated svn to try to get past these errors. Please try it out, and if you come acrosss any new compile errors feel free to fix them on your end and send me the modified files (or a patch) and I will apply it to svn.

[ssteinerX]

Latest svn build:

https://gist.github.com/4498811

[softcoder]

try rev# 4002

[ssteinerX]

Almost there!

https://gist.github.com/4500189

[softcoder]

rev #4003

[ssteinerX]

Simply adding a prototype like so:

namespace Shared { namespace Graphics {
char *strdup(const char *s1);

cured the problem in font.cpp.

Oddly, #include <string.h> in the same place did not solve the problem. 

As I said, I haven't programmed in C++ in many years, so maybe the #include obviously wouldn't work but it sure seems odd to me.

I'll hold off on patching anything else until I hear from someone more current with C++ as to whether my solution was the correct one.

Namespaces were not in common use back when I was using C++, so maybe there's some magic 'using xxx' that pulls the standard C string stuff into the current namespace but I couldn't find it (at 2:45AM when I was doing this 'cause I couldn't sleep...).

S


S

[ssteinerX]

We both tried the 'obvious' thing -- #include <string.h> -- but it didn't work where either of us put it, you at the top, me inside the namespace.

My "solution" of adding the prototype right in the namespace made it compile, but I'm suspicious that this will cause linking errors later on because we just faked it out; strdup's still not 'in' the namespace. 

Of course, I may just be talking out my ass -- I am very not-current with C++ at this point.

S