configure.ac and libgd (gdlib) - use pkg-config

[JPeterMugaas]

While preparing a package for MSYS's MINGW-W64, I found an issue with libgd detection in your configure script. The problem is this, that script depends upon using the libtool.la file for gdlib. That's a problem for two basic reasons:

1. The .la file is not generated if you built libgd with CMake. I tried making a workaround for that by attempting to create such a file with cmake with no luck. CMake does not use libtool at all, AFAIK.
2. Many software distributions do no include the .la files from most libraries by default so you can't depend on them being present.

You have made a comment about how gdlib-config does not always return the "-lgd" in it's --libs parameter. The matter is much worse than that. gdlib-config is now depreciated in libgd 2.4. In addition, it does not seem to be generated if CMake is used for the build. While I made a proposed fix for MSYS2's mingw-w64 distribution, that probably will not ultimately fix matters.

These days, the libgd authors prefer that you use pkg-coinfig to get information about the library from their gdlib.pc file. I am providing the a patch for this issue although it might be crude. The idea is to use "PKG_CHECK_MODULES(LIBGD, [gdlib])". I'm too lazy to make a PR.

libgphoto2-use-pkg-config-for-gd.patch.txt

[msmeissn]

can you attach a failing config.log ?
GP_CHECK_LIBRARY actually would call PKG_CHECK_MODULES in some of its detection methods.
might be we need to remove the gdlib case in gphoto-m4/gp-check-library.m4
@ndim

[JPeterMugaas]

Sure. No trouble. Here's a couple.

config.log.txt
config.log.txt

[msmeissn]

So ... our code actually tries to run pkg-config before trying out gdlib-config, so it should actually just work.

In both of your logs they call
pkg-config --libs gdlib

64bit:
checking gdlib library flags
result: "-lgd -LC:/msys64/mingw64/lib/libgd-2.2 -lgd"
checking gdlib cpp flags
result: "-IC:/msys64/mingw64/include/libgd-2.2"
...
checking for function gdImageCreateTrueColor in gdlib
x86_64-w64-mingw32-gcc -o conftest.exe -march=x86-64 -mtune=generic -O2 -pipe -Wall -Wmissing-declarations -Wmissing-prototypes -D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -pipe conftest.c -lgd -LC:/msys64/mingw64/lib/libgd-2.2 -lgd >&5
$? = 0
result: yes
checking gdlib library flags
result: "-lgd -LC:/msys64/mingw64/lib/libgd-2.2 -lgd"
checking gdlib cpp flags
result: "-IC:/msys64/mingw64/include/libgd-2.2"

so the 64bit build looks fine...

The 32bit build has a bit trouble, but it finds the gdlibs using pkg-config,
checking for gdlib to use
result: autodetect
checking for LIBGD
$PKG_CONFIG --exists --print-errors "gdlib >= 2.0"
$? = 0
$PKG_CONFIG --exists --print-errors "gdlib >= 2.0"
$? = 0
result: yes

but
checking for function gdImageCreateTrueColor in gdlib
i686-w64-mingw32-gcc -o conftest.exe -march=i686 -mtune=generic -O2 -pipe -Wall -Wmissing-declarations -Wmissing-prototypes -D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1 -I/mingw32/include -pipe conftest.c -lgd -LC:/msys64/mingw32/lib/libgd-2.2 -lgd >&5
C:\msys64\tmp\ccsw0CfU.o:conftest.c:(.text.startup+0xc): undefined reference to `gdImageCreateTrueColor'

It seems the mingw32 build of libgd went a bit bad? Can you check if there are problems?

[ndim]

@JPeterMugaas I concur with @msmeissn here. It appears your mingw64 build of libgd was built in a way we can link to and which does contain the gdImageCreateTrueColor function, while your mingw32 build of libgd has been built in a way we cannot link to, or which does not contain the gdImageCreateTrueColor function.

That linking error is the very issue here, and libgphoto2's configure script finds that issue as it is supposed to do.

If you remove the check for gdImageCreateTrueColor (which is what your PKG_CHECK_MODULES based proposed patch effectively does), configure will run apparently successfully but then compiling/ linking the camlibs which use the non-existent gdImageCreateTrueColor function will fail much later.

Failing earlier is to be preferred here, so that configure can have those camlibs be built without using libgd (which removes some file formats from their list of supported output file formats, but still lets them do useful work). And that is what libgphoto2's configure script is doing here.

All of this leads me to conclude that libgphoto2's configure script is behaving as it should, and your broken libgd build is nothing we could fix in libgphoto2. Therefore I am closing this issue now. If I am wrong anywhere in this assessment, please reopen this issue and comment on the specifics.