Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake and Makefiles build broken on Windows #249

Closed
pierrejoye opened this issue Jul 9, 2016 · 37 comments
Closed

CMake and Makefiles build broken on Windows #249

pierrejoye opened this issue Jul 9, 2016 · 37 comments
Assignees
Labels
Milestone

Comments

@pierrejoye
Copy link
Contributor

@nathanaeljones any appealing reason to have changed the Makefile for something we do not actually control? I would rather stick to the struture we had for cmake and PHP, using binaries/prebuilt deps that are validated and widely used. Any comment to do something different welcome :)

CMake as of now is also broken,

Using a simple command like:

cmake -G "Visual Studio 14 2015" -DBUILD_TEST=1 -DENABLE_PNG=1 -DENABLE_JPEG=1 -DENABLE_FREETYPE=1 -DENABLE_WEBP=1 -DCMAKE_LIBRARY_PATH=c:\php-sdk\master\vc14\x64\deps\lib -DCMAKE_INCLUDE_PATH=c:\php-sdk\master\vc14\x64\deps\include

Which simply requires to copy the deps llibs in ..\deps generates a clean build using all libraries we support. Deps prebuilt can be fetched here:

http://windows.php.net/downloads/php-sdk/

or can be built easily using:

https://github.com/winlibs

This is something I am not keen to change to some other structure or pre built binaries.

Thoughts and comments more than welcome.

@pierrejoye
Copy link
Contributor Author

It also means we need to restore the cmake/modules directory as currently CMake on Windows is a big mess from a deps point of view.

Installing system wide builds files is an absolute no-go, especially when it comes to create clean and custom builds.

I have to check if we can have it used only for windows and keep using system ones for other platforms, if that helps.

@cmb69
Copy link
Contributor

cmb69 commented Jul 9, 2016

I would rather stick to the struture we had for cmake and PHP, using binaries/prebuilt deps that are validated and widely used.

+1

@vapier
Copy link
Member

vapier commented Jul 9, 2016

I think before we seriously consider supporting the Windows builds, we need to get the appveyor CI stuff working. I spent a little time on it, but I've never used it before, and it's been years since I built under Windows (majority of my work has been with mingw).

along those lines, should we look at adding mingw to Travis? or would it not be that useful as we expect the majority of people to build under Windows using an MS toolchain?

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 9, 2016

I think before we seriously consider supporting the Windows builds,

We do. And we used to run tests but things went off on my side after latest 2.1. But we do support windows.

we need to get the appveyor CI stuff working. I spent a little time on it, but I've never used it before, and it's been years since I built under Windows (majority of my work has been with mingw).

All for it, back then it was not available/free to use for oss. So i am all for using it.

along those lines, should we look at adding mingw to Travis?

I think we can, it used to work.

or would it not be that useful as we expect the majority of people to build under Windows using an MS toolchain?

Both actually :)

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 9, 2016

To be more precised, for windows, the priorities are:

  1. Cmake
  2. Nmake makefile (very very handy)
  3. Mingw (not sure we can use std configure here or makefile

For both nnake and cmake I do want to keep supporting php pre built deps.as they are widely tested and supported.

@lilith
Copy link
Contributor

lilith commented Jul 9, 2016

It's been years, so I'm not sure what changes you're talking about. There were a couple scenarios we (Imazen) were facing:

  1. Windows doesn't have shared libraries, and the prebuilt binaries for php had a lot of flaws we kept encountering. We needed the ability to update our dependencies immediately when sec updates happened.
  2. Linux often ships with extremely outdated system libs.
  3. Static compilation was often useful.

So having control over which git revision of every dependency turned out to be helpful. Thumbs.sh provided this, albeit in a less than perfect manner. I now use Conan.io instead of thumbs.sh for all of my projects, and can't reccomend it enough. It doesn't care about your build system; it just ensures all the dependencies are compiled and made available for your build target, whether you use makefiles, autotools, CMake, etc. Very convenient, especially for CI, where you may want to test using, say, a different libpng than is shipped with Travis default. Ofc, docker could also be used, if you're willing to maintain the container image.

It's also slightly easier to test against multiple versions of dependencies that way. And, if your deps are already on Conan.io, the investment is minimal.

Since Conan.io coexists with CMakeLists.txt and your makefile, there's no need to use it unless you want to control/fetch dependencies instead of using the system set.

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 9, 2016

The main points are:

  • Grab the deps and put them in libgd/../deps and it is all good for a build
  • The winlibs are literally used by millions users and updated regulary
  • It should still be possible to use any other deps src tho'. The default must however works out of the box

I will take a look (on my list) to conan.io. i was thinking about chocolaterey but the way it installs package is a bit aweful when it comes to dev files :)

