compiling on osx

[ojii]

I'm trying to compile experimental 10.27 on OSX, but it fails with:

Code Select Expand



gui/components/../../dataobj/einstellungen.h:52:4: error: use of undeclared identifier 'append'
                        append( new T( *src[i] ) );
                        ^
                        this->
gui/components/../../dataobj/einstellungen.h:71:7: note: in instantiation of member function
      'vector_with_ptr_ownership_tpl<livery_scheme_t>::vector_with_ptr_ownership_tpl' requested here
class settings_t
      ^
gui/components/../../tpl/vector_tpl.h:104:8: note: must qualify identifier to find this declaration in dependent base
      class
                void append(const T& elem)
                     ^



Anyone know how to solve this?

[jamespetts]

I do not have access to an OS X machine, however 10.27 is very out of date, as a new release is imminent. Might I suggest that you try the 11.x branch?

[ojii]

that branch compiled fine. thanks.

[jamespetts]

Splendid! Thank you for testing. Incidentally, would you be able to make binaries available for Mac OS X users once I put out a release version?

[ojii]

Sure no problem. In case I don't notice the release, just mail me at ojiidotch@gmail.com when you make a release.

[jamespetts]

Thank you!

[dannyman]

I haven't tried compiling yet on OS X, but would be keen to try and help for release: dannyman@toldme.com


-d

[ojii]

Btw for those interested to play exp (commit e684a47722e4f5b40b0216094a6b427fd299519d) on OSX:

URL: http://uploads.ojii.ch/sim-exp-osx/sim-exp-osx-e684a47722e4f5b40b0216094a6b427fd299519d
Filesize: 4879512
MD5 Checksum: d615f92dca58103f5c14dd73b934588a

[jamespetts]

The new release, 11.0, is now out: do you think that either of you could prepare a compiled binary for that? I should be very grateful.

[dannyman]

Will take a crack at it this evening. :>

[dannyman]

Is this the repo?
https://github.com/jamespetts/simutrans-experimental

[dannyman]

Alright, ojii, how'd you do it?

Here's something:
https://www.dropbox.com/s/iwzonp8un2rmmzh/sim11

The performance seems off.  The UI is sluggish.

What options do you set in options.default?  I figured start with:
BACKEND = sdl
COLOUR_DEPTH = 16

To compile I needed to do:
1) Patch freight_list_sorter.cc to include malloc/malloc.h
2) -I/usr/include

I'll try fiddling the options a bit.

Here is with optimise set:

https://www.dropbox.com/s/t2t3wp237jnfmc3/sim11-opt

NOTE: I get far superior performance from the Windows binary running via wine.

-danny

[jamespetts]

You need the following settings in config.default:

OPTIMISE = 1

MULTI_THREAD = 4

FLAGS = -DNDEBUG -fpermissive

The following should be commented out (as shown):

#PROFILE = 0

I hope that this helps.

[ojii]

compilation (tag 11.0, 6eb948cea20017c238d601793e6aeee1ceb31df4) fails for me, see http://dpaste.com/hold/1294043/


EDIT: Btw I'm usually idling on #simutrans on quakenet if you want to talk to me in real time.

[dannyman]

Aye, ojii, I had tried to compile with threads and got an error like that, too.  -d

[jamespetts]

Hmm, the error appears to be:

Code Select Expand

boden/wege/weg.cc:50:46: error: use of undeclared identifier 'PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP'
static pthread_mutex_t weg_calc_bild_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;

Have you made sure that you have properly set up the pthread (multi-threading) libraries?

[dannyman]

0-16:42 dannhowa@dannhowa-mac simutrans-experimental$ grep PTHREAD_MUTEX_RECURSIVE /usr/include/pthread.h
#define PTHREAD_MUTEX_RECURSIVE      2
0-17:04 dannhowa@dannhowa-mac simutrans-experimental$ find /usr/include/ -type f | xargs grep -l PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
/usr/include//c++/4.2.1/bits/gthr-default.h
/usr/include//c++/4.2.1/bits/gthr-posix.h
/usr/include//c++/4.2.1/bits/gthr-tpf.h

Sounds like it might be a portability thing:

http://stackoverflow.com/a/7934058/178711

I have experimented with -pthread but no difference.

I tried running with code like:

http://stackoverflow.com/a/7963765/178711

