Windows 10 Build Issue (CR LF)

[adamchang2000]

https://stackoverflow.com/questions/59547342/libpng-building-issue-on-windows-10

I used the fix described in this Stack Overflow post, changing the line endings of scripts/pnglibconf.dfda from CR LF to LF.

Is there a fix for this?

[benkasminbullock]

Looking at pnglibconf.dfa with hexdump -C cloned from this repository, I get

00000000  23 20 73 63 72 69 70 74  73 2f 70 6e 67 6c 69 62  |# scripts/pnglib|
00000010  63 6f 6e 66 2e 64 66 61  20 2d 20 6c 69 62 72 61  |conf.dfa - libra|
00000020  72 79 20 62 75 69 6c 64  20 63 6f 6e 66 69 67 75  |ry build configu|
00000030  72 61 74 69 6f 6e 20 63  6f 6e 74 72 6f 6c 0a 23  |ration control.#|
00000040  0a 40 2f 2a 2d 20 70 6e  67 6c 69 62 63 6f 6e 66  |.@/*- pnglibconf|
00000050  2e 64 66 6e 20 69 6e 74  65 72 6d 65 64 69 61 74  |.dfn intermediat|
00000060  65 20 66 69 6c 65 0a 40  20 2a 20 20 67 65 6e 65  |e file.@ *  gene|

Here the 0a indicates that it has only LF line endings (ASCII 10). So what you have got is probably the file from lpng1637.zip, which is a file generated from the repository with all the line endings changed over, rather than the original repo file.

What I suggest is that you download the original file from the github repo and use that.

Assuming that I'm right about the origin of the file, it is a bug in libpng where it's generating the file and changing the line ending when it shouldn't, so please don't close this until that bug is fixed.

[adamchang2000]

When I run hexdump -C I see the same result as you with 0a's. However, opening the file in Notepad++ indicates that the file has CR LF line endings. Changing the line endings to LF inside Notepad++ doesn't affect the 0a's in the hexdump.

By the way, the way I'm retrieving libpng is through the CMake ExternalProject module:

ExternalProject_Add(
    ext_libpng
    PREFIX libpng
    GIT_REPOSITORY https://github.com/glennrp/libpng.git
    GIT_TAG v1.6.37
    UPDATE_COMMAND ""
    CMAKE_ARGS
        -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
        -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
        -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
        -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
        -DCMAKE_POSITION_INDEPENDENT_CODE=ON
        -DPNG_SHARED=OFF
        -DPNG_EXECUTABLES=OFF
        -DPNG_TESTS=OFF
        -DPNG_BUILD_ZLIB=ON
        -DZLIB_INCLUDE_DIR=${ZLIB_INCLUDE_DIRS}
    BUILD_ALWAYS ON
)

[benkasminbullock]

When I run hexdump -C I see the same result as you with 0a's.

OK but CR is 0d (13) so even if you see the Oa if it is not exactly the same as the one I quoted you might have CR too.

However, opening the file in Notepad++ indicates that the file has CR LF line endings.

The file in the repo does not have CR LF line endings, and you've stated that you see the same result as me with hexdump, so you are contradicting yourself.

Changing the line endings to LF inside Notepad++ doesn't affect the 0a's in the hexdump.

If you change the file in Notepad++ and save it and then see no difference in the hexdump that indicates a problem in Notepad++ rather than in libpng.

By the way, the way I'm retrieving libpng is through the CMake ExternalProject module:

It's probably better to install it from the tar file than from github, the github repo has unfixed bugs.

[adamchang2000]

Sorry, I don't really know what to look for in the hexdump's. I was just remarking that the 0a's exist before and after changing from CR LF to LF and I guess that's expected based on your reply.

Okay, I'll avoid directly cloning the repository on Windows for now.

[code-affinity]

This issue also causes build failures under XCode, with exactly the same error message.

I ran across this problem while building a downstream product: The latest ImageMagick source distribution includes a snapshot of libpng that has this bug. There are many other files in the scripts/ subdirectory of source distribution that have incorrect line endings. I don't know if the line ending discrepancy was introduced in libpng itself, or in the ImageMagick snapshot of libpng.

[Edit: I may not be right when I say that the files have the incorrect line endings. What I can say is that many of the script files have different line endings in ImageMagick's latest snapshot of libpng (a snapshot of 1.6.37) than they had in an older ImageMagick snapshot of libpng (a snapshot of 1.6.34). I discovered this problem after upgrading ImageMagick. I don't see any changes in the libpng history of the affected files that change the line endings, so maybe it just an artifact of the process that builds the lpng1637.zip file that @benkasminbullock referred to above. I don't know how to track that down.]