Compiling L++ - need some help

[The Doctor]

Ahoy there,

I'd just like to know if anybody has had success compiling the L++ source code on any platform.

I'm trying to build a version for Mac OS X so that I can play.

I'm guessing that I need libenet-1.2.2 or lower (libenet-1.3.0 seems to be incompatible with L++), but I'm not sure which version of Allegro.

I tried Allegro 4.4, that didn't quite work. I might give 4.2 a shot later on.

Any tips?

[Simon]

Which version are you going to compile? The March version needs enet 1.2 and Allegro 4.2 or 4.4. The October version needs enet 1.3 and also Allegro 4.2 or 4.4. The March version can be played on Mindless' server.

I was exchanging emails over the past weeks with someone who finally got the October version to compile under OS X. He has already sent me a fix for this particular problem, even though I haven't incorporated it yet into my codebase: In the nonworking versions, I declare static std::strings in globals.h. The fix is to move these into globals.cpp and only forward declare them in globals.h via the extern keyword.

I got the October code without the fix to compile on an Ubuntu machine, but haven't ran the game there yet. When geoo was visiting me, he got this September's version to compile under Windows.

-- Simon

[The Doctor]

Not sure which I'm trying. It's whatever's on the Lemmings File Archive mirror. I can compile it, but it segfaults when trying to run the main app. lppserv runs fine, though.

I have noticed a few details that Mac OS X didn't like, so I've changed them and made notes. (e.g. compiling in 32-bit mode only makes things a HELLUVA lot easier)

[Simon]

The March version is what usually lingers around the web. Try the fix in globals.h/globals.cpp that I wrote about. This removed a segfault for the person I was exchanging emails with, while he was able to run lppserv immediately.

You can compile it with 32-bit colors and still play with 16-bit color versions via network. The 16 bit colors were to speed up the game at a few friends' computers I was trying it on. You must change all _getpixel16() and _putpixel16() to _getpixel32() _putpixel32() in that case, just search the entire codebase for these two functions.

-- Simon

[The Doctor]

Well, I've moved them. Seems to reduce the amount of warnings that GCC was giving me. Still getting a segfault, however. I need to trace where it's coming from.

[The Doctor]

Any chance of obtaining the most recent source so I can jigger with that and see if I can get her running on OS X?

[Adam]

I have nothing of value to add to this thread, but I feel the need to say that I love the word 'jigger'.

That is all.

[The Doctor]

Hehe, Adam. Glad I stimulate your sense of vocabulary!

Anyway, the errors I seem to be having related to strings indeed.

GDB gives (compiled with GCC):

Code: [Select]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x93bb8a7b in std::string::_Rep::_M_grab ()
LLDB gives (compiled with Clang):

Code: [Select]

Process 38005 Stopped
* thread #1: tid = 0x2c03, pc = 0x93bb8a7b
where = libstdc++.6.0.9.dylib`std::string::_Rep::_M_grab(std::allocator<char> const&, std::allocator<char> const&) + 15,
stop reason = exception:
type = 0x00000001,
data_count = 2,
data[0] = 0x00000001,
data[1] = 0xfffffffc,
queue = com.apple.main-thread

[Simon]

Hey Jason,

I sat down today and rewrote several parts of the fundamental L++/Lix code. There was more to it than what I suggested earlier.

I will send you the work-in-progress code per email, some time in the next days. (I'm shifting code around right now to kill unnecessary includes, so the server code compiles nicely from the same files as well.) In case you're still interested and have time, you can see whether it compiles on your machine then.

All strings are initialized at a hopefully safe time now. Your issues appeared to be due to std::strings being initialized before any code is executed. The problem is that strings must be instantiated during executing code, since they're not a fundamental type. I really wonder why it worked all the time for me, under Linux and Windows with g++ and MinGW... compiler-specific magic?

Sorry for delaying the issue for so long. I didn't have a proper idea on the first day, and didn't think much in the meantime about it. Most of my work for the game goes into spriting at the moment.

-- Simion