libGD

Trying those attachments again...

Can you tried using CVS HEAD please? I added many mingw related fixes and succeeded to build gd using mingw only (with cmake).

Thanks for the really fast reply Pierre! :) It's almost 1am here so I won't be able try out CVS HEAD right away, but I'll give things a go tomorrow morning after I've had some sleep, and report back on the results.

Tried a CVS checkout as of a few hours ago. No luck with either autoconf or cmake. Same style of error for the autoconf build (dllimport problems). For cmake, I fear my unfamiliarity with the tool and libgd was my undoing- I couldn't find a way to persuade it to find the PNG library. No doubt it is an easy problem to fix for someone more familiar with the libgd library and cmake. I was unable to figure it out. cmake is incredibly cryptic, can't say my first experience with it has been positive. Building cmake itself, on the other hand, was quite easy- just the standard ./configure –prefix=??, make, make install.

Script used to build both the cmake and autoconf build is "try-all-gd". Build script is "bi-win-gd-cvs-any". Output in "log-gd-cvs-head-20080504-a" for the autoconf attempt, and "log-gd-cvs-head-20080504-c" for the cmake attempt. Updated "sysinfo" script included, along with output in "sysinfo.out".

I'm open to suggestions.

Tried a CVS checkout as of a few hours ago. No luck with either autoconf or cmake. Same style of error for the autoconf build (dllimport problems).

I do not get this error but that's easy to fix. Maybe a MSys specific requirement.

cmake is incredibly cryptic, can't say my first experience with it has been positive. Building cmake itself, on the other hand, was quite easy- just the standard ./configure –prefix=??, make, make install.

You don't need to build cmake on windows, simply install. Then you can call cmakesetup, select the src tree, select mingw as target and that's it :) All can be done using a normal DOS console (cmd.exe) without using MSys.

I'm writing a tutorial in our wiki (documentation section). It should help to get it work.

I couldn't find a way to persuade it to find the PNG library

If the PNG lib and include direcorties are in the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH, it should find it. Have you tried using what I describe here:

http://cvs.php.net/viewvc.cgi/gd/libgd/docs/README.CMAKE?revision=1.4&view=markup

> Tried a CVS checkout as of a few hours ago. No luck with either autoconf or cmake. Same style of error for the autoconf build (dllimport problems).

I do not get this error but that's easy to fix. Maybe a MSys specific requirement.

A similar error also occurs in 2.0.33 and 2.0.36RC1. If there's an easy solution you know of for the dllimport issue, please do share, as it would fix my problems.

> cmake is incredibly cryptic, can't say my first experience with it has been positive. Building cmake itself, on the other hand, was quite easy- just the standard ./configure –prefix=??, make, make install.

You don't need to build cmake on windows, simply install. Then you can call cmakesetup, select the src tree, select mingw as target and that's it :) All can be done using a normal DOS console (cmd.exe) without using MSys.

Building cmake from source wasn't hard, as mentioned. I just found *using* it to be difficult. I'm not sure if the build from source generated the GUI- I haven't seen it yet. If you think the GUI interface might be more successful, I can try this out.

I'm writing a tutorial in our wiki (documentation section). It should help to get it work.

I'll keep an eye out.

> I couldn't find a way to persuade it to find the PNG library

If the PNG lib and include direcorties are in the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH, it should find it. Have you tried using what I describe here:

http://cvs.php.net/viewvc.cgi/gd/libgd/docs/README.CMAKE?revision=1.4&view=markup

My attempts to set CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH can be found in the bi-win-gd-cvs-any file above. I used README.CMAKE for ideas when I was experimenting. Unfortunately I was unsuccessful. My best attempt can be found in my previous post.

One note about MSys, I do not use MSys for cmake. I only use the normal cmd.exe.

A similar error also occurs in 2.0.33 and 2.0.36RC1. If there's an easy solution you know of for the dllimport issue, please do share, as it would fix my problems.

I have no idea now why it happens. My first thought was that we did not export the declaration, but we do. And both the declaration and the implementation use the same signature.

