Compatibility with DF v0.34.01 - Linux/OSX

[GoogleCodeExporter]

YOU KNOW YOU WANT IT BABY

Original issue reported on code.google.com by AforAnon...@gmail.com on 14 Feb 2012 at 8:07

[GoogleCodeExporter]

OH GOD I WANT IT SO BAD

Original comment by Anonymou...@gmail.com on 15 Feb 2012 at 2:29

[GoogleCodeExporter]

THIS BUG HAS BEEN FIXED.

Original comment by ehler...@gmail.com on 16 Feb 2012 at 4:29

• Changed state: Fixed

[GoogleCodeExporter]

HELL YEAH.

Original comment by AforAnon...@gmail.com on 16 Feb 2012 at 6:38

[GoogleCodeExporter]

I'm afraid that 7b6b7d01a905 only adds support for the Windows binaries, those 
of us on linux still receive the following:

I'm sorry but I don't know how to talk to this version of Dwarf Fortress! 
(checksum:0xa42a074a)

Supported Versions:
v0.31.25(0xfc15065c)
etc.

I can't find a button to pop this back open, but Compatibility with DF v0.34.01 
is not complete yet.

Original comment by Kionm...@gmail.com on 16 Feb 2012 at 7:32

[GoogleCodeExporter]

Fixed for windows, but not linux or OSX yet.

Original comment by ehler...@gmail.com on 16 Feb 2012 at 2:33

• Changed title: Compatibility with DF v0.34.01 - Linux/OSX
• Changed state: Accepted
• Added labels: OpSys-Linux, OpSys-OSX

[GoogleCodeExporter]

Original comment by ehler...@gmail.com on 16 Feb 2012 at 2:34

• Added labels: Priority-High

[GoogleCodeExporter]

Here's my ini file for linux. It seems to be working pretty well for me, 
thought it might help you close this one.

Original comment by pascal.g...@gmail.com on 17 Feb 2012 at 1:55

Attachments:

• v0.34.01.ini

[GoogleCodeExporter]

Attaching companion ini file for v0.34.02 linux version. Same as pascal's, 
"seems to be working pretty well for me". Hope this helps.

Original comment by Kionm...@gmail.com on 18 Feb 2012 at 2:05

Attachments:

• v0.34.02.ini

[GoogleCodeExporter]

Got a compile error with 0.6.12:

src/scanner.cpp: In member function ‘void 
Scanner::find_null_terminated_string()’:
src/scanner.cpp:283:62: erreur: no matching function for call to ‘qMin(uint, 
long unsigned int)’
src/scanner.cpp:283:62: note: candidate is:
/usr/include/QtCore/qglobal.h:1194:34: note: template<class T> const T& 
qMin(const T&, const T&)
src/scanner.cpp: In member function ‘void 
Scanner::find_number_or_address()’:
src/scanner.cpp:301:62: erreur: no matching function for call to ‘qMin(uint, 
long unsigned int)’
src/scanner.cpp:301:62: note: candidate is:
/usr/include/QtCore/qglobal.h:1194:34: note: template<class T> const T& 
qMin(const T&, const T&)
make: *** [bin/release/scanner.o] Erreur 1

Original comment by hic...@gmail.com on 18 Feb 2012 at 5:27

[GoogleCodeExporter]

the (uint) casts in scanner.cpp need to be changed to (size_t), then it 
compiles fine.

Original comment by Yabo...@gmail.com on 18 Feb 2012 at 5:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm running DF 0.34.02 on Xubuntu 11.10,
uname: Linux Callisto 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 
2011 x86_64 x86_64 x86_64 GNU/Linux

I built DT from source (rev 4f19923884b5) with no errors, but it won't connect 
to DF.
I tried adding the extra ini's in this issue but they didn't seem to have any 
effect.

Attached are logs from ldd and DT, hope they help out. Thanks :)

Original comment by haeske...@gmail.com on 22 Feb 2012 at 7:32

Attachments:

• ldd.log
• run.log

[GoogleCodeExporter]

I had this connection problem with 2 instances of DF running (one was not 
terminated and still running in background). Check that you have only one DF 
running in your processes.

Original comment by hic...@gmail.com on 22 Feb 2012 at 8:43

[GoogleCodeExporter]

From the run.log file, it does indeed look like two instances of DF are running.

If that's not the case, go ahead and create an strace log (strace -f -o 
strace-dt.log bin/release/DwarfTherapist or so)

Original comment by Kionm...@gmail.com on 22 Feb 2012 at 4:13

[GoogleCodeExporter]

I just tried it again with strace running. I looked at my processes 
before/during/after, there were no DT processes before starting strace.
DT started and spawned 4 processes, when I quit DT it closed all of them.

strace logs attached

Original comment by haeske...@gmail.com on 22 Feb 2012 at 10:24

Attachments:

• strace-dt.log
• strace-dt_2.log

[GoogleCodeExporter]

I came across the won't connect issue as well (running Mint 12).  Since I was 
running from the command line I noticed it spat out the error message "ptrace 
attach: Operation not permitted".  A quick Google later and I was here 
http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process 
Solutions I see
1. Run DT as root or sudo
2. Use either the temporary or permanent fix in the linked article.
3. Ask a nice person to add a "Launch DF" button to DT.

