0002688: Not found: data/art/curses_640x300.png (32-bit Linux DF)

(0010232)
Footkerchief (manager)
2010-07-14 07:25

I changed all occurrences of ".png" to ".bmp" in data/init/interface.txt

Did you mean init.txt?

(0011599)
Footkerchief (manager)
2010-08-07 10:48

Reminder sent to: gone404

Is this error still present in 31.12?

(0011611)
gone404 (reporter)
2010-08-07 14:58
edited on: 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.

(0011613)
gone404 (reporter)
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.

(0011616)
Footkerchief (manager)
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.

(0011635)
gone404 (reporter)
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.

(0023955)
tsester (reporter)
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

(0024614)
ag (reporter)
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

(0024710)
Nonno Cicala (reporter)
2014-04-18 11:01

Thank you ag!

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

worked for me on Gentoo!

(0025608)
lue (reporter)
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.

(0026461)
nekoxmachina (reporter)
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.
:)

(0026503)
ag (reporter)
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.

(0027357)
djsmiley2k (reporter)
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.

(0027897)
Hello71 (reporter)
2014-07-29 14:16

recompiling libgraphics.so also works (obviously)

(0031110)
Khym Chanur (reporter)
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 [^]

(0032322)
Quietust (reporter)
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).

(0035380)
braiam (reporter)
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.

(0035382)
lethosor (manager)
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?

(0035803)
lethosor (manager)
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.

(0035806)
Max_TM (reporter)
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!

(0035809)
braiam (reporter)
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.

(0038149)
lethosor (manager)
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.

(0038386)
lethosor (manager)
2018-05-27 11:56

Reopening per 0010771

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

