Trouble with CMake on macOS 11.4

[Daniel Harding]

Since I've already started building FLTK 1.4 with CMake on Windows, I thought I'd try to switch to CMake on all platforms.

I was able to switch from autoconf to cmake on Linux without any issues. (And it's a clear improvement over autoconf, btw.)

But on macOS, I am getting a linker error when building my application and linking with FLTK. (Using cmake 3.29.3)

First, this is how I configured FLTK:
cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")"

(I clone the fltk repo into the ./lib/fltk/ directory in my application repo, which is why I set the install prefix to "../..", to install fltk into the include/ and lib/ directories at the root of my repo. This works on Linux just fine and so I don't think it is related to the errors that I'm seeing on macOS.)

Then after running the cmake command, I ran make and make install (just like on Linux).

Then when I invoke my own project's Makefile, it fails while linking with the below error messages:

c++ -o bin/crystaltracker tmp/config.o tmp/directory-chooser.o tmp/edit-context-menu.o tmp/help-window.o tmp/hex-spinner.o tmp/it-module.o tmp/main-window.o tmp/main.o tmp/modal-dialog.o tmp/note-properties.o tmp/option-dialogs.o tmp/parse-drumkits.o tmp/parse-song.o tmp/parse-waves.o tmp/piano-roll.o tmp/preferences.o tmp/ruler.o tmp/song.o tmp/themes.o tmp/utils.o tmp/widgets.o tmp/cocoa.o -DNDEBUG -O3 -flto -std=c++17 -Isrc -Ires -I/Users/Daniel/gb/crystal-tracker/include -I/Users/Daniel/gb/crystal-tracker/include/FL/images -I/Users/Daniel/gb/crystal-tracker/include/png -I/Users/Daniel/gb/crystal-tracker/include/zlib -I/Users/Daniel/gb/crystal-tracker/include/jpeg -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT  lib/libportaudio.a lib/libportaudiocpp.a lib/libopenmpt.a -framework CoreAudio -framework AudioToolbox -framework AudioUnit -framework CoreFoundation -framework CoreServices lib/libfltk_images.a /usr/local/opt/libpng/lib/libpng.a  -lz /usr/local/Cellar/jpeg-turbo/2.1.5.1/lib/libjpeg.a  /Users/Daniel/gb/crystal-tracker/lib/libfltk.a -lm -lpthread -framework Cocoa -framework UniformTypeIdentifiers
undef: _fltk_png_error
undef: _fltk_png_get_tRNS
undef: _fltk_png_read_info
undef: _fltk_png_get_color_type
undef: _fltk_png_get_image_width
undef: _fltk_png_get_image_height
undef: _fltk_png_get_bit_depth
undef: _fltk_png_set_packing
undef: _fltk_png_set_strip_16
undef: _fltk_png_get_valid
undef: _fltk_png_set_tRNS_to_alpha
undef: _fltk_png_set_longjmp_fn
undef: _fltk_png_read_end
undef: _fltk_png_create_info_struct
undef: _fltk_png_destroy_read_struct
undef: _fltk_png_set_interlace_handling
undef: _fltk_png_get_io_ptr
undef: _fltk_png_set_read_fn
undef: _fltk_png_set_expand
undef: _fltk_png_create_read_struct
undef: _fltk_png_init_io
undef: _fltk_png_read_rows
Undefined symbols for architecture x86_64:
  "_fltk_png_error", referenced from:
      png_read_data_from_mem(png_struct_def*, unsigned char*, unsigned long) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_tRNS", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_read_info", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_color_type", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_image_width", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_image_height", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_bit_depth", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_packing", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_strip_16", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_valid", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_tRNS_to_alpha", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_longjmp_fn", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_read_end", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_create_info_struct", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_destroy_read_struct", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_interlace_handling", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_get_io_ptr", referenced from:
      png_read_data_from_mem(png_struct_def*, unsigned char*, unsigned long) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_read_fn", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_set_expand", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_create_read_struct", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_init_io", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
  "_fltk_png_read_rows", referenced from:
      Fl_PNG_Image::load_png_(char const*, int, unsigned char const*, int) in libfltk_images.a(Fl_PNG_Image.cxx.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [bin/crystaltracker] Error 1

Sorry for the wall of text, but I figured the full link command and error output would be useful.

I gave a quick read through README.CMake.txt but didn't spot anything obvious that I should be doing differently. (For example, it mentions passing -G Xcode to cmake but my impression is that that is only necessary if I plan on using the XCode IDE, which I do not.)

This is probably simple user-error, but I'm unsure how to fix it so I thought I'd post here in case someone else can spot my mistake.

If there's additional useful information I can provide about how I am building FLTK or my application please let me know. Thanks!

P.S. Not related to the error, but possibly useful context..

I also tried configuring CMake with -D CMAKE_OSX_DEPLOYMENT_TARGET="11.0" which removed some warnings, but didn't change the error during linking.

The warning was:

ld: warning: object file (...) was built for newer macOS version (11.4) than being linked (11.0)

So I added to CMAKE_OSX_DEPLOYMENT_TARGET to suppress the warning and to see if it would help with the error, but it did not.

[Albrecht Schlosser]

On 5/11/24 20:52 Daniel Harding wrote:

Since I've already started building FLTK 1.4 with CMake on Windows, I thought I'd try to switch to CMake on all platforms.

I was able to switch from autoconf to cmake on Linux without any issues. (And it's a clear improvement over autoconf, btw.)

But on macOS, I am getting a linker error when building my application and linking with FLTK. (Using cmake 3.29.3)

First, this is how I configured FLTK:
cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")"

(I clone the fltk repo into the ./lib/fltk/ directory in my application repo, which is why I set the install prefix to "../..", to install fltk into the include/ and lib/ directories at the root of my repo. This works on Linux just fine and so I don't think it is related to the errors that I'm seeing on macOS.)

Then after running the cmake command, I ran make and make install (just like on Linux).

Then when I invoke my own project's Makefile, it fails while linking with the below error messages:

c++ -o bin/crystaltracker tmp/config.o tmp/directory-chooser.o tmp/edit-context-menu.o tmp/help-window.o tmp/hex-spinner.o tmp/it-module.o tmp/main-window.o tmp/main.o tmp/modal-dialog.o tmp/note-properties.o tmp/option-dialogs.o tmp/parse-drumkits.o tmp/parse-song.o tmp/parse-waves.o tmp/piano-roll.o tmp/preferences.o tmp/ruler.o tmp/song.o tmp/themes.o tmp/utils.o tmp/widgets.o tmp/cocoa.o -DNDEBUG -O3 -flto -std=c++17 -Isrc -Ires -I/Users/Daniel/gb/crystal-tracker/include -I/Users/Daniel/gb/crystal-tracker/include/FL/images -I/Users/Daniel/gb/crystal-tracker/include/png -I/Users/Daniel/gb/crystal-tracker/include/zlib -I/Users/Daniel/gb/crystal-tracker/include/jpeg -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT  lib/libportaudio.a lib/libportaudiocpp.a lib/libopenmpt.a -framework CoreAudio -framework AudioToolbox -framework AudioUnit -framework CoreFoundation -framework CoreServices lib/libfltk_images.a /usr/local/opt/libpng/lib/libpng.a  -lz /usr/local/Cellar/jpeg-turbo/2.1.5.1/lib/libjpeg.a  /Users/Daniel/gb/crystal-tracker/lib/libfltk.a -lm -lpthread -framework Cocoa -framework UniformTypeIdentifiers
undef: _fltk_png_error
undef: _fltk_png_get_tRNS
undef: _fltk_png_read_info

[...]

It's clear that your build misses the FLTK PNG lib (_fltk_png*) but tries to link the system PNG and JPEG libs instead:
> /usr/local/opt/libpng/lib/libpng.a  -lz /usr/local/Cellar/jpeg-turbo/2.1.5.1/lib/libjpeg.a

... which provide "the same" symbols (functions) w/o the '_fltk' prefix. We need to find out why your project doesn't "find" the correct ZLIB, PNG, and JPEG libs...

I'm not sure why this happens though.

Sorry for the wall of text, but I figured the full link command and error output would be useful.

Better more than less.

I gave a quick read through README.CMake.txt but didn't spot anything obvious that I should be doing differently. (For example, it mentions passing -G Xcode to cmake but my impression is that that is only necessary if I plan on using the XCode IDE, which I do not.)

That's correct, you have the choice to use Xcode or any other CMake generator, e.g. "Unix Makefiles" or "Ninja" which I prefer.

This is probably simple user-error, but I'm unsure how to fix it so I thought I'd post here in case someone else can spot my mistake.

It's maybe not a user error in your project. I have a suspicion but I would need to test this myself.

If there's additional useful information I can provide about how I am building FLTK or my application please let me know. Thanks!

I may come back to you if I need more info. One quick test would be to include '/path/to/fltk/CMake/fl_debug_var.cmake' in your build and then, after FLTK has been found and configured, execute: 'fl_debug_target(fltk::images)' and 'fl_debug_target(fltk::images-shared)'. The latter may issue "not a target" if you didn't build it but that doesn't matter. Please post the output here.

P.S. Not related to the error, but possibly useful context..

I also tried configuring CMake with -D CMAKE_OSX_DEPLOYMENT_TARGET="11.0" which removed some warnings, but didn't change the error during linking.

The warning was:

ld: warning: object file (...) was built for newer macOS version (11.4) than being linked (11.0)

That's something I can't help with, but maybe Manolo. I believe it would be "interesting" which "object file (...)" is mentioned in the warning message. It may be something of your Homebrew installation ("/usr/local/Cellar/..." in your log above indicates that you have Homebrew installed).

[Daniel Harding]

On Sunday, May 12, 2024 at 8:46:03 AM UTC-5 Albrecht-S wrote:

It's clear that your build misses the FLTK PNG lib (_fltk_png*) but tries to link the system PNG and JPEG libs instead:

> /usr/local/opt/libpng/lib/libpng.a  -lz /usr/local/Cellar/jpeg-turbo/2.1.5.1/lib/libjpeg.a

... which provide "the same" symbols (functions) w/o the '_fltk' prefix. We need to find out why your project doesn't "find" the correct ZLIB, PNG, and JPEG libs...

I'm not sure why this happens though.

ISTR when originally setting up my project for Mac and figuring out how to build and link FLTK (1.3.8) with autoconf, I had trouble with libpng, because (modern?) libpng is not a standard library on Mac.

However, the output for ./fltk-config --use-images --ldstaticflags is:

./lib/libfltk_images.a -lpng -lz -ljpeg ./lib/libfltk.a -lpthread -framework Cocoa

which failed to build my program due to "-lpng". (Either libpng was missing or unusablely old, I don't remember.)

So I manually installed libpng at /usr/local/opt/libpng/lib, and then I want to link with libpng statically and not dynamically, because I don't want to make my users dependent on a "custom" installation path of libpng (which means that the "-lpng" output of fltk-config is unusable).

To link libpng statically, I remove --use-images from the fltk-config command and specify the linker flags for libpng.a using pkg-config instead. (Then I'm pretty sure the only reason that I link libjpeg in the same way is because removing "-lpng" also removes "-ljpeg" too. libjpeg was not the source of any problems itself that I can recall.)

Just an observation: If I configure CMake with -D FLTK_USE_SYSTEM_LIBPNG=ON, I notice this in the configure output:

-- System PNG or ZLIB not usable, falling back to local PNG for compatibility.

but it doesn't elaborate on why it's "not usable".

If I continue with make && make install after the CMake config, that's how I get the linker errors mentioned in the OP when building my application (with my usual Makefile).

But I've just realized that now the output of ./fltk-config --use-images --ldstaticflags is now:

/Users/Daniel/gb/crystal-tracker/lib/libfltk_images.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_jpeg.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_png.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_z.a /Users/Daniel/gb/crystal-tracker/lib/libfltk.a -lm -lpthread -framework Cocoa -framework UniformTypeIdentifiers

Very different than with autoconf! So maybe I don't need my "special handling" for libpng linker flags in my Makefile anymore.. When I add back --use-images to my Makefile, I then have errors with my other main dependency (an audio library) unable to link with zlib functions (the error output even says things like "(maybe you meant: _fltk_z_inflateEnd)").

But after I add "-lz" explicitly in my linker flags, the build is successful.

So it was user-error after all. I think it works well. I'm certainly not going to complain about being able to delete some quirky code from my Makefile.

I would guess that what I should have done at the very beginning was tell autogen.sh to use the bundled libpng somehow and maybe that would have avoided the whole problem.

Thanks for the rubber duck troubleshooting. Writing this out helped.

I may come back to you if I need more info. One quick test would be to include '/path/to/fltk/CMake/fl_debug_var.cmake' in your build and then, after FLTK has been found and configured, execute: 'fl_debug_target(fltk::images)' and 'fl_debug_target(fltk::images-shared)'. The latter may issue "not a target" if you didn't build it but that doesn't matter. Please post the output here.

Sorry, my ignorance of CMake makes it difficult to figure out how to accomplish what you're asking. My project doesn't use CMake, just a (relatively) simple Makefile. Are these commands things that I would add to the FLTK CMake build process?

I believe it would be "interesting" which "object file (...)" is mentioned in the warning message. It may be something of your Homebrew installation ("/usr/local/Cellar/..." in your log above indicates that you have Homebrew installed).

Sorry, I probably shouldn't have omitted the object file. The warning messages refer to libfltk.a and libfltk_images.a, like so:

ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_draw.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)
ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_contrast.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)
ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_color.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)

And so on for each .cxx/.o file.

[Albrecht Schlosser]

On 5/12/24 23:33 Daniel Harding wrote:

On Sunday, May 12, 2024 at 8:46:03 AM UTC-5 Albrecht-S wrote:

It's clear that your build misses the FLTK PNG lib (_fltk_png*) but tries to link the system PNG and JPEG libs instead:

> /usr/local/opt/libpng/lib/libpng.a  -lz /usr/local/Cellar/jpeg-turbo/2.1.5.1/lib/libjpeg.a

... which provide "the same" symbols (functions) w/o the '_fltk' prefix. We need to find out why your project doesn't "find" the correct ZLIB, PNG, and JPEG libs...

I'm not sure why this happens though.

ISTR when originally setting up my project for Mac and figuring out how to build and link FLTK (1.3.8) with autoconf, I had trouble with libpng, because (modern?) libpng is not a standard library on Mac.

However, the output for ./fltk-config --use-images --ldstaticflags is:

./lib/libfltk_images.a -lpng -lz -ljpeg ./lib/libfltk.a -lpthread -framework Cocoa

which failed to build my program due to "-lpng". (Either libpng was missing or unusablely old, I don't remember.)

So I manually installed libpng at /usr/local/opt/libpng/lib, and then I want to link with libpng statically and not dynamically, because I don't want to make my users dependent on a "custom" installation path of libpng (which means that the "-lpng" output of fltk-config is unusable).

To link libpng statically, I remove --use-images from the fltk-config command and specify the linker flags for libpng.a using pkg-config instead. (Then I'm pretty sure the only reason that I link libjpeg in the same way is because removing "-lpng" also removes "-ljpeg" too. libjpeg was not the source of any problems itself that I can recall.)

Just an observation: If I configure CMake with -D FLTK_USE_SYSTEM_LIBPNG=ON, I notice this in the configure output:

-- System PNG or ZLIB not usable, falling back to local PNG for compatibility.

but it doesn't elaborate on why it's "not usable".

The CMake configure process should have told you which one was found and which one could not be found, e.g. (tested on my Linux system):

$ cmake -G Ninja -D FLTK_USE_SYSTEM_LIBPNG=OFF ../..
...
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.13")
-- System PNG or ZLIB not usable, falling back to local ZLIB for compatibility.

In this case, ZLIB was found but PNG was forced to use the bundled lib. Since both must use the same source (either system or bundled), the message says that ZLIB couldn't be used as system lib. In your case CMake didn't find the system PNG lib.

If I continue with make && make install after the CMake config, that's how I get the linker errors mentioned in the OP when building my application (with my usual Makefile).

But I've just realized that now the output of ./fltk-config --use-images --ldstaticflags is now:

/Users/Daniel/gb/crystal-tracker/lib/libfltk_images.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_jpeg.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_png.a /Users/Daniel/gb/crystal-tracker/lib/libfltk_z.a /Users/Daniel/gb/crystal-tracker/lib/libfltk.a -lm -lpthread -framework Cocoa -framework UniformTypeIdentifiers

Very different than with autoconf! So maybe I don't need my "special handling" for libpng linker flags in my Makefile anymore.. When I add back --use-images to my Makefile, I then have errors with my other main dependency (an audio library) unable to link with zlib functions (the error output even says things like "(maybe you meant: _fltk_z_inflateEnd)").

But after I add "-lz" explicitly in my linker flags, the build is successful.

Yup, this should be OK. The result is that your application includes zlib twice: once the bundled and prefixed one provided by FLTK and the system provided one. Since our version has these prefixes, there are no conflicts but it's a waste of memory because the program is bigger.

So it was user-error after all. I think it works well. I'm certainly not going to complain about being able to delete some quirky code from my Makefile.

I would guess that what I should have done at the very beginning was tell autogen.sh to use the bundled libpng somehow and maybe that would have avoided the whole problem.

Yes, that would have been one possibility.

Thanks for the rubber duck troubleshooting. Writing this out helped.

Wow, that's a lot of info. Important info. First I need to say that I misinterpreted your report, I got the impression that you built your own application with CMake as well. Now I know that this assumption was wrong. I do also think that I can follow your explanation about what you did in the past and now to "fix" it.

For clarification of one main difference of your old (autoconf) build of FLTK 1.3 and the new (CMake) build of 1.4 you should know: since FLTK 1.4 we are using a "prefix" when building our bundled image libraries. This is especially important when using shared libraries and serves the purpose not to mix different libpng versions (ABI-wise) in FLTK and other shared libs (on Linux e.g. the GTK libs loaded dynamically). Since libpng depends on zlib it is important to use either both as bundled libs (with prefix) or both as system libs (w/o prefix). libjpeg is independent of this and can be used either as a system lib or as the bundled version.

As could be seen in your posted build command you had
(a) '-I/Users/Daniel/gb/crystal-tracker/include/png' - which includes the libpng header files bundled with FLTK and
(b) '/usr/local/opt/libpng/lib/libpng.a' - which links the "system" libpng.

If we didn't use the "prefixed" libs then the symbol names would match and your build would succeed - although the ABI of these libs might be different. That would lead to unpredictable errors during runtime. Since we are using the prefixed function names, the linker can't find them, and the build fails if you don't linke the correct libs. That's intended.

Since the FLTK image libs are compiled with the "prefixed" headers you need to link the FLTK image libs (fltk_png and fltk_z) with your program. The object files in the static libs require this, and there shouldn't be conflicts with the system libs.

If you compile your own source files by including the FLTK headers (as seen above), then your own code uses the prefixed symbol names as well and must link to the FLTK versions of the library. You could remove the system libs from your Makefile and link (only) the FLTK image libs. OTOH you can also build your own program using the system libs (those you installed manually) but then you must not include the FLTK headers of the bundled FLTK libs when compiling your own code.

You can also make FLTK use the system libs, but this will need some tweaks of the FLTK build process. I'm not sure how you can convince the CMake process to find the system libpng. Our CMake code uses 'find_package(PNG)', hence you may need to add its location to CMAKE_PREFIX_PATH or run `cmake` with '-D PNGDIR=...' or something like that. I'm only guessing, and it's too late here to investigate further. FLTK's CMake configure log should show at the end if you succeeded (if you tried it). It tells you which system libs are used, or which libs are "bundled".

I may come back to you if I need more info. One quick test would be to include '/path/to/fltk/CMake/fl_debug_var.cmake' in your build and then, after FLTK has been found and configured, execute: 'fl_debug_target(fltk::images)' and 'fl_debug_target(fltk::images-shared)'. The latter may issue "not a target" if you didn't build it but that doesn't matter. Please post the output here.

Sorry, my ignorance of CMake makes it difficult to figure out how to accomplish what you're asking. My project doesn't use CMake, just a (relatively) simple Makefile. Are these commands things that I would add to the FLTK CMake build process?

These commands were intended to be used in your own (CMake based) build process, which turned out to be a wrong assumption on my side. The big advantage of the new "modern CMake" approach in FLTK 1.4 is that your own CMake build would benefit from many simplifications. In your case, however, you are using fltk-config and need to "know" which libs you need to link to.

I believe it would be "interesting" which "object file (...)" is mentioned in the warning message. It may be something of your Homebrew installation ("/usr/local/Cellar/..." in your log above indicates that you have Homebrew installed).

Sorry, I probably shouldn't have omitted the object file. The warning messages refer to libfltk.a and libfltk_images.a, like so:

ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_draw.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)
ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_contrast.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)
ld: warning: object file (/Users/Daniel/gb/crystal-tracker/lib/libfltk.a(fl_color.cxx.o)) was built for newer macOS version (11.4) than being linked (11.0)

And so on for each .cxx/.o file.

OK, then the warning concerns FLTK files. However, I don't know how to "fix" this. Someone with more macOS knowledge may be able to help.

[Daniel Harding]

On Sunday, May 12, 2024 at 7:22:13 PM UTC-5 Albrecht-S wrote:

First I need to say that I misinterpreted your report, I got the impression that you built your own application with CMake as well.

Sorry, one part of my OP was worded weirdly. My fault.

I'm not sure how you can convince the CMake process to find the system libpng. Our CMake code uses 'find_package(PNG)', hence you may need to add its location to CMAKE_PREFIX_PATH or run `cmake` with '-D PNGDIR=...' or something like that.

For the sake of only linking with one version of zlib, I tried to figure out how to get CMake to use my system libpng. I started testing with CMAKE_PREFIX_PATH but found that that actually isn't necessary. The path to libpng is already configured correctly with pkg-config, which CMake uses. The issue was that I needed to specify both FLTK_USE_SYSTEM_LIBPNG=ON and FLTK_USE_SYSTEM_ZLIB=ON. I was incorrectly assuming that just FLTK_USE_SYSTEM_LIBPNG would be sufficient in order for options.cmake to at least attempt to use (both) system libraries. Not a big deal.

This was enough to do the whole build without the bundled libraries, but I noticed the cmake configure output said:
PNG      = System: /usr/local/opt/libpng/lib/libpng.dylib

I thought it was interesting that it mentions libpng.dylib and not libpng.a. (Later when compiling my program I statically link with libpng.a, not dynamically link with libpng.dylib, but I'm not sure if this matters to FLTK at this point.)

Regardless, I'm able to build FLTK and my program like usual.

When I run my program, it immediately logs this:

libpng warning: Application built with libpng-1.4.12 but running with 1.6.39

1.6.39 is the version of my system libpng.a (verified with pkg-config --modversion libpng).

I'm not sure where 1.4.12 is coming from. Maybe the version of the .dylib file?

I'll keep looking into this, but thought I'd report on my progress. Thanks.

[Daniel Harding]

I'm getting pretty stumped.

I've tried setting CMAKE_PREFIX_PATH to different values to force it to look in different directories, I've tried uninstalling libpng 1.6.39 and reinstalling libpng 1.6.43 via homebrew, but no matter what the cmake config output claims that libpng is 1.4.12. These are all the different examples of output I got from CMake based on trying different things:

-- Found PNG: /usr/local/opt/libpng/lib/libpng.dylib (found version "1.4.12")

-- Found PNG: /usr/local/lib/libpng.dylib (found version "1.4.12")

-- Found PNG: /usr/local/Cellar/libpng/1.6.39/lib/libpng.dylib (found version "1.4.12")

-- Found PNG: /usr/local/Cellar/libpng/1.6.43/lib/libpng.dylib (found version "1.4.12")

Any advice in this situation?

[Albrecht Schlosser]

On 5/16/24 06:46 Daniel Harding wrote:

On Sunday, May 12, 2024 at 7:22:13 PM UTC-5 Albrecht-S wrote:

I'm not sure how you can convince the CMake process to find the system libpng. Our CMake code uses 'find_package(PNG)', hence you may need to add its location to CMAKE_PREFIX_PATH or run `cmake` with '-D PNGDIR=...' or something like that.

For the sake of only linking with one version of zlib, I tried to figure out how to get CMake to use my system libpng. I started testing with CMAKE_PREFIX_PATH but found that that actually isn't necessary. The path to libpng is already configured correctly with pkg-config, which CMake uses.

CMake *can* use pkg-config and we use it in our CMake files but definitely not for the three bundled libs. For these we use find_package(XXX) which (IMHO) does not use pkg-config in the general case - unless one of the FindXXX.cmake modules falls back to pkg-config if it doesn't find the libs by other means. I didn't check this for these libs though (no time to do it).

The issue was that I needed to specify both FLTK_USE_SYSTEM_LIBPNG=ON and FLTK_USE_SYSTEM_ZLIB=ON. I was incorrectly assuming that just FLTK_USE_SYSTEM_LIBPNG would be sufficient in order for options.cmake to at least attempt to use (both) system libraries. Not a big deal.

That's correct. Each of these bundled libs can theoretically be used independently as system or bundled lib, but we enforce that libpng and zlib are either both system or both bundled because libpng depends on zlib. The assumption is that system libs are always compatible with each other but a system zlib is not necessarily compatible with our bundled libpng.

Unfortunately everything is different if you use macOS. Therefore we set the default on macOS to "bundled" for all bundled libs.

The problem begins if you install one of these libs with homebrew or any other tool (and there are several for macOS). Unfortunately macOS provides its own ZLIB but none of the other libs. See more below and in my reply to your follow-up post.

This was enough to do the whole build without the bundled libraries, but I noticed the cmake configure output said:
PNG      = System: /usr/local/opt/libpng/lib/libpng.dylib

I thought it was interesting that it mentions libpng.dylib and not libpng.a. (Later when compiling my program I statically link with libpng.a, not dynamically link with libpng.dylib, but I'm not sure if this matters to FLTK at this point.)

It can certainly matter...

Regardless, I'm able to build FLTK and my program like usual.

When I run my program, it immediately logs this:

libpng warning: Application built with libpng-1.4.12 but running with 1.6.39

1.6.39 is the version of my system libpng.a (verified with pkg-config --modversion libpng).

I'm not sure where 1.4.12 is coming from. Maybe the version of the .dylib file?

I'll keep looking into this, but thought I'd report on my progress. Thanks.

This is the kind of incompatibility you must certainly avoid. If "built with 1.4.12" means that you compiled with the headers of 1.4.12 and you use 1.6.39 at runtime, then it is almost sure that the ABI is different and can lead to all kinds of bugs. Using pkg-config alone doesn't mean that what pkg-config finds is the only library on your system.

[Albrecht Schlosser]

I'll try.

First of all, you should always keep in mind that CMake caches the results of all find* calls. It's always a good idea to clear the cache, but you can easily forget it - or there is an internal variable you miss - and then you can try whatever you want, you'll always get the same results. Been there, done that...

Such a caching issue **might** cause the weird version numbers you posted above. Maybe it's a wrong output, I don't know.

Looking at the paths you listed above I'm wondering: it looks like this is all from Homebrew, but maybe you installed an older version than I did, or you are using an Intel system rather than an M1 system as I do. ISTR that the installation folders of Homebrew changed over time and can be different on these old/new processors. It would be worth checking where all these libs come from, and maybe removing unused libs...

I think on modern M1 processors (like mine) Homebrew installs to /opt/homebrew.

As an example I tried to convince CMake to "find" the zlib installed by Homebrew rather than the one from macOS. The only way I found so far was to set some cache variables with cmake-gui in "advanced" mode. Unfortunately I had to manually set a lot more CMake variables than I had anticipated, like this screenshot shows:



If you want to go that route, here is what I did (after the first cmake-configure run):

1. run cmake-gui, check the "Advanced" mode, and enter "zlib" in the "Search" field.
2. enter one or more values (cache variables) as given above (adjust the paths for your system)
3. click Configure
4. watch the output: if it changes anything you need to set one or more different variables

The cache variables in question are shown after the first configure process. If any variable includes the macOS version, overwrite it with the Homebrew path and "configure" again.

I believe that ZLIB_LIBRARY_RELEASE and ZLIB_LIBRARY_DEBUG don't need to be set by you (can't remember exactly). These are the results of the configure process. You can safely ignore ZLIB_LIBRARY_DEBUG which is "...-NOTFOUND".

Before you run a new configure process you can select these variables and use the "Remove Entry" button to delete them from the cache. Multiple select are possible.

Note that I used the static zlib for this example but it's up to you which one you want to configure.

You would need to do similar things with libpng, and (if it matters) libjpeg.

When you are satisfied with the result, use a script to run CMake with all these variables as '-D...' on the commandline and you should be able to preset exactly the libs you want, including their include directories. Hopefully.

That said, if you decided to build your own project with CMake as well you could benefit from FLTK's CONFIG mode that can import all the required libs to your own project. This *could* simplify your task, but YMMV.

Another point: I believe that you could try `fltk-config --use-images --ldstaticflags` if you want to use the correct libs from FLTK's build process and link statically. Once you convinced the FLTK build to use the libs you want, this combination (with '--use-images'!) should give you what you need for your project. But this is only the theory, there may be other issues...

Good luck! Feedback welcome.

[Daniel Harding]

On Thursday, May 16, 2024 at 3:22:53 PM UTC-5 Albrecht-S wrote:

First of all, you should always keep in mind that CMake caches the results of all find* calls. It's always a good idea to clear the cache, but you can easily forget it - or there is an internal variable you miss - and then you can try whatever you want, you'll always get the same results. Been there, done that...

To avoid any doubt, I've always ran this before every re-configure:

rm .gitignore && git clean -df && git reset --hard HEAD

There might be a simpler CMake command for doing the equivalent, but this way I "know" it's done fully and completely.

Unfortunately I had to manually set a lot more CMake variables than I had anticipated, like this screenshot shows:

[...]

When you are satisfied with the result, use a script to run CMake with all these variables as '-D...' on the commandline and you should be able to preset exactly the libs you want, including their include directories. Hopefully.

Thanks for these suggestions. I was able to resolve all issues with CMake on my mac this way. I ended up with these configuration options:

cmake \
-D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")" \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_OSX_DEPLOYMENT_TARGET="$(sw_vers -productVersion | cut -d '.' -f 1).0" \
-D FLTK_USE_SYSTEM_LIBPNG=ON \
-D PNG_PNG_INCLUDE_DIR="$(pkg-config --cflags-only-I libpng | cut -d ' ' -f 1 | cut -c 3-)" \
-D PNG_LIBRARY_RELEASE="$(pkg-config --static --libs-only-L libpng | cut -d ' ' -f 1 | cut -c 3-)/libpng.a" \
-D LIB_png="$(pkg-config --static --libs-only-L libpng | cut -d ' ' -f 1 | cut -c 3-)/libpng.a" \
-D FLTK_USE_SYSTEM_ZLIB=ON \
-D ZLIB_INCLUDE_DIR="$(pkg-config --cflags-only-I zlib | cut -c 3-)" \
-D ZLIB_LIBRARY_RELEASE="$(pkg-config --static --libs-only-L zlib | cut -c 3-)/libz.a" \
-D LIB_zlib="$(pkg-config --static --libs-only-L zlib | cut -c 3-)/libz.a"

Compared to my usual options on Linux:

cmake -D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")" -D CMAKE_BUILD_TYPE=Release

These options allow me to use "system" (homebrew) versions of both libpng and zlib (while still using the bundled libjpeg), with static linking, with only 1 copy of zlib in the executable, and without the "libpng warning: Application built with libpng-1.4.12 but running with 1.6.39" warning that I mentioned previously.

It's a bit ugly, but it allows me to flexibly refer to the lib dirs and include dirs of each library.

Another point: I believe that you could try `fltk-config --use-images --ldstaticflags` if you want to use the correct libs from FLTK's build process and link statically. Once you convinced the FLTK build to use the libs you want, this combination (with '--use-images'!) should give you what you need for your project. But this is only the theory, there may be other issues...

Yes, this is working correctly now. Like mentioned previously in the thread, I've never been able to use --use-images with FLTK 1.3 on Mac because its output would include -lpng.
But with the new cmake configuration options, `fltk-config --use-images --ldstaticflags` now outputs the paths to the .a files that I provided to cmake.

Somewhat related though, I have one concern.

The output of `fltk-config --use-images --cxxflags` includes (among other things):
-I/Users/Daniel/gb/crystal-tracker/include/FL/images

And the ./include/FL/images/ directory contains header files for all 3 libraries: libjpeg, libpng, and zlib.

If I use fltk-config in my Makefile to help control my cxx compiler flags, and fltk-config tells the cxx compiler to include libpng/zlib headers that correspond to the "bundled" libraries, but my project links with the system libpng and zlib libraries, then isn't this another source of unexpected compiler errors?

Should `cmake -D ... && make && make install` copy only the header files for libraries which are actually bundled (libjpeg in my case)?

Good luck! Feedback welcome.

I appreciate your help as always.

[Albrecht Schlosser]

On 5/18/24 04:57 Daniel Harding wrote:

On Thursday, May 16, 2024 at 3:22:53 PM UTC-5 Albrecht-S wrote:

To avoid any doubt, I've always ran this before every re-configure:

rm .gitignore && git clean -df && git reset --hard HEAD

Yes, this might work if you don't intend to change (patch) anything in the FLTK source tree.

There might be a simpler CMake command for doing the equivalent, but this way I "know" it's done fully and completely.

An easier way would be to build FLTK in a really separate build tree (not inside the source tree) so you can delete the entire build tree, although this separate build tree can also be a subdirectory, e.g. build/debug inside the FLTK root. YMMV

Unfortunately I had to manually set a lot more CMake variables than I had anticipated, like this screenshot shows:

[...]

When you are satisfied with the result, use a script to run CMake with all these variables as '-D...' on the commandline and you should be able to preset exactly the libs you want, including their include directories. Hopefully.

Thanks for these suggestions.

Welcome. I'm also learning how to do such things while trying to help users like you. ;-)

I was able to resolve all issues with CMake on my mac this way. I ended up with these configuration options:

cmake \
-D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")" \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_OSX_DEPLOYMENT_TARGET="$(sw_vers -productVersion | cut -d '.' -f 1).0" \
-D FLTK_USE_SYSTEM_LIBPNG=ON \
-D PNG_PNG_INCLUDE_DIR="$(pkg-config --cflags-only-I libpng | cut -d ' ' -f 1 | cut -c 3-)" \
-D PNG_LIBRARY_RELEASE="$(pkg-config --static --libs-only-L libpng | cut -d ' ' -f 1 | cut -c 3-)/libpng.a" \
-D LIB_png="$(pkg-config --static --libs-only-L libpng | cut -d ' ' -f 1 | cut -c 3-)/libpng.a" \
-D FLTK_USE_SYSTEM_ZLIB=ON \
-D ZLIB_INCLUDE_DIR="$(pkg-config --cflags-only-I zlib | cut -c 3-)" \
-D ZLIB_LIBRARY_RELEASE="$(pkg-config --static --libs-only-L zlib | cut -c 3-)/libz.a" \
-D LIB_zlib="$(pkg-config --static --libs-only-L zlib | cut -c 3-)/libz.a"

To make this work (in my test environment with homebrew) I also had to ...

$ export PKG_CONFIG_PATH="/opt/homebrew/opt/zlib/lib/pkgconfig"

as homebrew suggested:

"For pkg-config to find zlib you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/zlib/lib/pkgconfig"

Compared to my usual options on Linux:

cmake -D CMAKE_INSTALL_PREFIX="$(realpath "$PWD/../..")" -D CMAKE_BUILD_TYPE=Release

Yes, it's much more complicated but this is due to the lack of full integration of these libs in macOS. I think we *could* convince CMake to search for these libs in the FLTK CMake files if we only knew what users like you expect in this case (no offense intended, it's a legit issue). But I have no idea how to do this in the general case. Also, there is Fink and macPorts and whatever, it's hard to tell where to search. It's obviously much easier if you use the default Linux packages but I guess it could become similarly complicated to your solution above if you wanted to use self-built libs on Linux for some reasons. Let's not talk about Windows and additional libs on that platform. Sigh.

These options allow me to use "system" (homebrew) versions of both libpng and zlib (while still using the bundled libjpeg), with static linking, with only 1 copy of zlib in the executable, and without the "libpng warning: Application built with libpng-1.4.12 but running with 1.6.39" warning that I mentioned previously.

Yep, that's good!

It's a bit ugly, but it allows me to flexibly refer to the lib dirs and include dirs of each library.

Another point: I believe that you could try `fltk-config --use-images --ldstaticflags` if you want to use the correct libs from FLTK's build process and link statically. Once you convinced the FLTK build to use the libs you want, this combination (with '--use-images'!) should give you what you need for your project. But this is only the theory, there may be other issues...

Yes, this is working correctly now. Like mentioned previously in the thread, I've never been able to use --use-images with FLTK 1.3 on Mac because its output would include -lpng.
But with the new cmake configuration options, `fltk-config --use-images --ldstaticflags` now outputs the paths to the .a files that I provided to cmake.

Great, thank you for the confirmation, I had hoped that it would work this way.

Somewhat related though, I have one concern.

The output of `fltk-config --use-images --cxxflags` includes (among other things):
-I/Users/Daniel/gb/crystal-tracker/include/FL/images

And the ./include/FL/images/ directory contains header files for all 3 libraries: libjpeg, libpng, and zlib.

Oh, oh, ...

If I use fltk-config in my Makefile to help control my cxx compiler flags, and fltk-config tells the cxx compiler to include libpng/zlib headers that correspond to the "bundled" libraries, but my project links with the system libpng and zlib libraries, then isn't this another source of unexpected compiler errors?

Absolutely correct. It would depend on the order of '-I' flags, but yes, this can be a cause of trouble, and it would be fragile to rely on the "correct" order of include directories.

Side note: this is a general problem I'm contemplating about: if we search for libs in several places and add multiple '-I' flags, how can we ensure that the compiler always finds the correct set of header files if there is more than one for a particular library? We have such examples, especially (again) on macOS.

Should `cmake -D ... && make && make install` copy only the header files for libraries which are actually bundled (libjpeg in my case)?

It's complicated, I can't give you a quick and correct answer to this question right now. We could probably do as you suggest, i.e. copy only the headers of the libs that are used as "bundled" libs and not those used as system libs. But in the context of fltk-config it's more complicated because there is one that is used on the FLTK build directory itself and one that gets installed with the lib(s). I really need to look into the details. Thanks for the heads-up.