Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0002688Dwarf FortressInit Optionspublic2010-07-14 03:142018-05-27 11:57
Toady One 
0002688: Not found: data/art/curses_640x300.png (32-bit Linux DF)
I could have sworn I had dwarf fortress running at one point. Maybe it was all a dream.

Anyway. At first I was getting the "Not found: data/art/curses_640x300.png" error. I changed all occurrences of ".png" to ".bmp" in data/init/interface.txt

Now I'm getting the mouse.png not found error. Setting "[MOUSE:NO]" and "[MOUSE_PICTURE:NO]" doesn't fix it.

Just a heads up.
Try to run ./df
I have libpng, sdl-image, and all other necessary requirements. This is a 64bit system, so maybe it's unsupported. Either way, there are no 32bit builds of any of the above packages for Gentoo.
0.44.10, 32-bit DF only
has duplicate 0006506resolved Footkerchief Tileset not found: data/art/curses_640_300.png 
has duplicate 0006739resolved lethosor Tileset not found 
has duplicate 0007675resolved Footkerchief Unable to locate theme engine in module_path: "murrine" 
has duplicate 0007772resolved Dwarfu Not found: data/art/mouse.png 
has duplicate 0007970resolved Footkerchief Game play controls do not match "interface.txt" 
has duplicate 0010771resolved lethosor libgraphics.so has no dependency on libz.so.1 in the 32 bit build 
has duplicate 0011562resolved lethosor Not found: data/art/curses_640x300.png 
related to 0006147new  Not found: data/art/curses_640x300.png 
Issue History
2010-07-14 03:14gone404New Issue
2010-07-14 07:25FootkerchiefNote Added: 0010232
2010-07-14 07:25FootkerchiefTag Attached: AWAITING UPDATE
2010-08-07 10:48FootkerchiefNote Added: 0011599
2010-08-07 14:58gone404Note Added: 0011611
2010-08-07 14:58gone404Note Edited: 0011611bug_revision_view_page.php?bugnote_id=0011611#r4531
2010-08-07 15:08gone404Note Added: 0011613
2010-08-07 15:13gone404Note Edited: 0011613bug_revision_view_page.php?bugnote_id=0011613#r4533
2010-08-07 16:21FootkerchiefIssue Monitored: Baughn
2010-08-07 16:21FootkerchiefNote Added: 0011616
2010-08-07 16:21FootkerchiefTag Detached: AWAITING UPDATE
2010-08-08 13:59gone404Note Added: 0011635
2013-05-04 07:23tsesterNote Added: 0023954
2013-05-04 07:24tsesterNote Deleted: 0023954
2013-05-04 07:25tsesterNote Added: 0023955
2014-03-21 07:39agNote Added: 0024614
2014-03-25 18:41DwarfuAssigned To => Dwarfu
2014-03-25 18:41DwarfuStatusnew => confirmed
2014-03-25 18:42DwarfuStatusconfirmed => acknowledged
2014-03-25 23:32agIssue Monitored: ag
2014-04-18 11:01Nonno CicalaNote Added: 0024710
2014-06-15 00:59FootkerchiefRelationship addedhas duplicate 0006506
2014-07-08 20:27lethosorRelationship addedhas duplicate 0006739
2014-07-08 20:27lethosorIssue Monitored: smickles
2014-07-10 15:35lueNote Added: 0025608
2014-07-15 06:43Nonno CicalaIssue Monitored: Nonno Cicala
2014-07-15 07:03nekoxmachinaNote Added: 0026461
2014-07-15 11:15agNote Added: 0026503
2014-07-23 15:12djsmiley2kNote Added: 0027357
2014-07-28 00:56FootkerchiefRelationship addedhas duplicate 0007675
2014-07-29 14:16Hello71Note Added: 0027897
2014-07-29 14:16Hello71Issue Monitored: Hello71
2014-08-01 05:16DwarfuRelationship addedhas duplicate 0007772
2014-08-12 12:39FootkerchiefRelationship addedhas duplicate 0007970
2014-08-18 11:45FootkerchiefSummaryNot found: data/art/mouse.png => Not found: data/art/curses_640x300.png
2014-10-24 12:28lethosorStatusacknowledged => confirmed
2014-11-21 22:01Khym ChanurNote Added: 0031110
2014-11-21 22:01Khym ChanurTag Attached: Probable Quick Fix
2015-03-02 20:03lethosorRelationship addedrelated to 0006147
2015-03-02 20:04lethosorTag Detached: Probable Quick Fix
2015-03-03 17:37QuietustNote Added: 0032322
2016-06-09 05:41braiamNote Added: 0035380
2016-06-09 08:32lethosorNote Added: 0035382
2016-08-22 14:34lethosorNote Added: 0035803
2016-08-22 14:34lethosorAssigned ToDwarfu => lethosor
2016-08-22 14:34lethosorStatusconfirmed => needs feedback
2016-08-24 15:38Max_TMNote Added: 0035806
2016-08-25 14:27braiamNote Added: 0035809
2018-04-10 10:36lethosorNote Added: 0038149
2018-04-10 10:36lethosorStatusneeds feedback => resolved
2018-04-10 10:36lethosorFixed in Version => 0.43.05
2018-04-10 10:36lethosorResolutionopen => fixed
2018-04-10 10:36lethosorStatusresolved => assigned
2018-04-10 10:36lethosorAssigned Tolethosor => Toady One
2018-04-10 10:36lethosorStatusassigned => resolved
2018-05-27 11:55lethosorRelationship addedhas duplicate 0010771
2018-05-27 11:56lethosorNote Added: 0038386
2018-05-27 11:56lethosorStatusresolved => needs feedback
2018-05-27 11:56lethosorResolutionfixed => reopened
2018-05-27 11:57lethosorStatusneeds feedback => acknowledged
2018-05-27 11:57lethosorTag Attached: 0.44.10
2018-05-27 11:57lethosorSummaryNot found: data/art/curses_640x300.png => Not found: data/art/curses_640x300.png (32-bit Linux DF)
2018-05-27 11:57lethosorTag Attached: 32-bit DF only
2018-05-31 09:33kritzefitzIssue Monitored: kritzefitz
2018-05-31 09:33kritzefitzIssue End Monitor: kritzefitz
2018-05-31 09:34kritzefitzIssue Monitored: kritzefitz
2020-06-21 09:44lethosorRelationship addedhas duplicate 0011562

