HAVE_GL_GL_H-NOTFOUND

[Robin Rowe]

Hi. I'm building FLTK as part of a new CinePaint cmake build system.
FLTK not finding the Windows OpenGl headers or the Zlib/PNG/JPEG
libraries I've downloaded. How do I tell FLTK where they are?

Output below is from Windows:

$ cmake ..
--- Building fltk ---
-- Note: The following three headers should all be found!
-- HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
-- HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
-- HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
-- If one of these headers was not found, run cmake-gui ...
-- ... again from a Visual Studio developer command prompt!
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
--
cannot find system zlib library - using built-in

--
cannot find system jpeg library - using built-in

--
cannot find system png library - using built-in

> If one of these headers was not found, run cmake-gui ...
> again from a Visual Studio developer command prompt!

In the Windows git bash shell. Would rather not use the dev command
prompt or cmake-gui. And besides, I can't find dev command prompt in VS2017.

Thanks!

Robin

[Ian MacArthur]

On Wednesday, 27 December 2017 07:27:57 UTC, robinsrowe wrote:

Hi. I'm building FLTK as part of a new CinePaint cmake build system.
FLTK not finding the Windows OpenGl headers or the Zlib/PNG/JPEG
libraries I've downloaded. How do I tell FLTK where they are?

Hi Robin,

Which fltk variant are you using, BTW?

IIRC, Cinepaint has been built for fltk-2 and fltk-1.x variants at different points along the way... Are you looking at fltk-1.4 now, or something else?

FWIW, the cmake support is most nearly complete in fltk-1.4; it is less complete (though probably "working") in fltk-1.3, for example.

Also, I tend (under Windows with VS) to use the fltk built-in jpeg/zlib/png libs as I find that easier than trying to persuade VS to use ones I built stand-alone! Do you need "external" image libs? (I speculate that you do need specific versions, possible modified, for Cinepaint?)

 

Output below is from Windows:

        $ cmake ..
        --- Building fltk ---
        -- Note: The following three headers should all be found!
        -- HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
        -- HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
        -- HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
        -- If one of these headers was not found, run cmake-gui ...
        -- ... again from a Visual Studio developer command prompt!
        -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
        -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
        --
        cannot find system zlib library - using built-in

        --
        cannot find system jpeg library - using built-in

        --
        cannot find system png library - using built-in

 > If one of these headers was not found, run cmake-gui ...
 > again from a Visual Studio developer command prompt!

In the Windows git bash shell. Would rather not use the dev command
prompt or cmake-gui. And besides, I can't find dev command prompt in VS2017.

The VS git shell doesn't seem to get all the correct paths set up, at least for me. 

If I build with VS (which I do not do *all* that often) then I always have to run cmake from the "proper" VS cmd prompt. 

On my machine, that's in... (VS IDE)->Tools->Visual Studio Command Prompt.  

It's also in the "Start" menu, in the "Visual Studio 2017" sub-folder there are several command prompt choices (32-bit, 64-bit, cross-, etc...)

OK, just did a full rebuild under VS, just to make sure (this was of svn current fltk-1.4) and it all went smoothly, so it *ought* to Just Work (!)

That said, under Windows, I mainly use mingw-32 and mingw64 still, even though VS does "play nicer" these days than it used to.

 

[Robin Rowe]

Ian, interesting insights into how you use the stock FLTK libraries, but
misses the question I asked. To follow up the questions you asked me...

> Which fltk variant are you using, BTW?

1.3.4.

FYI, here's my FLTK.cmake, a work in progress...

#CinePaint FLTK.cmake
set(NAME "fltk")
project(${NAME})
message("--- Building " ${NAME} " ---")

set(PATH_FLTK "${CMAKE_BINARY_DIR}/fltk")
set(URL_FLTK "http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-2-source.tar.gz")

if(NOT IS_DIRECTORY ${PATH_FLTK})
download_project(PROJ fltk
PREFIX ${PATH_FLTK}
# UPDATE_COMMAND msbuild FLTK.sln
URL ${URL_FLTK}
UPDATE_DISCONNECTED ON
)
endif()

include_directories(fltk "${CMAKE_BINARY_DIR}/fltk/fltk-src"
"${CMAKE_BINARY_DIR}/fltk/fltk-build")
#add_subdirectory("${PATH_ZLIB}/zlib-src"
"${CMAKE_CURRENT_BINARY_DIR}/zlib-build")
#include_directories(SYSTEM "${fltk_SOURCE_DIR}")
add_subdirectory("${PATH_FLTK}/fltk-src" "${PATH_FLTK}/fltk-build")