Issue History
Date Modified	Username	Field	Change
2010-07-14 03:14	gone404	New Issue
2010-07-14 07:25	Footkerchief	Note Added: 0010232
2010-07-14 07:25	Footkerchief	Tag Attached: AWAITING UPDATE
2010-08-07 10:48	Footkerchief	Note Added: 0011599
2010-08-07 14:58	gone404	Note Added: 0011611
2010-08-07 14:58	gone404	Note Edited: 0011611	View Revisions
2010-08-07 15:08	gone404	Note Added: 0011613
2010-08-07 15:13	gone404	Note Edited: 0011613	View Revisions
2010-08-07 16:21	Footkerchief	Issue Monitored: Baughn
2010-08-07 16:21	Footkerchief	Note Added: 0011616
2010-08-07 16:21	Footkerchief	Tag Detached: AWAITING UPDATE
2010-08-08 13:59	gone404	Note Added: 0011635
2013-05-04 07:23	tsester	Note Added: 0023954
2013-05-04 07:24	tsester	Note Deleted: 0023954
2013-05-04 07:25	tsester	Note Added: 0023955
2014-03-21 07:39	ag	Note Added: 0024614
2014-03-25 18:41	Dwarfu	Assigned To	=> Dwarfu
2014-03-25 18:41	Dwarfu	Status	new => confirmed
2014-03-25 18:42	Dwarfu	Status	confirmed => acknowledged
2014-03-25 23:32	ag	Issue Monitored: ag
2014-04-18 11:01	Nonno Cicala	Note Added: 0024710
2014-06-15 00:59	Footkerchief	Relationship added	has duplicate 0006506
2014-07-08 20:27	lethosor	Relationship added	has duplicate 0006739
2014-07-08 20:27	lethosor	Issue Monitored: smickles
2014-07-10 15:35	lue	Note Added: 0025608
2014-07-15 06:43	Nonno Cicala	Issue Monitored: Nonno Cicala
2014-07-15 07:03	nekoxmachina	Note Added: 0026461
2014-07-15 11:15	ag	Note Added: 0026503
2014-07-23 15:12	djsmiley2k	Note Added: 0027357
2014-07-28 00:56	Footkerchief	Relationship added	has duplicate 0007675
2014-07-29 14:16	Hello71	Note Added: 0027897
2014-07-29 14:16	Hello71	Issue Monitored: Hello71
2014-08-01 05:16	Dwarfu	Relationship added	has duplicate 0007772
2014-08-12 12:39	Footkerchief	Relationship added	has duplicate 0007970
2014-08-18 11:45	Footkerchief	Summary	Not found: data/art/mouse.png => Not found: data/art/curses_640x300.png
2014-10-24 12:28	lethosor	Status	acknowledged => confirmed
2014-11-21 22:01	Khym Chanur	Note Added: 0031110
2014-11-21 22:01	Khym Chanur	Tag Attached: Probable Quick Fix
2015-03-02 20:03	lethosor	Relationship added	related to 0006147
2015-03-02 20:04	lethosor	Tag Detached: Probable Quick Fix
2015-03-03 17:37	Quietust	Note Added: 0032322
2016-06-09 05:41	braiam	Note Added: 0035380
2016-06-09 08:32	lethosor	Note Added: 0035382
2016-08-22 14:34	lethosor	Note Added: 0035803
2016-08-22 14:34	lethosor	Assigned To	Dwarfu => lethosor
2016-08-22 14:34	lethosor	Status	confirmed => needs feedback
2016-08-24 15:38	Max_TM	Note Added: 0035806
2016-08-25 14:27	braiam	Note Added: 0035809
2018-04-10 10:36	lethosor	Note Added: 0038149
2018-04-10 10:36	lethosor	Status	needs feedback => resolved
2018-04-10 10:36	lethosor	Fixed in Version	=> 0.43.05
2018-04-10 10:36	lethosor	Resolution	open => fixed
2018-04-10 10:36	lethosor	Status	resolved => assigned
2018-04-10 10:36	lethosor	Assigned To	lethosor => Toady One
2018-04-10 10:36	lethosor	Status	assigned => resolved
2018-05-27 11:55	lethosor	Relationship added	has duplicate 0010771
2018-05-27 11:56	lethosor	Note Added: 0038386
2018-05-27 11:56	lethosor	Status	resolved => needs feedback
2018-05-27 11:56	lethosor	Resolution	fixed => reopened
2018-05-27 11:57	lethosor	Status	needs feedback => acknowledged
2018-05-27 11:57	lethosor	Tag Attached: 0.44.10
2018-05-27 11:57	lethosor	Summary	Not found: data/art/curses_640x300.png => Not found: data/art/curses_640x300.png (32-bit Linux DF)
2018-05-27 11:57	lethosor	Tag Attached: 32-bit DF only
2018-05-31 09:33	kritzefitz	Issue Monitored: kritzefitz
2018-05-31 09:33	kritzefitz	Issue End Monitor: kritzefitz
2018-05-31 09:34	kritzefitz	Issue Monitored: kritzefitz
2020-06-21 09:44	lethosor	Relationship added	has duplicate 0011562

Notes
(0010232) Footkerchief (manager) 2010-07-14 07:25	I changed all occurrences of ".png" to ".bmp" in data/init/interface.txt Did you mean init.txt?

(0011599) Footkerchief (manager) 2010-08-07 10:48	Reminder sent to: gone404 Is this error still present in 31.12?

(0011611) gone404 (reporter) 2010-08-07 14:58 edited on: 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.

(0011613) gone404 (reporter) 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.

(0011616) Footkerchief (manager) 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.

(0011635) gone404 (reporter) 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.

(0023955) tsester (reporter) 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

(0024614) ag (reporter) 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

(0024710) Nonno Cicala (reporter) 2014-04-18 11:01	Thank you ag! LD_PRELOAD=/lib32/libz.so.1 ./df worked for me on Gentoo!

(0025608) lue (reporter) 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.

(0026461) nekoxmachina (reporter) 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. :)

(0026503) ag (reporter) 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.

(0027357) djsmiley2k (reporter) 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.

(0027897) Hello71 (reporter) 2014-07-29 14:16	recompiling libgraphics.so also works (obviously)

(0031110) Khym Chanur (reporter) 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 [^]

(0032322) Quietust (reporter) 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).

(0035380) braiam (reporter) 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.

(0035382) lethosor (manager) 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?

(0035803) lethosor (manager) 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.

(0035806) Max_TM (reporter) 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!

(0035809) braiam (reporter) 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.

(0038149) lethosor (manager) 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.

(0038386) lethosor (manager) 2018-05-27 11:56	Reopening per 0010771 Possibly missing an "-lz" in the build script, from what I understand.