2010-07-14 07:25   
I changed all occurrences of ".png" to ".bmp" in data/init/interface.txt

Did you mean init.txt?
2010-08-07 10:48   
Reminder sent to: gone404

Is this error still present in 31.12?
2010-08-07 14:58   
I did mean init.txt.

Error is still present (df_31_12_linux.tar.bz2). Changing all occurances of .png to .bmp gets rid of the curses_640x300 error. But the "Not found: data/art/mouse.png" error still comes up. This happens whether [MOUSE] is set to "YES" or "NO"

I've also tried running ./libs/DwarfFortess directly as well as executing df with a full path. Nothing seems to help.

2010-08-07 15:08   
(edited on: 2010-08-07 15:13)
Update: Hex editing df_linux/libs/DwarfFortress and replacing "mouse.png" with "mouse.bmp" lets me run DwarfFortress!

It was a bit of a crapshoot, but luckily the reference was a string in the binary.

Cool intro by the way =)

NOTE: I had to set MOUSE_PICTURE:NO because the ax cursor was blank when mousing into the df window.

2010-08-07 16:21   
Reminder sent to: Baughn

Hey Baughn, any input on this one? gone404 did some testing (see above) which may shed some light on the problem.
2010-08-08 13:59   
It seems like an issue with png processing. I've been testing tilesets and raw/graphics/ packs (mayday). Nothing works until I change the the images to bitmaps and update the references accordingly.
2013-05-04 07:25   
i have similar problem
OS: ArchLinux 64 bit
df: 0.34.11-2 (arch package) 0.34.11 (official package)

resolution: delete all png, link all bmp to respective names ending in png
2014-03-21 07:39   
So, I got this same problem after upgrading to Fedora 20, and investigated it.

It seems, libgraphics.so from DF statically links to zlib and exports all of its symbols, so the system's libpng ends up calling the functions in libgraphics instead of the system zlib. Apparently something changed in the zlib API recently, and recent libpng versions rely on it, so on an up to date system it fails to work.

A solution I found is to preload the system zlib, so that it has priority over libgraphics:

export LD_PRELOAD=/usr/lib/libz.so.1
Nonno Cicala   
2014-04-18 11:01   
Thank you ag!

LD_PRELOAD=/lib32/libz.so.1 ./df

