#85 Fix detection of png debug

[tal]

There is a bug, that when you compile GraphicsMagick with debug png, is add also the non debug version of png, leading it that the tests in configure in the check phase, are failed due they don't find the correct library file.
This fix is fixing that.

[Bob Friesenhahn]

Tal, I expect that you would not have submitted this patch unless there is a problem with the very complex libpng configure code. However, the patch seems to be disabling two very important lines of code. I will study the libpng configuration code some more.

Can you please post the output of the configure script when it is encountering the issue that your patch is addressing?

[tal]

I am a vcpkg contribute to graphicsmagick. You add hardcoded the libpng library name. In libpng debug the library name there is a d suffix you ignore, and it already detected before.
This hardcoded library names is done for other libraries as well.

You can learn more from my PR and the next PR that fix it, and take a look on the patches.
You can also comments there, the community will help you understand it better.

Better comment on the second link

https://github.com/microsoft/vcpkg/pull/46725
https://github.com/microsoft/vcpkg/pull/46839

On a side note, please consider to do a mirror repo on github.
It will be easier for other devs to report and share their idea for the project.

You can take for example of octave. It has also a mercury source control (hg), and have a clone in github:

https://github.com/gnu-octave/octave

Thank you for reading my patch.

[Bob Friesenhahn]

Someone did create a git clone of GraphicsMagick Hg, but it requires 1.4GB space! I am not sure how to reduce that without spending a few weeks figuring out how to create a new Hg repository which still contains all of the important history and release tags but with shorter branches. If there is an Hg to Git translator which follows the full chronological revision history (including all branches) rather than converting one branch at a time, then the result would surely be much smaller.

[tal]

When I clone your repo, I use git-remote-hg. Yes it take around 1.7G but this is ok for me.
I ratter use the git, then use the hg.
Why it important for you that it take 1.4G?
Then it give you all the history with all the tags as you see it.
But in mirror is different, when you push a commit in your hg repo, it automatic take the commit and save it on github.

https://githgmirror.com/
https://stackoverflow.com/questions/12559517/how-to-mirror-hg-repo-to-git-repo
https://superuser.com/questions/383366/how-to-make-automatic-git-mirror-for-hg-repo
In general how to do clone in gitgub:

https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository

[Bob Friesenhahn]

To put it in perspective, 1.4G is large enough to support an operating system installation!
Bandwidth is not extremely fast or free for everyone, and so 1.4GB (or 1.7GB) is a huge price to pay as compared with 303MB. The Git repository history is not the same as Hg because each branch was translated/copied independently so the tree history of the merging between the branches (which unfortunately is how I decided to produce releases) is lost.

The GM repository is likely cloned at least tens of times per day. The oss-fuzz builds perform a distinct clone for each fuzzing build variant. From the build logs at https://oss-fuzz-build-logs.storage.googleapis.com/index.html#graphicsmagick I see a Hg clone time of 45 seconds for the default branch (it is often closer to 60). The longer the clone takes, the more likely it is to fail. If I replicate the oss-fuzz build on my personal computer then the clone times might take many times longer (especially if the network round trip times (RTT) is longer), and if the data transfer is not free, I have to pay for it. Of course this is true for others as well.

IMHO, the Hg repository is already much larger than it should be, and it would be smaller except for some (possibly bad, or perhaps wise) decisions made long ago.

[tal]

I don't have now a good answer for you. It needed more time for investigate.
How octave do it? Can you find out?
https://github.com/gnu-octave/octave

[tal]

What about to switch to github? as open source you get everything free, also you can put your website on github
https://docs.github.com/en/pages/quickstart

[Bob Friesenhahn]

Thanks for providing me with some context. Sorry for not replying earlier. I thought that I had replied but found that my message still remained in the browser widow and had not been submitted.

I was not aware that vcpkg was able to support anything other than CMake. It is interesting that you are using the configure-based build. You may have noticed that magick/magick_types.h.in now has no configurable values at all since development GM now requires working C'99 support. It is a goal to reduce the configuration complexity and eventually support alternative build mechanisms such as CMake or meson.

[tal]

You may have noticed that magick/magick_types.h.in now has no configurable values at all since development GM now requires working C'99 support

I notice that, I didn't sure how it will effect vcpkg build. But will deal with that when you do a next release.

It is a goal to reduce the configuration complexity and eventually support alternative build mechanisms such as CMake or meson.

I would love to see your project move to cmake or meson. (and also git ...).

[tal]

If you take a look on my PR, I removed the unofficial cmake build that was before. You can use that as a reference if you are want to go to cmake build.

[Bob Friesenhahn]

Is it correct that the vcpkg build does not support/use pkg-config information?
I did not see any GraphicsMagick configure logs in the two pull requests provided above. Being able to see the intermediate test steps/results in the failing configuration would be useful.

[tal]

