Compiling for powerpc (Darwin 9/OS X 10.5)

[R-T-B]

That was before MC "upgraded" to double the build height, and was slightly under-estimated.

Right now just the chunks for a single player take up around 64 MiB, and since they are not unloaded very often, it can get to twice that amount fast. Sure, unloading them as soon as they go "out of sight" is possible but still you won't be able to fit more than 3 players.

Just a thought: Is it possible to have a settings.ini file variable to define the build height server side? That would allow lower ram configurations to have more potential.

Back on topic:

I've gotten it to build and report status, but I can never actually login. Here's what I had to do (and obviously this will break it on non-darwin platforms). This is all done on SVN 400.

Change line 87 of CMonster.cpp to: "*Spawn->m_Pos = (Vector3i) m_Pos * 32;" (build issue)
comment out line 28 and line 31 in cEvent.cpp (build issue)
change line 125 of cSocket.cpp to "char * res = (char*)strerror_r( errno, buffer, ARRAYCOUNT(buffer) );" (build issue)
change every instance of MSG_NOSIGNAL to SO_NOSIGPIPE in WebServer/Socket.cpp (build issue, MSG_NOSIGNAL not present in Darwin)
disable/commentout the check function of cSocketThreads.cpp at line #448. (crash on login if not done)
comment out entire if at line 634 cSocketThreads.cpp (crash on login if not done)

When doing this, it disconnects users saying something about a unknown packet "0x7E" but does not crash.

Server log:

[15:50:26] Client "127.0.0.1" connected!
[15:50:26] New ClientHandle created at 0x83d800
[15:50:26] Creating a new cSocketThread (currently have 0)
[15:50:26] Error on shutting down socket ()
[15:50:26] Error on shutting down socket (127.0.0.1)
[15:50:26] Deleting client "" at 0x83d800
[15:50:26] ClientHandle at 0x83d800 deleted
[15:50:28] Client "127.0.0.1" connected!
[15:50:28] New ClientHandle created at 0x83d800
[15:50:28] HANDSHAKE Memphesian2007
[15:50:28] User "Memphesian2007" was sent a handshake
[15:50:28] LOGIN Memphesian2007
[15:50:28] Added Memphesian2007 to group Default
[15:50:28] Player Memphesian2007 has permissions:
[15:50:28] core.help
[15:50:28] core.playerlist
[15:50:28] core.pluginlist
[15:50:28] core.spawn
[15:50:28] Streaming chunks centered on [28, -1], view distance 9
[15:50:32] Unknown packet type 0x7e from client "Memphesian2007"
[15:50:33] chunk [28, -1] destroying entity #1 for player "Memphesian2007"
[15:50:33] Error on shutting down socket (127.0.0.1)
[15:50:33] Error 9 while writing to client "127.0.0.1", disconnecting. "Error 9 while getting error string for error #9!"
[15:50:33] Error on shutting down socket (127.0.0.1)
[15:50:33] Error closing socket (127.0.0.1)
[15:50:33] Deleting client "Memphesian2007" at 0x83d800
[15:50:33] ClientHandle at 0x83d800 deleted
[15:50:33] Destroying entity #1
[15:50:33] Deleting cPlayer "Memphesian2007" @ 0x205b90
[15:50:33] DESTROY WINDOW
[15:50:33] DESTROY WINDOW
[15:50:33] Player 0x205b90 deleted
[15:50:33] Deleting entity 1 at pos {463.00, -9.00} ~ [28, 0]; ptr 0x205b90

Any ideas? I'd make diffs but it seems pretty pointless right now. Also, I'm using client 1.2.3. I assume that's right?

[xoft]

Serverside height is not possible atm and I don't think it's worth implementing. However, FakeTruth set out to implement dynamic chunk height, meaning that chunk will take up only the RAM they need for non-air blocks. Effectively, this is an even better solution.
There's also the setting for player viewdistance, making it possible to have less chunks loaded per player. The server starts each player with the server-side default ([Server].DefaultViewDistance in INI, 9 if not present), players may adjust the setting using the /viewdistance <N> command in-game.

I'll look into your changes and try to incorporate them into the svn sources.

Packet 0x7e is not documented and Windows clients don't send it. Are you using a vanilla client, or with some mods? 1.2.3 is the version curently supported by the latest svn versions of MCS.

---