I will finish to write the doc about compiling GD using cmake and mingw (pretty much the same operation to compile gd using VC's nmake). It may help to get a common base and then see why MSys get lost with this declaration.

Thanks a lot for your tests and feedbacks! I hope we can figure out a solution very quickly.

OK, I got the time to set up a working MSys environment with libpng, jpeg and freetype. I am finally able to reproduce your error. It is a little mistery for me right now. The exact code works like a charm using cmake and mingw tools under a cmd.exe.

I'm investigating further.

I’m miserably blocked with automake to regenerate the configure scripts, but I think all we need is to get BGDWIN32 when configure is ran via MSys.

Mingw/Msys could be detected using AC_CANONICAL_TARGET([]) or AC_CANONICAL_HOST([]) in the beginning of configure.ac. Can you try to add them and see if it correctly sees MSYS or MinGW32? We can then define BGDWIN32 if one or the other has been detected. That’s what I do in cmake and may explain why I don’t get this error using the same compiler/linker.

It does work by forcing BGDWIN32 (and DLLIMPORT/EXPORT). A couple of functions are actually lacking the right export but that's fixable.

What is more problematic are errors like:

internal compiler error: in rest_of_handle_final, at toplev.c:2067 (in gd_transform.c:28)

and

Some well declared functions using BGD_DECLARE but msys+mingw think they are lacking proper dllimport symbols.

Hi Pierre,

Following from a hunch on your mention of BGDWIN32, I dug around and found that defining NONDLL would restrict it to a static build, which is enough for me, since I was only after a static build anyway.

Adding CPPFLAGS="$CPPFLAGS -DNONDLL=1" near the end of configure.ac and doing the usual autoconf magic got me a bit further. Strangely, adding it near the start had no effect, the setting was lost. Could this mean that all environment variables passed in (eg. CPPFLAGS, etc, see "./configure –help" near the end) are discarded? More on that in a moment.

Anyway, adding it in later in the file got me further in the build. It couldn't find the zlib headers, so I hardcoded them in in a similar way to NONDLL. It got further, then choked on the png headers. This was concerning- I had used the "–with-png" configure flag, and told it where to look. Looking at the configure output, it both finds, and doesn't find, the png headers- ie. "yes" on the configuration summary, but png.h and libpng/png.h say "no".

I'm left with the following bugs:

- Environment variables CPPFLAGS, etc, are not respected, or are replaced. It should have been sufficient to specify the zlib includes through them, and I should have been able to set NONDLL that way too.

- No "–with-zlib" configure flag, so if zlib isn't installed in /usr or /, you have to resort to trickery to get it in. Without the CPPFLAGS environment variable being respected, I've lost the usual way I specify its location with other configure scripts.

- CPPFLAGS settings set too early in configure.ac are not respected. Putting it at the end of the file instead should not have made a difference, but did.

- Even with "–disable-shared" specified, it's trying to use all of the dllimport stuff.

- The "–with-png" configure switch doesn't seem to work. Even if you tell it where libpng is, it doesn't seem to be enough. I suspect there may be troubles with the other "–with" flags as well.

I think if I kept at it, and plugged in more hardcoded paths into configure.ac as with zlib, I might get further. However, the need to work around so many bugs is particularly concerning, especially when the main reason I'm looking at libgd is to evaluate if it is suitable for my project. I can't afford to sink so much time into libgd. :( As such, I think I'll stop here for now. I'm happy to try out and provide feedback on any future versions though, check out fixes in CVS, release candidates, so forth. Just let me know.

I'm not sure why MSYS is so different and tricky than cygwin or other unix-like system. I will try to figure it out when I have the time.

I think if I kept at it, and plugged in more hardcoded paths into configure.ac as with zlib, I might get further. However, the need to work around so many bugs is particularly concerning, especially when the main reason I'm looking at libgd is to evaluate if it is suitable for my project. I can't afford to sink so much time into libgd. :( As such, I think I'll stop here for now. I'm happy to try out and provide feedback on any future versions though, check out fixes in CVS, release candidates, so forth. Just let me know.

I like to already thank you for testing it, I greatly appreciate your efforts!

As I said it works using CMake in a normal cmd.exe with MingW. That is enough to build a MSys/MingW binary (even for VC6 in non threaded environment). Once I'm done with the actual development fo 2.1 I will make it work smoothly (hopefully) for Msys.

You're most welcome. I hope the feedback has been useful.

I'll keep the cmake & direct MinGW thing in mind. When I'm next playing with image libraries it should give me something else to try.

Forgive my ignorance about libgd; I'm just bumbling around trying to compile it as a dependency for something else. I was able to get libgd 2.0.36RC1 to compile under mingw by making a few modifications:

1) In gd_jpeg.c add #define HAVE_BOOLEAN just above #include "jpeglib.h"

This prevents a conflicting typedef in jmorecfg.h (from libjpeg) from being invoked.

2) (This is not libgd, but...) in jmorecfg.h from libjpeg, wrap "typedef long INT32" inside of #ifndef _BASETSD_H and a #endif, ala

#ifndef XMD_H			/* X11/xmd.h correctly defines INT32 */
#ifndef _BASETSD_H_		/* Microsoft defines it in basetsd.h */
#ifndef _BASETSD_H		/* MinGW defines it in basetsd.h, too */
#ifndef QGLOBAL_H		/* Qt defines it in qglobal.h */
typedef long INT32;
#endif
#endif
#endif
#endif

The "typedef long INT32" conflicts with another typedef provided in basetsd.h. The headers provided by Microsoft define _BASETSD_H_ but the header provided with mingw defines _BASETSD_H (note missing trailing _). A possible work-around for just libgd might be to...

#ifdef _BASETSD_H
#define _BASETSD_H_
#endif

... perhaps? I'm not sure what the side effects would be, if any.

3) In gd.h, I had to force

#define BGD_DECLARE(rt) __declspec(dllexport) rt __stdcall

and

#define BGD_EXPORT_DATA_PROT __declspec(dllexport) extern
#define BGD_EXPORT_DATA_IMPL __declspec(dllexport)

With those changes, make seems to have finished without errors.

ack... hitting refresh was a bad idea