But that was errors about ...

#if MULTI_THREAD>1
#include <pthread.h>
/*
static pthread_mutex_t weg_calc_bild_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
*/

pthread_mutex_t         weg_calc_bild_mutex;
pthread_mutexattr_t     attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&weg_calc_bild_mutex, &attr);

#endif

...

I get errors like:
boden/wege/weg.cc:56:1: error: unknown type name 'pthread_mutexattr_init'; did you mean 'pthread_mutexattr_t'?

. . . which I believe means I don't speak C++ adequately, because what looks to me like a function call is erroring out like a bad type assignment.

[dannyman]

Okay, I moved the function calls to the init function, now we bomb out at dataobj/loadsave.cc because OSX does not support posix barriers ...

In dataobj/loadsave.cc I do:


#if MULTI_THREAD>1 && _POSIX_BARRIERS>0


Then, boden/wege/weg.cc complains again about PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP ... more hacking to see if we get anywhere.

Any general advice about threadedness in loadsave.cc?  I think disabling the barriers might allow compilation but might cause some trouble.

-d

[dannyman]

Hacked barrier out of the way, and compiles, but crashes at startup.

0-22:22 dannhowa@dannhowa-mac simutrans$ ./sim
Use work dir /Users/dannhowa/Dropbox/simutrans/
Reading low level config data ...
Parsed simuconf.tab for directory layout; multiuser = 1
parse_simuconf() in program dir (config/simuconf.tab): Reading simuconf.tab successful!
Preparing display ...
SDL_driver=Quartz, hw_available=0, video_mem=0, blit_sw=0, bpp=32, bytes=4
Screen Flags: requested=10, actual=10
dr_os_open(SDL): SDL realized screen size width=704, height=560 (requested w=704, h=560)Loading font 'font/prop.fnt'
font/prop.fnt successfully loaded as old format prop font!
Segmentation fault: 11

Diff attached.  It is maybe slightly more elegant and well-informed as a lobotomy   Possibly sanest is to find an implementation of posix barriers we can incorporate into source tree?

Maybe this?  http://www.scs.stanford.edu/histar/src/pkg/uclibc/libpthread/linuxthreads/barrier.c

Okay, over my head now ... sorry.

-danny

[dannyman]

Yarr!


So, I appropriated a barrier.h from http://blog.albertarmea.com/post/47089939939/using-pthread-barrier-on-mac-os-x (it was broken, though, and I had to fix it ..)


Then compiled, per the attached patch ...


ALMOST made it ...



0-23:03 dannhowa@dannhowa-mac simutrans-experimental$ make
===> LD  build/default/sim
duplicate symbol __Z20pthread_barrier_initP17pthread_barrier_tPKij in:
    build/default/dataobj/loadsave.o
    build/default/simview.o
duplicate symbol __Z23pthread_barrier_destroyP17pthread_barrier_t in:
    build/default/dataobj/loadsave.o
    build/default/simview.o
duplicate symbol __Z20pthread_barrier_waitP17pthread_barrier_t in:
    build/default/dataobj/loadsave.o
    build/default/simview.o
duplicate symbol __Z20pthread_barrier_initP17pthread_barrier_tPKij in:
    build/default/dataobj/loadsave.o
    build/default/simsys_s.o
duplicate symbol __Z23pthread_barrier_destroyP17pthread_barrier_t in:
    build/default/dataobj/loadsave.o
    build/default/simsys_s.o
duplicate symbol __Z20pthread_barrier_waitP17pthread_barrier_t in:
    build/default/dataobj/loadsave.o
    build/default/simsys_s.o
ld: 6 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build/default/sim] Error 1

[dannyman]

And yeah, if I rename barrier.c to barrier.h, no dice.

[jamespetts]

Hmm - can you try first, as an experiment, compiling without MULTI_THREAD defined at all? That should at least narrow the problem. I'm afraid that I don't know how to set up multi-threading support on OSX, but I think that the Standard developers have been able to do it, and there are, to my knowledge, no changes in the threading code between Standard and Experimental.

[ojii]

11.0 without threading:

TAG: 11.0
COMMIT: 6eb948cea20017c238d601793e6aeee1ceb31df4
URL: http://uploads.ojii.ch/sim-exp-osx/sim-exp-osx-11.0-no-threading
SIZE: 4879512
MD5: bf0c9a174744f06cde0e457e0b2233f9