@vapier
Copy link
Member

vapier commented Jul 10, 2016

i'm not saying Windows isn't supported. i'm saying before we embark on trying to get things building/working again, we get the CI running for these. otherwise we'll spend time fixing things now only to have them break again and not notice.

doing configure+mingw by itself isn't a problem. it's more how do we get the mingw toolchain in the Travis Ubuntu environment. i suspect it's not hard.

@rashadkm
Copy link

what about CMake ExternalProject to get dependencies before building libgd?

@pierrejoye
Copy link
Contributor Author

@vapier ah ok :) And yes, totally agree.

CMake seems to need more love in the custom Find*, also some updates in them to support 3.x better.

In the meantime, I went for the easiest way, updated the makefile.vc, at least it builds now with most features. Tests suite will follow.

@rashadkm could be useful. I am not sure it is worth the extra work to maintain that. Given how easy it is to grab the deps, unzip in ..\deps, builds :)

@rashadkm
Copy link

@pierrejoye , agreed that it won't be as easy compared to just downloading dependencies into deps.
if winbuilds are able to give clean build, maintenance overhead will be less.

pierrejoye added a commit that referenced this issue Jul 10, 2016
@pierrejoye
Copy link
Contributor Author

I started to port gdtest. Only missing is the temporary directory. I may simply go for the system temp directory for the time being.

Alternatively I can port what I did in php for mkdtemp but :)

@pierrejoye
Copy link
Contributor Author

Initial ports of @vapier helpers functions as well as fixing some tests to use these helpers are done now.

I hope I did not break more than I fixed, but windows tests suite using makefile is back on track:

library source: src

test: bmp\bmp_im2im...................................................Passed
test: bmp\bmp_null....................................................Passed
test: freetype\bug00132...............................................Passed
test: gd\gd_im2im.....................................................Passed
test: gd\gd_null......................................................Passed
test: gd\gd_num_colors................................................Passed
test: gd\gd_versiontest...............................................Passed
test: gd2\gd2_empty_file..............................................Passed
test: gd2\gd2_im2im...................................................Passed
test: gd2\gd2_null....................................................Passed
Usage: gd2_read.exe <input gd2> <expected png>
test: gd2\gd2_read....................................................Failed
test: gdimagearc\bug00079.............................................Passed
test: gdimagecolorclosest\gdimagecolorclosest.........................Passed
test: gdimagecolordeallocate\gdimagecolordeallocate...................Passed
test: gdimagecolorexact\gdimagecolorexact.............................Passed
test: gdimagecolorreplace\gdimagecolorreplace.........................Passed
test: gdimagecolorresolve\gdimagecolorresolve.........................Passed
test: gdimagecolortransparent\gdimagecolortransparent.................Passed
test: gdimagecopy\bug00007............................................Passed
test: gdimagecopy\bug00081............................................Passed
test: gdimagecopyrotated\bug00020.....................................Passed
Skipping test for 'img-ref.xbm'.  FIX THIS!
Skipping test for 'img-ref.tga'.  FIX THIS!
Skipping test for 'img.webp'.  FIX THIS!
Skipping test for 'img.tiff'.  FIX THIS!
test: gdimagefile\gdnametest..........................................Passed
test: gdimagefill\bug00002_1..........................................Passed
test: gdimagefill\bug00002_2..........................................Passed
test: gdimagefill\bug00002_3..........................................Passed
test: gdimagefill\bug00002_4..........................................Passed
test: gdimagefilledellipse\bug00010...................................Passed
test: gdimagefilledellipse\bug00191...................................Passed
test: gdimagefilledpolygon\bug00100...................................Passed
test: gdimagefilledpolygon\gdimagefilledpolygon0......................Passed
test: gdimagefilledpolygon\gdimagefilledpolygon1......................Passed
test: gdimagefilledpolygon\gdimagefilledpolygon2......................Passed
test: gdimagefilledpolygon\gdimagefilledpolygon3......................Passed
test: gdimagefilledrectangle\bug00004.................................Passed
test: gdimagefilledrectangle\bug00078.................................Passed
test: gdimagefilledrectangle\bug00106_gdimagefilledrectangle..........Passed
test: gdimagefilltoborder\bug00037....................................Passed
test: gdimagefilter\gdCopyBlurred.....................................Passed
test: gdimageline\bug00072............................................Passed
test: gdimageline\bug00077............................................Passed
test: gdimageline\bug00111............................................Passed
test: gdimageline\gdImageAALine_thickness.............................Passed
test: gdimageline\gdimageline_aa......................................Passed
test: gdimageline\gdimageline_aa_outofrange...........................Passed
test: gdimageline\gdimageline_bug5....................................Passed
test: gdimageopenpolygon\gdimageopenpolygon0..........................Passed
test: gdimageopenpolygon\gdimageopenpolygon1..........................Passed
test: gdimageopenpolygon\gdimageopenpolygon2..........................Passed
test: gdimageopenpolygon\gdimageopenpolygon3..........................Passed
test: gdimagepixelate\gdimagepixelate.................................Passed
test: gdimagepolygon\gdimagepolygon0..................................Passed
test: gdimagepolygon\gdimagepolygon1..................................Passed
test: gdimagepolygon\gdimagepolygon2..................................Passed
test: gdimagepolygon\gdimagepolygon3..................................Passed
test: gdimagerectangle\bug00003.......................................Passed
test: gdimagerectangle\bug00106_gdimagerectangle......................Passed
test: gdimagerotate\bug00067..........................................Passed
test: gdimagerotate\php_bug_64898.....................................Passed
test: gdimagescatterex\bug00208_1.....................................Passed
test: gdimagescatterex\bug00208_2.....................................Passed
test: gdimagesetpixel\bug00186........................................Passed
test: gdimagesetpixel\gdeffectmultiply................................Passed
test: gdimagesetpixel\gdeffectoverlay.................................Passed
test: gdimagestringft\gdimagestringft_bbox............................Passed
test: gdimagestringftex\gdimagestringftex_returnfontpathname..........Passed
test: gdinterpolatedscale\gdModesAndPalettes..........................Passed
test: gdinterpolatedscale\gdTrivialResize.............................Passed
test: gdnewfilectx\gdnewfilectx_null..................................Passed
test: gdtiled\bug00032................................................Passed
test: gif\bug00005....................................................Passed
test: gif\bug00005_2..................................................Passed
test: gif\bug00006....................................................Passed
test: gif\bug00060....................................................Passed
test: gif\bug00066....................................................Passed
test: gif\bug00181....................................................Passed
test: gif\bug00227....................................................Passed
test: gif\gif_im2im...................................................Passed
test: gif\gif_null....................................................Passed
test: jpeg\jpeg_empty_file............................................Passed
test: jpeg\jpeg_im2im.................................................Passed
test: jpeg\jpeg_null..................................................Passed
skip, JPEG Major version too high (9)
test: jpeg\jpeg_read..................................................Passed
test: jpeg\jpeg_resolution............................................Passed
test: png\bug00011....................................................Passed
test: png\bug00033....................................................Passed
test: png\bug00086....................................................Passed
test: png\bug00088....................................................Passed
test: png\bug00193....................................................Passed
test: png\png_im2im...................................................Passed
test: png\png_null....................................................Passed
test: png\png_resolution..............................................Passed
test: tga\tga_null....................................................Passed

