Ticket #29749 (closed defect: fixed)
libdevil 1.7.8_2 refers to deprecated and removed function in libpng
| Reported by: | daftalx@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.2 |
| Keywords: | png | Cc: | ryandesign@… |
| Port: | libdevil |
Description
while running a code dependent on libdevil, I get:
15:39:49: Error: dlopen(/opt/local/lib/libunitsync.so, 2): Symbol not found: _png_set_gray_1_2_4_to_8 Referenced from: /opt/local/lib/libIL.1.dylib Expected in: flat namespace in /opt/local/lib/libIL.1.dylib
Further reading got me to: "png_set_gray_1_2_4_to_8" was deprecated and REMOVED in libpng 1.4 and replaced with "png_set_expand_gray_1_2_4_to_8". MacPorts has libpng 1.4.7.
Attachments
Change History
comment:3 in reply to: ↑ description ; follow-up: ↓ 4 Changed 2 years ago by ryandesign@…
Replying to daftalx@…:
while running a code dependent on libdevil, I get:
libdevil compiles fine for me. If the problem only appears when "running code dependent on libdevil", can you provide an example of this that I could use as a test case?
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 2 years ago by daftalx@…
Replying to ryandesign@…:
libdevil compiles fine for me. If the problem only appears when "running code dependent on libdevil", can you provide an example of this that I could use as a test case?
Same here, libdevil compiles fine, which makes little sense to me, since il_png.c includes "png.h" in order to call the old "png_set_gray_1_2_4_to_8", while "png.h" no longer references this method (other than in the comments where they say it's been deprecated and replaced by the other one). Could there be another (outdated) png.h outside MacPorts on Mac OS ?
Haven't got an easy sample code right here, but a simple use case would be to call the ILboolean readpng_get_image(ILdouble display_exponent) function, which calls "png_set_gray_1_2_4_to_8" (line 281 of il_png.c) in the specific case that your input PNG file is grayscale and has less than 8bit precision.
comment:5 in reply to: ↑ 4 Changed 2 years ago by daftalx@…
I mean, as an easy-but-dirty fix, a quick patch to this particular line after fetch would solve the problem here (though indeed not upstream, but if DevIL is not very active these days, that'll do, right ?)
comment:6 Changed 2 years ago by ryandesign@…
Yes, a local patch in MacPorts is fine for now, until the developers can apply it to their sources. But before I would commit such a patch, I would want to verify the issue, and verify the patch fixes it. That means I need a set of commands I can type in my terminal that demonstrate the problem. I am not a C programmer; if you are, can you supply a program that calls this function you mentioned, and instructions on how to compile and use it? Regarding the specific type of input file you suggest using with it, can you supply such an image?
comment:7 Changed 22 months ago by daftalx@…
didn't have time to actually write specific code for the issue, but i forked the Portfile on my repo (rsync://daftserve.dyndns.org/macports) and patched the necessary files locally (2), the dependent project now works as expected. should I send the Portfile / files somewhere ?
comment:8 follow-up: ↓ 9 Changed 22 months ago by ryandesign@…
Yes, please attach your Portfile diff and your patchfiles to this ticket.
comment:9 in reply to: ↑ 8 Changed 22 months ago by daftalx@…
Replying to ryandesign@…:
Yes, please attach your Portfile diff and your patchfiles to this ticket.
sorry, attached before reading your text. The attached Portfile can be removed, I also removed a comment I added in the description to remember what I did
comment:10 Changed 22 months ago by ryandesign@…
- Status changed from new to closed
- Resolution set to fixed
Thanks very much!