Original comment by nick31...@gmail.com on 23 Feb 2012 at 4:02

[GoogleCodeExporter]

While the "Launch DF" option would be nice (and never thought of that myself), 
I can connect to DF, but it just cant read the dwarfs. Whenever I try to read 
them it tells me I have closed DF or unloaded my game (which i hadn't). This 
happens with ptrace on/off, running with sudo or just user.

Original comment by Shad...@gmail.com on 23 Feb 2012 at 4:19

[GoogleCodeExporter]

Confirming running DT with sudo works perfectly, reads/writes jobs fine. :)

Original comment by haeske...@gmail.com on 23 Feb 2012 at 5:17

[GoogleCodeExporter]

I built DF from source (changeset:   515:4f19923884b5) in debian/wheezy
I used the v0.34.02.ini from Kionm...@gmail.com with DF v0.34.02

reading/writing of jobs seems to work, but DT got at least one name wrong. 
The name of that dwarf is not listet by DT. A dwarf in DT with the right skills 
is listed by DT with a name, no dwarf in the game has.

Original comment by thuelsem...@googlemail.com on 24 Feb 2012 at 11:35

[GoogleCodeExporter]

That'd probably be a vampire, iirc. :)

Original comment by Kionm...@gmail.com on 24 Feb 2012 at 11:38

[GoogleCodeExporter]

@Haeske, yeah, you were getting ENOPERM -1 when trying to ptrace.. The odd 
entry in the logs is because DT was then trying to open /proc/$(DF-pid)/mem, 
and didn't receive an error until it tried to do an actual read from the 
process memory.

@nick31, what happens if you use a bash script.. Something like (copy/paste 
this into a console window to magically create the script, assuming that you're 
in a directory that contains both df_linux and dwarftherapist trees)

touch df-dt.sh
cat - >> df-dt.sh << EOF
#!/bin/bash
(cd df_linux; ./df)&
(cd dwarftherapist; ./bin/release/DwarfTherapist)&
EOF
chmod 0700 df-dt.sh

My suspicion is that both threads, as they're now child threads of the same 
shell instance, will be able to ptrace since they should be in-scope..

Original comment by Kionm...@gmail.com on 24 Feb 2012 at 11:52

[GoogleCodeExporter]

@Kionm,  no luck with that script, I even stuck a launch delay on DT so I could 
get into DF and load a game.  My interpretation of of the ptrace security 
lockout it that DF needs to be a child process of DT, not a sibling.

I've attached the run log if that helps anyone.  I shall continue using the 
work-arounds.

Original comment by nick31...@gmail.com on 24 Feb 2012 at 12:33

Attachments:

• run.log

[GoogleCodeExporter]

I've been running with the ini from comment 7; seems to work fine except for 
the migration wave numbers. 64-bit ubuntu 11.10.

Original comment by rws...@gmail.com on 24 Feb 2012 at 1:36

[GoogleCodeExporter]

@rws - You'll either need to use issue 382 (If that's the kind of migration 
wave issue you're seeing) or you'll need to open a new issue. Please note, dt 
0.6.12 is compatible with df v0.34.0x, not with v0.31.xx versions as the way 
migration waves are tracked had to be changed since we're now getting 
historical dwarves migrating.

Original comment by Kionm...@gmail.com on 24 Feb 2012 at 10:55

[GoogleCodeExporter]

@nick31: It's possible to construct a script that lets DT be the parent process 
of DF, through exec.  Here's the one I use:

#!/bin/bash
(
  cd $(dirname "$0")/df_linux
  ./df &
  sleep 15
  cd ../therapist/
  exec ./bin/release/DwarfTherapist
) &

Original comment by esw...@gmail.com on 29 Feb 2012 at 5:51

[GoogleCodeExporter]

@esw - thanks for that, it worked a treat, although the last cd needs to be 
changed if you build from source.
This issue ought to affect all Ubuntu derived distros, and probably some 
others, so it'd be quite nice to have a variant on this script added to the 
source tree, or at least a comment put in the linux readme (I've got no idea 
how to go about this, or even if the devs are happy to have some random guy off 
the forums start adding code).

Original comment by nick31...@gmail.com on 1 Mar 2012 at 10:33

[GoogleCodeExporter]

Here's "worksforme" memory layout for v0.34.04. 
taken from this post 
http://www.bay12forums.com/smf/index.php?topic=66525.msg3047415#msg3047415

Original comment by pzskc...@gmail.com on 3 Mar 2012 at 4:55

Attachments:

• v0.34.04.ini

[GoogleCodeExporter]

Are there still problem with migration wave numbers and stuff?

Original comment by Yabo...@gmail.com on 3 Mar 2012 at 11:23

[GoogleCodeExporter]

Going to mark this as done. The ubuntu repository has been rebuilt, and OSX dmg 
is in beta on the downloads page. If you have issues with specific releases 
from this point forward, please open separate issues.

Original comment by ehler...@gmail.com on 5 Mar 2012 at 4:13

• Changed state: Done

[GoogleCodeExporter]

Can the other versions of the ini file in this ticket be checked into mecurial 
and not just 34.04?

Original comment by jjc...@gmail.com on 6 Mar 2012 at 2:30