No custom professions in Linux64

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Builed the latest on (gentoo) amd64 system.
2.load any fort, new or old.
3.Create a custom profession and add dorfs to it.

What is the expected output? What do you see instead?
In the windows version it changes 'jeweler' or 'trapper' to '<custom name>'

What version of the product are you using? On what operating system?
I did a checkout about 3-4 days ago from the repo. Im running gentoo amd64

Please provide the "run.log" file in the "log" directory of DwarfTherapist when 
this error occurred.

first i should point out "libgnomesegvhandler.so: cannot open shared object 
file: No such file or directory"

If this is a truly "crazy" issue, please also attach a copy of your save-
game.

Original issue reported on code.google.com by pfifo.f...@gmail.com on 7 Apr 2011 at 1:57

• Merged into: #175

Attachments:

• run.log

[GoogleCodeExporter]

A small clarification about #2, if I try to change Urist McGemCutter to a 
custom profession I made, he remains in the jewelers profession. Of the several 
ways to go about setting custom professions none of them get my dwarves 
organized.

Original comment by pfifo.f...@gmail.com on 7 Apr 2011 at 2:00

[GoogleCodeExporter]

`emerge bug-buddy` installed libgnomesegvhandler.so

Im currently trying to patch this, but im a C programmer, and rarely play with 
C++. And don't even get me started on windows programs... ugh

Original comment by pfifo.f...@gmail.com on 9 Apr 2011 at 11:32

[GoogleCodeExporter]

OK I have given up, this is being caused because memory address in 64 bit 
are... well 64 bits!! I dont think anything less than an entire rewrite of the 
program will fix this. Luckily for us we can cross-compile a working 32bit 
version.

Original comment by pfifo.f...@gmail.com on 9 Apr 2011 at 11:56

[GoogleCodeExporter]

I just wanted to give an update of what I have found so far, 64bit anything 
isnt a problem. the First issue is that the data stored in the memory for Urist 
McCatButcher is not his actual nickname/profession, rather it is a pointer to a 
char array, By default everyones nick/prof points to some default area of 
memory, so when I tried simply changing its value , everry dwarf on the map 
instantly had the nickname 'test' and were all in the 'test' profession.

Upon giving a single dwarf a custom profession in game, I could then change his 
to anything I wanted with dwarf therapist. However, I cannot find the place 
where the string length is stored. so I set his custom profession in game to 
'foobar' and then in DT I changed it to 'deadbeef', but what ended up happening 
is that in game his profession showed as 'deadbe' cause the string length was 
set to 6.

Im currently writing some code to try and interrupt the game, and call whatever 
function the game uses to set custom strings. however this is an amazingly 
daunting task as Im no assembly programmer and have never used gdb todo such a 
task.

Original comment by pfifo.f...@gmail.com on 11 Apr 2011 at 6:58

[GoogleCodeExporter]

Yeah those are actually std::string pointers you're seeing. Since they are 
generally heap variables, you're going to have a hard time completely 
replicating a std::string if you just treat it like a char**.

On windows this is a bit easier, as MSVC pre-allocates 16 bytes per 
std::string. So on windows you're always sure to have at least 15 bytes to work 
with (plus a terminator)

g++ doesn't do this though. This is a long-known issue. You may want to look 
into how dfhack does it (using a shared memory segment via injection in the SDL 
lib, to allocate new heap memory *as DF itself*)

Original comment by treyst...@gmail.com on 11 Apr 2011 at 7:12

[GoogleCodeExporter]

My patches for nicknames over here obviously fix this too:

http://code.google.com/p/dwarftherapist/issues/detail?id=175

Direct code injection is somewhat nasty, but I feel it's in a way less 
complicated than full-blown LD_PRELOAD injection.

Original comment by ANGavri...@gmail.com on 27 Apr 2011 at 4:11

[GoogleCodeExporter]

Rolling this into issue 175.

Original comment by ehler...@gmail.com on 6 Mar 2012 at 2:58

• Changed state: Duplicate