[jamespetts]

Splendid - thank you very much.

Can anyone more familiar than I with pthreads assist with the multi-threading issue?

[TurfIt]

See:
http://forum.simutrans.com/index.php?topic=11747.msg115872#msg115872
https://github.com/artdent/simutrans/commit/ef549695387e448b0008c7409a4fcdfc6f9a4442

[ojii]

I see you also have linux x64 as "to follow", I can provide those binaries (tomorrow) too if necessary. do you already have someone for those or do you want me to compile them?

[jamespetts]

TurfIt - thank you. Ojii - does that help? As for Linux 64-bit (and 32-bit), that is taken care of by an automated system (or, will be when the compile bugs are fixed), which complies every night, if there are any changes. The offer is much appreciated, however.

[ojii]

glad to hear that, I would've offered to set up an automated system on my servers anyway, but glad to hear you have that already in place. wish I could do the same for OSX, but unfortunately Apple is not too keen to allow ec2 like offers...


I'll see what I can do to automate the OSX builds nevertheless, but for now I'm happy to just do it manually.

[jamespetts]

That is very kind - thank you very much. Did the threads to which TurfIt referred help with the multi-threading support?

[ojii]

I haven't looked into it, I'm not very proficient in C++, but unless dannyman figures it out by tomorrow (my time) I'll try to apply the referenced patch and see if I can get it to compile.

[jamespetts]

Thank you!

[dannyman]

dannyman thinks the most likely avenue is the application of https://github.com/artdent/simutrans/commit/ef549695387e448b0008c7409a4fcdfc6f9a4442, which he would try himself were he either more git-savvy.

If you have trouble getting that patched version to compile, and you can drop me a note on pulling that into my checkout, I would be happy to try banging on it some more.  (It looks like all the hacking I tried to do, were it done by a professional.

Godspeed, ojii!

(Or, if I get some time, I'll learn a bit more git and see if I can integrate the patch...)

-danny

[jamespetts]

Hmm - interesting. Where did you find that? The person who created it might be able to assist.

As for Git, you could try this tutorial. My Git knowledge is Linux and Windows based, so I am not sure how much that I might be able to help you.

[dannyman]

jamespetts: TurfIt posted that URL a wee bit up the thread.  I wish it had a "download as diff" option.  I've tried git remote add, git fetch, but not yet managing to git cherry-pick.  My little brain is fried tonight as my little one is getting over a cold and sleep is in short supply around here.

As far as I know, your knowledge of git would work equally well in Macintosh land.  Anyway, if nobody beats me to it, I'll learn more git and merge that changeset and see if we can get a proper multithreaded simutrans-exp running on OSX.

-danny

[ojii]

jamespetts: TurfIt posted that URL a wee bit up the thread.  I wish it had a "download as diff" option.  I've tried git remote add, git fetch, but not yet managing to git cherry-pick.  My little brain is fried tonight as my little one is getting over a cold and sleep is in short supply around here.

As far as I know, your knowledge of git would work equally well in Macintosh land.  Anyway, if nobody beats me to it, I'll learn more git and merge that changeset and see if we can get a proper multithreaded simutrans-exp running on OSX.

-danny

Add .diff or .patch at the end of any 'diff-like' github url (this is a github feature, not git) to get a patch/diff.

git cherry-pick is a bit "dangerous" (it can mess with your history), so it's better avoided in my opinion. however, it is fairly straight forward to use: `git cherry-pick <commit sha>` will apply that commit to your local copy (if it can find that commit, you might need a git fetch first).

having said that, I did cherry pick ef549695387e448b0008c7409a4fcdfc6f9a4442 and tried to compile it, but got:

Code Select Expand


In file included from ./boden/grund.h:18:
./boden/wege/weg.h:228:22: warning: 'weg_t::ist_entfernbar' hides overloaded virtual function [-Woverloaded-virtual]
        virtual const char *ist_entfernbar(const spieler_t *sp, bool allow_public = false);
                            ^
./dataobj/../simdings.h:339:22: note: hidden overloaded virtual function 'ding_t::ist_entfernbar' declared here
        virtual const char *ist_entfernbar(const spieler_t *sp);
                            ^
freight_list_sorter.cc:18:10: fatal error: 'malloc.h' file not found
#include "malloc.h"