vcpkg doese use and support pkg-config information.
I actually switch to built in upstream build system aka configure-based build,
because I want to use the pc file that generate, that I will detected by octave.

On the unofficial cmake, we didn't generate the pc files, we did instead export cmake files that do the equivalent but only with cmake.

What logs are you looking for?
Maybe I can generate it on my local. I have windows and linux.

[tal]

Do you want the logs without the patches? to see what happen? on linux?

[tal]

I cannot repreduce the error on my local, because on my local, on debug it take the release and debug path, and found the release symbol.
On vcpkg ci, it doing correctly, only take the debug path:

this file taken from my PR:
https://github.com/user-attachments/files/21561500/failure.logs.for.x64-linux.zip

Inside the file:
config-x64-linux-dbg-config.log:
see the error that it search for -lpng16 together with -lpng16d
because you hard coded the library name:

configure:27523: checking for jpeg_read_header in -ljpeg
configure:27548: /usr/bin/cc -o conftest -fopenmp -fPIC -g -Wall   -I/mnt/vcpkg-ci/installed/x64-linux/debug/lib/pkgconfig/../../../include -DLZMA_API_STATIC  -I/mnt/vcpkg-ci/installed/x64-linux/debug/lib/pkgconfig/../../../include/libpng16 -L/mnt/vcpkg-ci/installed/x64-linux/debug/lib -L/mnt/vcpkg-ci/installed/x64-linux/debug/lib/pkgconfig/../../lib  conftest.c -ljpeg  -lturbojpeg -lpng16 -lpng16d -lXext  -lSM -lICE -lX11  -llzma -lz -lm  -lpthread >&5
/usr/bin/ld: cannot find -lpng16: No such file or directory
collect2: error: ld returned 1 exit status

This line have multiple times in this file result many undetection for things:
cannot find -lpng16

[Bob Friesenhahn]

The console output from 'configure' as well as the final 'config.log' file would be great.
Are these vcpgk builds (presumably targeting Windows) being done on Linux? If so, that is interesting.

Clearly there is a problem in that PKG_CHECK_MODULES is used to query "libpng" and then it appears to go into detailed code which is testing for specific versions of libpng. What should happen is if pkg-config finds a libpng, then it should use that data rather than then manually trying to determine correct values.

[tal]

The zip file I post here have both configure as well config.log. the names for that is:
config-x64-linux-dbg-out.log
config-x64-linux-dbg-config.log

The log file taken from vcpkg ci, target for linux build on linux.
The PKG_CHECK_MODULES is correct, it taken the correct library name -lpng16d
The wrong is in the lines I comments that take hardcoded name: LIB_PNG="-l${pnglib}"

[Bob Friesenhahn]

A challenge I am seeing is that pkg-config may return results equivalent to (for respective configure sections):

PNG_LIBS=-L/work/lib -lpng16 -lm -lz
FREETYPE_LIBS=-L/work/lib -lfreetype -lbz2 -lpng16 -lm -lz

It is strongly desired to verify that it is possible to successfully link with the added library before deciding to use it, and to verify header inclusion given the provided header search paths. It is necessary for configure to support fully-static builds, which makes configuration more challenging.

If a 'd' (or any other suffix) was added to the "standard" library names, then it (or some other value) might be added as a suffix to other library names. This means that other configure script sections may not be actually working properly for your builds.

[tal]

We aware of it, that why there is much bigger patch.
How you can think you need to solve it in the general case, that in pkg-config it give you the correct library name with the suffix if exist. (d for example)?
You can also comment on this link:
https://github.com/microsoft/vcpkg/pull/46839
Kai can explain better then me how to deal with the problem, also suggest a better solution for you.

[tal]

the suffix name d in the png in debug, coming from upstream. not from vcpkg.

[Bob Friesenhahn]

Tal, please test with Mercurial changeset 17771:a5e10a7b2c95 or source snapshot GraphicsMagick-1.4.020250816 and let me know if the configure script works for you now.

There are surely other cases where the pkg-config provided library name is not used. I will address those later. The PNG case is by far the most complex since it tests for multiple library names, and verifies that the header file is compatible with the library.

The configure script verifies successful linkage before adding a library to the configuration.

[tal]

I cannot test it. On local and vcpkg ci:
configure.ac:14: error: Autoconf version 2.72 or higher is required
https://github.com/microsoft/vcpkg/pull/46958

on my local: Can it done with autoconf 2.71?

autoconf --version
autoconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
https://gnu.org/licenses/gpl.html, https://gnu.org/licenses/exceptions.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

[Bob Friesenhahn]

What version of Autoconf do you have? Probably 2.72 is not an absolute requirement and I can find an older version number which supports the requirements.
Change the line AC_PREREQ([2.72]) so it says 2.69 and see what happens.

[tal]

I patch it for support autoconf 2.71. Any reason why autoconf 2.72?

[Bob Friesenhahn]

There is no reason for 2.72 other than that is what I am using at the moment.