Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Belal]

Hey guys, I'm just curious as to whether a compiled binary for OSX is being worked on or planned in the future? 

I use my mac for work and usually have df running in the background.  Unfortunately there isn't any tools for dwarf management available for the mac (I use 40d16 and even the modified version of MacForeman error's on me).  I usually end up having to copy my save to a network share, restart my machine into windows, organise my dorfs, copy the save back to a network share, then restart back into mac.  As you can imagine this is quiet a tedious process   

Neither peterix or I has access to an OSX machine, and from some research it looks like processor access on OSX is an ugly affair, and not as close to linux as you would think.  So as of right now this is not planned.  If someone would like to step up to do the requisite research in extending dfhack to support OSX it is a possibility, but until that happens it is not likely.

[peterix]

Well, I do have some ideas on how to do it... but without an OSX machine, I can't do much.

[kutulu]

Well, I do have some ideas on how to do it... but without an OSX machine, I can't do much.

I have two of them available, one already even has XCode/gcc installed on it.  Anything I can do to help just holler.

--K

[kutulu]

Building libdfconnect yourself/linking against precompiled stuff from other distros: Don't, unless you really know what you are doing. All it takes for it to fail is a simple change in alignment of C++ types or something similar. If I didn't have to hack in using LD_PRELOAD (if it was an official DF API), there would be no such problem, but the way things are right now, libdfconnect has to be binary compatible with DF. LD can detect some of the problems, but not all.
Mixing libs built with different compilers, libc/libstdc++ versions or CFLAGS is just asking for trouble... and that's probably why you can't link to the precompiled libdfhack.so

Anyway, when you build both DT and dfhack, it should work even with 64bit. Actually, I do this all the time - I'm using 64bit Archlinux and the Ubuntu machine is only for building libdfconnect [/spoiler]

This is what I'd really like to do, but so far that still hangs on startup.  It looks like it connects properly to the running df instance, but hangs on the line of code that sets the title bar.  This happens to be, as far as I can tell, the first time DT actually tries to read something from the connected instance.

I've started over from scratch, and did this:

* Checked out the latest dwarftherapist.git and dwarfhack.git into my src folder.
* Copied the dfconnect lib from dfhack into my dwarf fortress folder and preloaded it (that works fine -- I see the preloading message).
* Built dfhack
* Added the dfhack output to dwarftherapists's LDFLAGS and startup script, and built that.

Unless I missed some key step that you can correct me on, this should run.  I'll work on getting a usable backtrace from this, but I dunno how successful I'll be.  gdb doesn't seem to like my system -- either PaX prevents it from attaching properly or building everything as PIE prevents it from loading symbols.  Soon as my tax refund gets here I'm getting a second Linux system just for development work

--K

[peterix]

Building libdfconnect yourself/linking against precompiled stuff from other distros: Don't, unless you really know what you are doing. All it takes for it to fail is a simple change in alignment of C++ types or something similar. If I didn't have to hack in using LD_PRELOAD (if it was an official DF API), there would be no such problem, but the way things are right now, libdfconnect has to be binary compatible with DF. LD can detect some of the problems, but not all.
Mixing libs built with different compilers, libc/libstdc++ versions or CFLAGS is just asking for trouble... and that's probably why you can't link to the precompiled libdfhack.so

Anyway, when you build both DT and dfhack, it should work even with 64bit. Actually, I do this all the time - I'm using 64bit Archlinux and the Ubuntu machine is only for building libdfconnect [/spoiler]

This is what I'd really like to do, but so far that still hangs on startup.  It looks like it connects properly to the running df instance, but hangs on the line of code that sets the title bar.  This happens to be, as far as I can tell, the first time DT actually tries to read something from the connected instance.

I've started over from scratch, and did this:

* Checked out the latest dwarftherapist.git and dwarfhack.git into my src folder.
* Copied the dfconnect lib from dfhack into my dwarf fortress folder and preloaded it (that works fine -- I see the preloading message).
* Built dfhack
* Added the dfhack output to dwarftherapists's LDFLAGS and startup script, and built that.

Unless I missed some key step that you can correct me on, this should run.  I'll work on getting a usable backtrace from this, but I dunno how successful I'll be.  gdb doesn't seem to like my system -- either PaX prevents it from attaching properly or building everything as PIE prevents it from loading symbols.  Soon as my tax refund gets here I'm getting a second Linux system just for development work

--K

I've never run dfhack on a PaX-enabled system and to be honest, I don't think this is a good idea in general. DFHack depends on things being in predictable places. I do counter the ASLR stuff in Vista and 7, but that's fairly simple...

So, some questions
Does DT or dfhack work without the SHM?
Try the dfhack utils. Start with dfsuspend - that's the simplest one and doesn't touch DF's memory at all.
Did you give the compiled DT the right Memory.xml?
Can you also try with all that PaX stuff disabled?

Also, dfhack on Linux has some requirements that are normally met:
A writable /tmp/ for the SHM to work - I guess it works, because you get crashes It's used to store file locks.
A readable /proc/PID/mem and ability to use ptrace for the 'normal' memory access.

Some security thing could block those and the results wouldn't be pretty.

[muty]

I have one issue to report.
Everything works fine now, just when I switch to squad in the "group by" dropdown, dwarf therapist segfaults. DF is continues to run fine tho.

[peterix]

I have one issue to report.
Everything works fine now, just when I switch to squad in the "group by" dropdown, dwarf therapist segfaults. DF is continues to run fine tho.

What system and which version of DF are you using?
Nevermind. I'll look into it

[muty]

Thank you.
Let me know if I can help with anything, logs, crashdumps, a beer

[Belal]

Thank you.
Let me know if I can help with anything, logs, crashdumps, a beer

This is now fixed in the 0.1.2 release, thanks for letting us know about the crash

[Fullets]

Unfortunately there isn't any tools for dwarf management available for the mac (I use 40d16 and even the modified version of MacForeman error's on me).

Is that the version I posted? If you can let me know what the error is I'll look into it.

[Spectral]

When i try and run on Ubtunu 9.10 I get this:

undefined symbol: _ZN9QHashData14detach_helper2EPFvPNS_4NodeEPvEPFvS1_Eii

Any idea wtf that means?

[Sudius]

Please tell me DT is in the works for our new release ;_;

Your amazing program has spoiled me and I now actually have to maintain microscopic levels of detail to remember who has what labor enabled from in-game.  ;_;

[Paradox]

Same here, I can barely function without Dwarf Therapist.

[John Hopoate]

Please hurry please hurry please hurry please hurry

[Ninteen45]

My ego is growing to massive proportions!

Who needs Therapist with the new organizational tools coming out?

Burrows, Zones... I guess you guys never play Myst and similer with the good ol' note keeping tools, Pen and Paper.