worked for me on Gentoo!
2014-07-10 15:35   
This is still an issue on 0.40.01 and 0.40.02 (and was an issue with me with 0.34.11 days before 0.40.01 was released).

I am on Gentoo using emul-linux-x86-baselibs 20140406-r4, which provides me with 32-bit libpng and libz libraries. Using the LD_PRELOAD given in the previous note throws a couple of "ERROR: ld.so: object '/lib32/libz.so.1' from LD_PRELOAD cannot be preloaded: ignored." but otherwise runs fine.

Trying to specify /usr/lib32/libz.so interestingly causes the fatal error to occur, despite it also being installed by that emul-linux package. Not sure why this is, but I should note that I have libpng libraries in /usr/lib32, while not having them in /lib32

That's about all I can find at the moment, hope it's helpful in some fashion.
2014-07-15 07:03   
>Trying to specify /usr/lib32/libz.so interestingly causes the fatal error to occur, despite it also being installed by that emul-linux package. Not sure why this is, but I should note that I have libpng libraries in /usr/lib32, while not having them in /lib32

1) Over /usr/lib32/libz.so fatal issue:
On gentoo, libz.so is ascii file with 'GNU ld script' inside.
neko@laptop : ~
[0] % file /usr/lib32/libz.so
/usr/lib32/libz.so: ASCII text

2) Over LD_PRELOAD issue:
This is because you have 64bit environment at the moment of the script (df) launch.
ld is smart & won't preload wrong architecture library for you.
your /bin/sh is 64bit, library is 32bit, script is executed with /bin/sh, thus problems.
However it is unclear why, while LD_PRELOAD doesn't preload the library, it fixes the issue for you.
2014-07-15 11:15   
Because LD_PRELOAD independently applies to every process that is started by the command, so /bin/sh complains, but the actual DF executable doesn't even know about that and works.
2014-07-23 15:12   
On gentoo I've had to add

export LD_PRELOAD=/lib32/libz.so.1 libs/Dwarf_Fortress #gentoo hax

and then it works normally as far as I can tell.
2014-07-29 14:16   
recompiling libgraphics.so also works (obviously)
Khym Chanur   
2014-11-21 22:01   
I've modified the Linux df script so that it should work under most 64 bit Linux systems. See http://pastebin.com/Rkv5WKXz [^]
2015-03-03 17:37   
This issue should not be confused with 0006147 - despite having the exact same title, this one applies to Linux while the other one applies to Windows (and is actually a totally different problem).
2016-06-09 05:41   
On Debian the library is in `/lib/i386-linux-gnu`, so adding that to Khym script should work for Debian derivatives http://pastebin.com/733uamx2. [^]

As far I know, the dynamic linker should have found it as ldd output shows:

ldd df_linux/libs/Dwarf_Fortress | grep libz
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf62ad000)

But `ld ./libs/DwarfFortress` throws:

➜ ~ ld df_linux/libs/Dwarf_Fortress
ld: i386 architecture of input file `df_linux/libs/Dwarf_Fortress' is incompatible with i386:x86-64 output
ld: error in df_linux/libs/Dwarf_Fortress(.eh_frame); no .eh_frame_hdr table will be created.
ld: warning: cannot find entry symbol _start; defaulting to 0000000000404a20

Which according to this http://stackoverflow.com/q/19200333/792066 [^] some emulation should be used. Since the compiler is new, I presume Toady hasn't been able to get around it, yet.
2016-06-09 08:32   
The compiler hasn't changed since around 2010, so I don't know what you mean. There's no need for emulation. Does actually running DF work?
2016-08-22 14:34   
Okay, now Toady has upgraded his Linux toolchain. Is this still an issue with DF 0.43.05? I was able to run both builds on Ubuntu 16.04, but I haven't tried other distros.
2016-08-24 15:38   
Worked for me on Arch straight from him, no more editing the executable with vim until the arch build is ready!
2016-08-25 14:27   
I swear I responded to lethosor comment... yes, it works without a hitch on a Debian testing. The user only needs to install the libraries, not even the 32-bit build, but the 64-bit ones.
2018-04-10 10:36   
Okay, thanks, we'll call it fixed in 0.43.05, then. PM a manager on the forums if it persists in anything newer than that.
2018-05-27 11:56   
Reopening per 0010771

Possibly missing an "-lz" in the build script, from what I understand.