libdevil 1.7.8_2 refers to deprecated and removed function in libpng

[daftalx@…]

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.

[ryandesign (Ryan Carsten Schmidt)]

This is reported upstream ​here and ​here. Unfortunately the developer appears to have no time for DevIL lately.

[ryandesign (Ryan Carsten Schmidt)]

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?

[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.

[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 ?)

[ryandesign (Ryan Carsten Schmidt)]

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?

[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 ?

[ryandesign (Ryan Carsten Schmidt)]

Yes, please attach your Portfile diff and your patchfiles to this ticket.

[daftalx@…]

updated Portfile

[daftalx@…]

(replaces attached Portfile)

[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

[ryandesign (Ryan Carsten Schmidt)]

Thanks very much!