> IIRC, Cinepaint has been built for fltk-2

No, never. As CinePaint project leader, I was briefly the sole
maintainer of fltk-1.3 because that's what we have in CinePaint Glasgow.
FLTK had announced it was moving to 2.0, later decided not to
discontinue 1.x after all.

> FWIW, the cmake support is most nearly complete in fltk-1.4; it is less
> complete (though probably "working") in fltk-1.3, for example.

I've been using cmake to build fltk-1.3 for a long time. Reported a bug
fix for building in VS2017.

> Also, I tend (under Windows with VS) to use the fltk built-in
> jpeg/zlib/png libs as I find that easier than trying to persuade VS to
> use ones I built stand-alone! Do you need "external" image libs? (I
> speculate that you do need specific versions, possible modified, for
> Cinepaint?)

Yes, CinePaint supports exotic HDR image formats.

> The VS git shell doesn't seem to get all the correct paths set up, at
> least for me.

Yes, a known deficiency.

> On my machine, that's in... (VS IDE)->Tools->Visual Studio Command Prompt.

That doesn't exist in my VS IDE, that is, VS2017 Community Edition. My
enterprise version of VS2015 has all the command line tools you mention,
so perhaps the developer command prompt is a pro feature only. VS2017
Community Edition is my Windows compiler for this project, not mingw or
VS2017 enterprise.

Does anyone know how to point my cmake file to tell FLTK where to find
the OpenGL, Zlib, libpng and libjpeg libraries that I wish to use?

Robin

[imm]