Is there any preprocessor macro specific for your compiler, such as _MSC_VER for MSVC or __GNUC__ for gcc? I'd need that for your cSocket.cpp modifications. If you look closely, the strerror_r is already there, just a few lines below, in a different #if block (because stupid *nix community can't choose which one to use )

---

I've tried to fix most of your issues in rev 402, but I'm not comfortable doing any of the changes you made to cSocketThreads. Both of the lines you indicated are vital to the program and it cannot function without them. If it crashes on them, then we need to find the reason for the crash, rather than commenting them away blindly.

[R-T-B]

Serverside height is not possible atm and I don't think it's worth implementing. However, FakeTruth set out to implement dynamic chunk height, meaning that chunk will take up only the RAM they need for non-air blocks. Effectively, this is an even better solution.
There's also the setting for player viewdistance, making it possible to have less chunks loaded per player. The server starts each player with the server-side default ([Server].DefaultViewDistance in INI, 9 if not present), players may adjust the setting using the /viewdistance <N> command in-game.

I'll look into your changes and try to incorporate them into the svn sources.

Packet 0x7e is not documented and Windows clients don't send it. Are you using a vanilla client, or with some mods? 1.2.3 is the version curently supported by the latest svn versions of MCS.

---

Is there any preprocessor macro specific for your compiler, such as _MSC_VER for MSVC or __GNUC__ for gcc? I'd need that for your cSocket.cpp modifications. If you look closely, the strerror_r is already there, just a few lines below, in a different #if block (because stupid *nix community can't choose which one to use )

---

I've tried to fix most of your issues in rev 402, but I'm not comfortable doing any of the changes you made to cSocketThreads. Both of the lines you indicated are vital to the program and it cannot function without them. If it crashes on them, then we need to find the reason for the crash, rather than commenting them away blindly.

I'm using a vanilla client. Weird.

Anyhow, I'll admit I got desperate towards the end and started commenting away pretty much anything throwing an error. I don't know enough about C++ to be honest to tell you about the preprocessor macros, I'm assuming a google search might turn something up from the apple dev documents.

Honestly, I'm finding Darwin is a bastard of an operating system when it comes to standardization. It's really strange some of the things they chose not to support.

[xoft]

Okay, so let's try rev 406. Can you build it from clean sources? Does it run? If not, what are the errors messages?

[R-T-B]

Okay, so let's try rev 406. Can you build it from clean sources? Does it run? If not, what are the errors messages?

I'll try it sometime tonight/tomorrow. Just got home from a trip. Thanks for working with me to fix this.

[xoft]

It seems that both Darwin and OS X whatever have the macro __APPLE__ defined, but each has a different strerror_r() function signature.

Could you please run this command on your Darwin machine, and paste its output here, so that we can find out what kind of macros we need to set up to make the compilation succeed on both systems.

Code:

gcc -dM -E - < /dev/null

Thanks.

[R-T-B]

It seems that both Darwin and OS X whatever have the macro __APPLE__ defined, but each has a different strerror_r() function signature.

Could you please run this command on your Darwin machine, and paste its output here, so that we can find out what kind of macros we need to set up to make the compilation succeed on both systems.

Code:

gcc -dM -E - < /dev/null

Thanks.

Hello, I ran this on my leopard machine. I don't have an actual Darwin machine on hand.

Sorry it took so long but I was out of town visiting family for a good month. Here's the output:

#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __VEC__ 10206
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __ALTIVEC__ 1
#define __FLT_EVAL_METHOD__ 0
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 1
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.79769313486231580793728971405301e+308L
#define __APPLE_CC__ 5493
#define __LDBL_MAX_EXP__ 1024
#define __SCHAR_MAX__ 127
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __DBL_DIG__ 15
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 2.00416836000897277799610805135016e-292L
#define __ppc__ 1
#define __strong
#define __APPLE__ 1
#define __DECIMAL_DIG__ 33
#define __LDBL_HAS_QUIET_NAN__ 1
#define __DYNAMIC__ 1
#define __GNUC__ 4
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_HAS_INFINITY__ 1
#define OBJC_NEW_PROPERTIES 1
#define __weak
#define __DBL_MAX_EXP__ 1024
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_HAS_QUIET_NAN__ 1
#define __pixel __attribute__((altivec(pixel__))) unsigned short
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define _ARCH_PPC 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.0.1 (Apple Inc. build 5493)"
#define __BIG_ENDIAN__ 1
#define __UINTMAX_TYPE__ long long unsigned int
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1058
#define __SIZE_TYPE__ long unsigned int
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L
#define __NATURAL_ALIGNMENT__ 1
#define __vector __attribute__((altivec(vector__)))
#define __FLT_HAS_QUIET_NAN__ 1
#define __bool __attribute__((altivec(bool__))) unsigned
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __FLT_HAS_INFINITY__ 1
#define _BIG_ENDIAN 1
#define __LDBL_MANT_DIG__ 106
#define __CONSTANT_CFSTRINGS__ 1
#define __WCHAR_TYPE__ int
#define __FLT_DIG__ 6
#define __INT_MAX__ 2147483647
#define __LONG_DOUBLE_128__ 1
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ int
#define __LDBL_MIN_EXP__ (-968)
#define __MACH__ 1
#define __LDBL_MAX_10_EXP__ 308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __PIC__ 1
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define __GNUC_MINOR__ 0
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.94065645841246544176568792868221e-324L
#define __PTRDIFF_TYPE__ int
#define __LDBL_MIN_10_EXP__ (-291)
#define __LDBL_DIG__ 31
#define __POWERPC__ 1
#define __GNUC_GNU_INLINE__ 1

[xoft]

Welcome back

Can you try the latest rev (488), if it compiles? There have been some changes in the preprocessor magic, and I've kinda lost track of what's been done where
I think you should be able to compile, and if not, the only problematic thing is the strerror_r(). It seems Apple has been changing their mind a lot regarding this function and they use both signatures in different OSs, maybe even in the same OS, just a different version.

[R-T-B]

Welcome back

Can you try the latest rev (488), if it compiles? There have been some changes in the preprocessor magic, and I've kinda lost track of what's been done where
I think you should be able to compile, and if not, the only problematic thing is the strerror_r(). It seems Apple has been changing their mind a lot regarding this function and they use both signatures in different OSs, maybe even in the same OS, just a different version.

Yep, compiles without a hitch now. However, it crashes with a genuine true segmentation-fault when a client tries to connect.

I'll run it in the x-code debugger later and see why. Too tired right now.

[The Walking Glitch]

Is your code taking that path in cEvent? If you uncomment those lines and put a breakpoint in them, does it hit the breakpoint? If so, that's the reason for your failure - the ASSERT() macro force-terminates the program.

If there's anything that doesn't compile, please send us the patch that makes it work for you. You can either attach a patch file to the forum post, or send me an email at <my-nick> @ <my-nick>.cz

That 'weird' code path was specifically there for Mac >_>

http://stackoverflow.com/questions/14137...it-on-os-x

To comment on why I'm using sem_unlink after creation ( // _X: I'm unconvinced about using sem_unlink() just after a successful sem_open(), it seems wrong - why destroy the object just after creating? )
sem_unlink() does not destroy the object yet, it only destroys it after it has been closed

If one or more processes have the semaphore open when sem_unlink() is called, destruction of the semaphore is postponed until all references to the semaphore have been destroyed by calls to sem_close(), _exit(), or exec

http://pubs.opengroup.org/onlinepubs/790...nlink.html

Yeah, the issue actually has nothing to do with powerpc. The issue lies solely with Darwin using screwy headers. For example, using unnamed semaphores is completely unsupported and brings a host of networking problems with it. This probably applies to intel as well.

I've basically fixed most of the issues, but my fixes are noobish and will likely break compilation on other platforms. Please wait why I test and cleanup the code a bit.

Could you guys by chance use a hand on this project? I really want to learn C and C++ and I have access to several odd pieces of hardware (PowerPC, SPARC, ARM,even a MIPS router running linux) that I could test compilation on. Would be good for an educational experience. The only thing I ask is that I could use this code in a commercial "minebox" I've been developing that is basically a low cost minecraft server in a $100 pricepoint single board computer. I assume the license terms allow that?

As far as what I can contribute, I was the author of PhoenixTerrainMod (google it) and I know a lot about terrain generation in the minecraft style. By the looks of it, you could use some help on that front.

Thanks, will continue to work on this regardless.

-RTB

I think you will have issues with MIPS. MIPS does not support division and square root functions. You would need to change all division operations to multiplication using decimals, and find a substitute for square root operations. Though you could speed up mcserver if you changed all the division operations to multiplication by decimals anyways, since those can be pipelined on most processor architectures.