@pierrejoye
Copy link
Contributor Author

Test now generated dynamically.

One note, please avoid using test wrapped in .sh but use C directly to deal with many files. Using very nice @vapier new API, it is very straightforward.

@pierrejoye pierrejoye self-assigned this Jul 20, 2016
@pierrejoye pierrejoye added this to the GD 2.2.4 milestone Jul 20, 2016
@pierrejoye pierrejoye added the bug label Jul 20, 2016
@cmb69
Copy link
Contributor

cmb69 commented Jul 22, 2016

I've just managed to have a look at building on Windows, and with VS 2015 x64 the instructions in windows/Makefile.vc worked fine for building the lib, but not building the tests. gd_test.c fails:

tests\gdtest\gdtest.c(1): fatal error C1083: Cannot open include file: 'config.h': No such file or directory

Any hints?

If I get the Windows build working properly, I would improve the documentation (windows/Makefile.vc could clarify where to put the deps, where the default build dir is, and windows/readme.md needs an update, anyway).

@pierrejoye
Copy link
Contributor Author

Ah I dod not notice it was not generated anynore.

You can take src/config.h.cmake as a base.

I will try to add the config.h generation to the makefile over the weekend.

@cmb69
Copy link
Contributor

cmb69 commented Jul 22, 2016

You can take src/config.h.cmake as a base.

Thanks (could have thought of this myself as well).

After additionally adding #include <test_config.h> to tests/gdtest.c the tests built fine, but all tests are failing (unless a few skipped ones). Will try to investigate.

Anyhow, I've noticed a skipped test with message JPEG Major version too high (9). Apparently, @weltling has updated to libjepg 9b, so either libgd should support libjpeg-9b (but not 10, most likely), or winlibs/libjpeg should downgrade again (or perhaps use libjpeg-turbo).

@pierrejoye
Copy link
Contributor Author

@cmb69 Tests should pass now. @vapier removed test_config.h making all tests using files failed.

Consistent with autotools script top dir is now passed by argument using /D...