(This will not be very coherent, as I'm trying to use my phone for this...)

On 27 Dec 2017 8:39 p.m., "Robin Rowe wrote:

Ian, interesting insights into how you use the stock FLTK libraries, but misses the question I asked. To follow up the questions you asked me...

Which fltk variant are you using, BTW?

1.3.4.

OK - have you looked at the cmake files for 1.4, BTW?

They have addressed a lot of the issues we had with cmake builds, and for the most part I've found them pretty good on a variety of hosts, including Windows/VS builds.

IIRC, Cinepaint has been built for fltk-2

No, never. 

Ah, right. I was mistaken. Actually, I think I'm conflating work on Dillo (which did migrate from 2 to 1.3) with your work on Cinepaint, which is an entirely different kettle of fish!

CinePaint project leader, I was briefly the sole maintainer of fltk-1.3 because that's what we have in CinePaint Glasgow. FLTK had announced it was moving to 2.0, later decided not to discontinue 1.x after all.

I'm not sure what that paragraph means, so can't respond to it.

FWIW, the cmake support is most nearly complete in fltk-1.4; it is less complete (though probably "working") in fltk-1.3, for example.

I've been using cmake to build fltk-1.3 for a long time. Reported a bug fix for building in VS2017.

Yes, the cmake support under 1.3 works to some extent, at least on some host configurations. 1.4 is more refined though, I believe, so worth a look in case there are bits of cmake files you can take advantage of.

Also, I tend (under Windows with VS) to use the fltk built-in jpeg/zlib/png libs as I find that easier than trying to persuade VS to use ones I built stand-alone! Do you need "external" image libs? (I speculate that you do need specific versions, possible modified, for Cinepaint?)

Yes, CinePaint supports exotic HDR image formats.

I think you have modes with pixels with (more than eight) bits, and other such exotica? Fancy stuff!

The VS git shell doesn't seem to get all the correct paths set up, at least for me.

Yes, a known deficiency.

On my machine, that's in... (VS IDE)->Tools->Visual Studio Command Prompt.

That doesn't exist in my VS IDE, that is, VS2017 Community Edition. My enterprise version of VS2015 has all the command line tools you mention, so perhaps the developer command prompt is a pro feature only. VS2017 Community Edition is my Windows compiler for this project, not mingw or VS2017 enterprise.

Hmm, OK. That's odd. I haven't had a "pro" version of the VS tools since VC6. The machine I do my VS builds on is a Win10 VM running VS2017 Community, and the developer console is provided.

TBH, VS is practically useless to me without a console (I'm not very IDE oriented.)

Does anyone know how to point my cmake file to tell FLTK where to find the OpenGL, Zlib, libpng and libjpeg libraries that I wish to use?

Can't access a real computer just now.

I usually fire up cmake-gui, select the advanced tab, then write down the names of the variables that are pertinent, for setting from the command prompt. But I can't try that right now.

I'm fairly sure I recall building 1.4 on a Win7 machine, with VS and cmake, and setting the paths to correctly find external zlib and PNG builds - but I have no clue what I did... So, I'm pretty sure it works, but have nothing to offer as to how...

-- 
Ian
From my Fairphone FP2
   

[Albrecht Schlosser]

On 27.12.2017 21:39 Robin Rowe wrote:
>
>> Which fltk variant are you using, BTW?
>
> 1.3.4.

As Ian mentioned, FLTK's CMake support is not really complete in 1.3.4,
although I believe most of it works, so it _can_ work for you.

I'd suggest at least to try FLTK 1.4.0 (svn/git) to see if it works
better. See below.

> FYI, here's my FLTK.cmake, a work in progress...

I'm short in spare time now, so I'll take a look at it later.

>> FWIW, the cmake support is most nearly complete in fltk-1.4; it is
>> less complete (though probably "working") in fltk-1.3, for example.
>
> I've been using cmake to build fltk-1.3 for a long time. Reported a bug
> fix for building in VS2017.

Which one, and has it been fixed? (Note: I'm the one that currently does
most of the CMake work for FLTK, although most parts have been developed
by someone else).

>> The VS git shell doesn't seem to get all the correct paths set up, at
>> least for me.
>
> Yes, a known deficiency.

The CMake guys say you should "know" which libs are "always" available
in the VS IDE environment an rely on these w/o searching. The warnings
you showed in your first post can be ignored - at least in 1.4, I don't
know if I fixed it in 1.3 as well. The best thing you can do is to
trigger a CMake reconfigure from within the CMake IDE, for instance by
touching (rewriting w/o modifying) the main CMakeLists.txt and rebuild
target ZERO_CHECK. This should find all the three headers mentioned in
these warnings:

-- HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
-- HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
-- HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'

>> On my machine, that's in... (VS IDE)->Tools->Visual Studio Command
>> Prompt.
>
> That doesn't exist in my VS IDE, that is, VS2017 Community Edition.

I don't have VS2017 Community Editition, but my VS2015 Community
Editition has it. In win10 you can easily find it by typing "dev" in the
windows search (windows key + "dev"). Maybe you didn't install the
complete VS environment?

> Does anyone know how to point my cmake file to tell FLTK where to find
> the OpenGL, Zlib, libpng and libjpeg libraries that I wish to use?

I'll try to give you better advice later, but for now I can only suggest
that you search for png, jpeg, and zlib (case insensitive) either via
command line - using MinGW I can see:

$ grep -i 'PNG\|ZLIB\|JPEG' CMakeCache.txt
HAVE_LIBPNG_PNG_H:FILEPATH=HAVE_LIBPNG_PNG_H-NOTFOUND
HAVE_PNG_H:FILEPATH=HAVE_PNG_H-NOTFOUND
LIB_jpeg:FILEPATH=LIB_jpeg-NOTFOUND
LIB_png:FILEPATH=LIB_png-NOTFOUND
LIB_zlib:FILEPATH=LIB_zlib-NOTFOUND
//use system libjpeg
OPTION_USE_SYSTEM_LIBJPEG:BOOL=OFF
//use system libpng
OPTION_USE_SYSTEM_LIBPNG:BOOL=OFF
//use system zlib
OPTION_USE_SYSTEM_ZLIB:BOOL=OFF
fltk_images_LIB_DEPENDS:STATIC=general;fltk;general;fltk_jpeg;general;fltk_z;general;fltk_png;
fltk_jpeg_LIB_DEPENDS:STATIC=
fltk_png_LIB_DEPENDS:STATIC=general;fltk_z;
//ADVANCED property for variable: HAVE_LIBPNG_PNG_H
HAVE_LIBPNG_PNG_H-ADVANCED:INTERNAL=1
//ADVANCED property for variable: HAVE_PNG_H
HAVE_PNG_H-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LIB_jpeg
LIB_jpeg-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LIB_png
LIB_png-ADVANCED:INTERNAL=1
//ADVANCED property for variable: LIB_zlib
LIB_zlib-ADVANCED:INTERNAL=1

If you use the CMake GUI, don't forget to mark the "Advanced" option.

Then you can set the particular variables either via GUI or via command
line. You _may_ need to set the 'OPTION_USE_SYSTEM_LIB*:BOOL' variables
ON to make it work, but I'm not sure.

ISTR that I did this with self-built libs for Linux (maybe also for
Windows), but I can't find it right now. I'll try later.

I'm sorry I can't help further right now. In the future we should
probably add options to point directly at external (non-system)
libraries to use in the build, but that's not available now.

If you find a solution meanwhile, please post it here.

[Robin Rowe]

Albrecht,

> has it been fixed? (Note: I'm the one that currently does
> most of the CMake work for FLTK, although most parts have been developed
> by someone else).

FLTK 1.3.4 may not build on VS2017 without this...

if(win32)
add_definitions(-DWIN32)
endif()

While the above cmake fix works, the proper fix would be a global
replace so it is _WIN32 throughout the FLTK codebase. The old WIN32
define was deprecated and is no longer available as of VS2017.

> The CMake guys say you should "know" which libs are "always" available
> in the VS IDE environment an rely on these w/o searching.

I don't know why cmake isn't finding OpenGL on Windows. As CinePaint
isn't using OpenGL, I suppose that warning may be ignored.

Of course, the real issue is Zlib, libpng and libjpeg are never "always"
there for Windows. And if they were, it wouldn't help CinePaint.

CinePaint is an HDR paint app, supports images of all bit-depths
(8/16/32-bit). By default, libjpeg is not built with 12-bit JPEG support
because ordinary paint apps can only use 8-bit. By the way, the TIFF
library has a 64-bit option, not built by default.

> $ grep -i 'PNG\|ZLIB\|JPEG' CMakeCache.txt

Thanks for that clue. It led me to make the connection that it's an
issue with cmake find_file(). Adding the following to my cmake found my
lib headers for Zlib, libjpeg and libpng:

set(CMAKE_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/lib")

Thanks,

Robin

[Albrecht Schlosser]

To continue my own reply ...

On 28.12.2017 11:45 Albrecht Schlosser wrote:

>>> The VS git shell doesn't seem to get all the correct paths set up, at
>>> least for me.
>>
>> Yes, a known deficiency.
>
> The CMake guys say you should "know" which libs are "always" available

> in the VS IDE environment an[d] rely on these w/o searching. The warnings

> you showed in your first post can be ignored - at least in 1.4, I don't
> know if I fixed it in 1.3 as well. The best thing you can do is to
> trigger a CMake reconfigure from within the CMake IDE, for instance by
> touching (rewriting w/o modifying) the main CMakeLists.txt and rebuild
> target ZERO_CHECK. This should find all the three headers mentioned in
> these warnings:
>
>     -- HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
>     -- HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
>     -- HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'

Of course, once you found the correct values in your installation you
can preset these variables using the normal CMake way: cmake-gui,
ccmake, or commandline `cmake -D<your definition here> ...'.

>> Does anyone know how to point my cmake file to tell FLTK where to find
>> the OpenGL, Zlib, libpng and libjpeg libraries that I wish to use?

For OpenGL: see above. BTW: do you use an own one, or do you only want
to find the one bundled with VS (or the SDK)?

> I'll try to give you better advice later, but for now I can only suggest
> that you search for png, jpeg, and zlib (case insensitive) either via
> command line - using MinGW I can see:

[output elided, see previous post]

> If you use the CMake GUI, don't forget to mark the "Advanced" option.
>
> Then you can set the particular variables either via GUI or via command
> line. You _may_ need to set the 'OPTION_USE_SYSTEM_LIB*:BOOL' variables
> ON to make it work, but I'm not sure.
>
> ISTR that I did this with self-built libs for Linux (maybe also for
> Windows), but I can't find it right now. I'll try later.

Okay, here it is. It worked when I used it with FLTK 1.3.4, but there's
no guarantee it will work for you. This approach sets CMAKE_CXX_FLAGS
and others which is generally discouraged, but anyway it may give you
some hints to get you started. You'll have to edit paths to suit your
needs. See also comments marked with line numbers below.

1 cmake -G "Unix Makefiles" \
2 -D'CMAKE_BUILD_TYPE:STRING=Debug' \
3 -D'CMAKE_CXX_FLAGS:STRING=-I/path/to/libs/include' \
4 -D'CMAKE_C_FLAGS:STRING=-I/path/to/libs/include' \
5 -D'CMAKE_INSTALL_PREFIX:PATH=/path/to/libs/fltk-1.3' \
6 -D'HAVE_PNG_H:FILEPATH=/path/to/libs/include/png.h' \
7 -D'JPEG_INCLUDE_DIR:PATH=/path/to/libs/include' \
8 -D'JPEG_LIBRARY:FILEPATH=/path/to/libs/lib/libjpeg.a' \
9 -D'LIB_jpeg:FILEPATH=/path/to/libs/lib/libjpeg.a' \
10 -D'LIB_png:FILEPATH=/path/to/libs/lib/libpng.a' \
11 -D'LIB_zlib:FILEPATH=/path/to/libs/lib/libz.a' \
12 -D'PNG_LIBRARY:FILEPATH=/path/to/libs/lib/libpng.a' \
13 -D'PNG_PNG_INCLUDE_DIR:PATH=/path/to/libs/include' \
14 -D'ZLIB_INCLUDE_DIR:PATH=/path/to/libs/include' \
15 -D'ZLIB_LIBRARY:FILEPATH=/path/to/libs/lib/libz.a' \
16 -D'OPTION_ABI_VERSION:STRING=10304' \
17 -D'OPTION_BUILD_EXAMPLES:BOOL=OFF' \
18 -D'OPTION_BUILD_HTML_DOCUMENTATION:BOOL=OFF' \
19 -D'OPTION_BUILD_SHARED_LIBS:BOOL=OFF' \
20 -D'OPTION_OPTIM:STRING=-Wno-deprecated-declarations' \
21 /path/to/fltk-sources

(1) use VS Generator (or GUI), e.g. "Visual Studio 14 2015"

(2) maybe you shouldn't use this for VS generators ?

(3-4) provided 'other' libs were installed in /path/to/libs

(5) where you want your FLTK installation to go

(6-15) variables needed to find image libs and to configure FLTK
accordingly. We only used static libs (YMMV). It may be harder to
configure FLTK and depending builds to use the correct shared libraries
instead.

(16) optional: use all available ABI features

(17-19) optional: disable unnecessary parts of the build. YMMV

(20) optional: suppress (Linux/X11 specific) compiler warning

(21) your FLTK source directory


I'm aware that this is not a general way to build FLTK within a project
as you want to do. There should be an easier way than to set so many
non-obvious variables. However, this is *one* build FLTK 1.3.4 with
external, non-system, libs (jpeg, png, zlib), so this should give you a
start. I hope it helps.

When I have more time I'll try to improve this. Suggestions and patches
welcome.

[Albrecht Schlosser]

On 28.12.2017 21:25 Robin Rowe wrote:
> Albrecht,
>
>> has it been fixed? (Note: I'm the one that currently does most of the
>> CMake work for FLTK, although most parts have been developed by
>> someone else).
>
> FLTK 1.3.4 may not build on VS2017 without this...
>
> if(win32)
> add_definitions(-DWIN32)
> endif()

Oh, well, thanks for this! I thought we always did this in FLTK, but we
only did it in autoconf/configure/make builds.

Fixed in svn now (branch 1.3 and 1.4).

> While the above cmake fix works, the proper fix would be a global
> replace so it is _WIN32 throughout the FLTK codebase. The old WIN32
> define was deprecated and is no longer available as of VS2017.

I agree: this would be a better (more general) solution. I really don't
know why FLTK used to use WIN32 instead of _WIN32. We even require users
to #define WIN32 in their own projects (under Windows), at least with
some compilers, notably Visual Studio. If VS defined _WIN32 in all
current and older versions and other Windows compilers do this
consistently, this would be the way to go.

>> The CMake guys say you should "know" which libs are "always" available
>> in the VS IDE environment an rely on these w/o searching.
>
> I don't know why cmake isn't finding OpenGL on Windows. As CinePaint
> isn't using OpenGL, I suppose that warning may be ignored.

Yes, see my other post - with a workaround. It's only a warning anyway.

> Of course, the real issue is Zlib, libpng and libjpeg are never "always"
> there for Windows. And if they were, it wouldn't help CinePaint.
>
> CinePaint is an HDR paint app, supports images of all bit-depths
> (8/16/32-bit). By default, libjpeg is not built with 12-bit JPEG support
> because ordinary paint apps can only use 8-bit. By the way, the TIFF
> library has a 64-bit option, not built by default.
>
>> $ grep -i 'PNG\|ZLIB\|JPEG' CMakeCache.txt
>
> Thanks for that clue. It led me to make the connection that it's an
> issue with cmake find_file(). Adding the following to my cmake found my
> lib headers for Zlib, libjpeg and libpng:
>
> set(CMAKE_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/lib")

Looks like a clean solution, better than mine posted in my previous
post. However, maybe this is not enough if multiple library versions
exist in other paths. The linker may then find the wrong libraries and
you get incompatibilities. I suggest to test this thoroughly.

> Thanks,
> Robin

Welcome.