@vapier
Copy link
Member

vapier commented Jul 23, 2016

one step forward, two steps back ? or two steps forward ? :)

@pierrejoye
Copy link
Contributor Author

:)

@cmb69
Copy link
Contributor

cmb69 commented Jul 23, 2016

Tests should pass now.

I'm still not able to build the tests, because config.h doesn't get generated. After manually creating it, the tests build, but still all tests are failing, because libgd.dll isn't found. I don't know how to solve the former (short of creating a fixed config.h), but the latter might already be sufficiently solved by adding SET PATH=..;%PATH% to windows/run_tests.bat.

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 23, 2016

Either that or copy it over. It should be there already if i am not mistaken

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 23, 2016

Ah, it is but not seems not to be called anymore.

$(TEST_LIST): $(TARGETDLL)
if not exist $(TDR) mkdir $(TDR)
copy $(TARGETDLL) $(TDR)$(GD_DLL)

I have to check why.

@pierrejoye
Copy link
Contributor Author

@cmb69 The DLL issue should work now.

I just tested with clean checkout and no existing gdbuild directory (or if you choose another one).

@cmb69
Copy link
Contributor

cmb69 commented Jul 23, 2016

The DLL issue should work now.

Yes, thanks!

@pierrejoye
Copy link
Contributor Author

config.h generations work too, basics one.

Todos:

add options to makefile to enable/disable features (png, webp etc) then we are good again.

@cmb69
Copy link
Contributor

cmb69 commented Jan 19, 2017

What do we do with regard to libtiff, which is not available on http://windows.php.net/downloads/php-sdk/deps/? Makefile.vc doesn't define HAVE_LIBTIFF in config.h, so the build works fine, but building the test executables fails, because gentest.bat doesn't skip the tiff/ tests. For now, it makes sense to skip the tiff/ tests, but in the long run it would be great to have TIFF support on Windows, too.

@vapier
Copy link
Member

vapier commented Jan 19, 2017

all the checked in files should be in sync. so if we have a committed config header that disables tiff, then the gentest.bat script should skip them too.

@cmb69
Copy link
Contributor

cmb69 commented Jan 19, 2017

so if we have a committed config header that disables tiff, […]

Actually, for Windows config.h is generated by the Makefile, but there's no way to enable TIFF, so I've disabled tests/tiff/ as well.

@xinxilas
Copy link

xinxilas commented Jul 29, 2021

There is no easy way to customize the building for Windows or mingw32?

I dont want to add freetype2 and fontconfig, avif, heif, and some others
Im trying to build a minimal libgd to use as dependency for windows nginx(it will only resize images)

PS: Why following windows tutorial the resulted include files was .objs and not .h?
https://github.com/libgd/libgd/blob/master/windows/readme.md
I need the headers files to use for nginx(but this wasn't the major problems)

I was able to build this with vcpkg editing their portfile.cmake:
https://github.com/microsoft/vcpkg/tree/master/ports/libgd
this lines

vcpkg_configure_cmake(
    SOURCE_PATH ${SOURCE_PATH}
    PREFER_NINJA
    OPTIONS -DENABLE_PNG=${ENABLE_PNG}
            -DENABLE_JPEG=${ENABLE_JPEG}
            -DENABLE_WEBP=${ENABLE_WEBP}
            -DBUILD_STATIC_LIBS=${LIBGD_STATIC_LIBS}
)

It worked fine but they use v2.2.5

PS: Windows Makefile.vc file has some duplicated lines:
image
image

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 30, 2021 via email

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Jul 30, 2021 via email

@cmb69
Copy link
Contributor

cmb69 commented Jul 30, 2021

what do you mean by "there is no way to enable it"?

I think that has been resolved in the meantime. :)

@vapier
Copy link
Member

vapier commented Aug 8, 2021

can we just delete all Windows related files and tell people to use cmake ? we're supporting way too many build methods.

@pierrejoye
Copy link
Contributor Author

pierrejoye commented Aug 9, 2021

Hi @vapier

Yes, I will do it in Head this week.

At the same time, I will update the windows/VC build doc to use vcpkg for all deps. It makes the whole thing a breath. Step 2 I will create a libgd registry so one can simply use vcpkg to add libgd to their project.

I will also stop relying on PHP's windows builds, only libxpm and maybe the latest codecs are not in vcpkg, I will add them via our registry.

@pierrejoye
Copy link
Contributor Author

Also please note that vcpkg works on Linux and MacOs as well. As it is less needed on linux, I think it can help a lot too on MacOS. Let see.

@pierrejoye
Copy link
Contributor Author

CMake works smoothly now on Windows. Github Actions Windows is enabled.

As of the Makefile, let drop them. They are handy but time consuming to maintain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants