Regression in CMake-based build

36 views
Skip to first unread message

Manolo

unread,
Aug 26, 2020, 5:33:23 AM8/26/20
to fltk.coredev

CMake no longer builds correctly test apps on the macOS platform
when OPTION_APPLE_X11 is turned ON. That's a regression.
The problem is that all test apps are put inside macOS bundles
rather than as plain executable files. These apps should be
processed by CMake as is fluid which CMake still correctly builds
as a plain executable file, to BUILD/fluid.

Albrecht Schlosser

unread,
Aug 26, 2020, 6:52:20 AM8/26/20
to fltkc...@googlegroups.com
FTR: Isn't this BUILD/bin/fluid ?

Regression fixed in 2f26170a2a6.

Thanks for the report.

I had tried to simplify the CMake code too much: CMake ignores options
not relevant on particular platforms, so I used the options "WIN32
MACOSX_BUNDLE" simultaneously, but that is not correct if X11 is used
under macOS.

Manolo

unread,
Aug 26, 2020, 8:10:10 AM8/26/20
to fltk.coredev
On Wednesday, August 26, 2020 at 12:52:20 PM UTC+2 Albrecht Schlosser wrote:

FTR: Isn't this BUILD/bin/fluid ?
Yes.


Regression fixed in 2f26170a2a6.
I can confirm it's fixed having run it on macOS.
Many thanks.


Greg Ercolano

unread,
Aug 29, 2020, 11:15:06 AM8/29/20
to fltkc...@googlegroups.com
Question about the cmake constructed fltk-config(s):

Maybe it's a work in progress, but it seems like after a 'cmake .. && make',
/two/ fltk-config's are constructed:

> "build/fltk-config" (which works)
> "build/bin/fltk-config" (which doesn't)

The one in bin seems as if it's configured for a 'make install', since if I
try to use it, it fails to find libfltk.a because it's looking in /usr/local/lib64,
which would probably be the install directory.

But since I never ran 'make install', the one in bin is a bit confusing.

If we need the one in bin for an eventual 'make install' by the user,
perhaps it can be moved somewhere else with a different name until
it's actually installed, so people don't get confused and use the wrong one.

Greg Ercolano

unread,
Aug 29, 2020, 11:22:14 AM8/29/20
to fltkc...@googlegroups.com
On 2020-08-29 08:15, Greg Ercolano wrote:
> Question about the cmake constructed fltk-config(s):
>
> Maybe it's a work in progress, but it seems like after a 'cmake .. && make',
> /two/ fltk-config's are constructed:
>
> > "build/fltk-config" (which works)
> > "build/bin/fltk-config" (which doesn't)


Thought I should report too, I get a weird error on my Mac 10.10.5 machine when
building a simple c++ file with the fltk-config's:

$ cat > foo.cxx
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
^D

$ bin/fltk-config --compile foo.cxx
/Library/Developer/CommandLineTools/usr/bin/c++ -I/usr/local/include -isysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/lib/libfltk.a -lm -lpthread -framework Cocoa
clang: error: no such file or directory: '/usr/local/lib/libfltk.a' <-- EXPECTED (I GUESS)
clang: warning: no such sysroot directory: '-D_LARGEFILE_SOURCE' <-- NOT EXPECTED
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

$ ./fltk-config --compile foo.cxx
/Library/Developer/CommandLineTools/usr/bin/c++ -I/usr/local/src/fltk-1.4.x-git/build -I/usr/local/src/fltk-1.4.x-git -isysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/src/fltk-1.4.x-git/build/lib/libfltk.a -lm -lpthread -framework Cocoa
clang: warning: no such sysroot directory: '-D_LARGEFILE_SOURCE' <-- NOT EXPECTED
foo.cxx:1:10: fatal error: 'stdio.h' file not found <--
#include <stdio.h> <--
^
1 error generated.


On linux I get:

$ bin/fltk-config --compile foo.cxx
/bin/c++ -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/lib64/libfltk.a -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl
c++: error: /usr/local/lib64/libfltk.a: No such file or directory <-- NO INSTALL

$ ./fltk-config --compile foo.cxx
/bin/c++ -I/usr/local/src/fltk-1.4.x-git/build -I/usr/local/src/fltk-1.4.x-git -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/src/fltk-1.4.x-git/build/lib/libfltk.a -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl
$ <-- WORKED OK


Manolo

unread,
Aug 30, 2020, 1:51:33 PM8/30/20
to fltk.coredev
On Saturday, August 29, 2020 at 5:22:14 PM UTC+2 Greg wrote:

$ ./fltk-config --compile foo.cxx
/Library/Developer/CommandLineTools/usr/bin/c++ -I/usr/local/src/fltk-1.4.x-git/build -I/usr/local/src/fltk-1.4.x-git -isysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/src/fltk-1.4.x-git/build/lib/libfltk.a -lm -lpthread -framework Cocoa
clang: warning: no such sysroot directory: '-D_LARGEFILE_SOURCE' <-- NOT EXPECTED
foo.cxx:1:10: fatal error: 'stdio.h' file not found <--
#include <stdio.h> <--
^
1 error generated.

This error arises because the command line contains option "-isysroot" not followed by a proper SDK path.
That path is normally computed by cmake when it runs in its variable CMAKE_OSX_SYSROOT (see clip below).cmake-clip.png
Greg: don't you see that variable being assigned a value when you run cmake on macOS?

The statement at line #59 of file CMake/options.cmake is
  list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
and this contributes to the value of CXXFLAGS at line #46 of file fltk-config which is expected to contain
"-isysroot" followed by the path to the SDK adequate for the running system.
 

Greg Ercolano

unread,
Aug 30, 2020, 2:19:13 PM8/30/20
to fltkc...@googlegroups.com
On 2020-08-30 10:51, Manolo wrote:
> $ ./fltk-config --compile foo.cxx
> /Library/Developer/CommandLineTools/usr/bin/c++ -I/usr/local/src/fltk-1.4.x-git/build -I/usr/local/src/fltk-1.4.x-git -isysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'foo' 'foo.cxx' /usr/local/src/fltk-1.4.x-git/build/lib/libfltk.a -lm -lpthread -framework Cocoa
> clang: warning: no such sysroot directory: '-D_LARGEFILE_SOURCE' <-- NOT EXPECTED
> foo.cxx:1:10: fatal error: 'stdio.h' file not found <--
> #include <stdio.h> <--
> ^
> 1 error generated.
>
> This error arises because the command line contains option "-isysroot" not followed by a proper SDK path.
> That path is normally computed by cmake when it runs in its variable CMAKE_OSX_SYSROOT (see clip below).cmake-clip.png
> Greg: don't you see that variable being assigned a value when you run cmake on macOS?

Where should I look?

I don't see it in the output of 'cmake ..', and when I grepped the build directory
(post-cmake) for the string, I got this one hit:

$ grep -R CMAKE_OSX_SYSROOT .
./CMakeCache.txt:CMAKE_OSX_SYSROOT:STRING=

..so it seems unset. FLTK built OK though, so not sure what's up.

> The statement at line #59 of file CMake/options.cmake is
>   list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
> and this contributes to the value of CXXFLAGS at line #46 of file fltk-config which is expected to contain
> "-isysroot" followed by the path to the SDK adequate for the running system.

I guess this means CMAKE isn't setting the variable.

I don't have any CMAKE_xxx variables in my environment at build time,
so I assume cmake derives this string by default.

$ printenv | grep CMAKE
<-- no output
$ which cmake
/usr/local/bin/cmake

$ cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Perhaps a bug in my cmake version?

Greg Ercolano

unread,
Aug 30, 2020, 2:27:15 PM8/30/20
to fltkc...@googlegroups.com
On 2020-08-30 11:19, Greg Ercolano wrote:
>> The statement at line #59 of file CMake/options.cmake is
>>   list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
>> and this contributes to the value of CXXFLAGS at line #46 of file fltk-config which is expected to contain
>> "-isysroot" followed by the path to the SDK adequate for the running system.

Since it's adding it to the path FLTK_CFLAGS whether it's set or not,
I tried the seemingly obvious thing of making this change in CMake/options.cmake:

if (APPLE)
option (OPTION_APPLE_X11 "use X11" OFF)
option (OPTION_APPLE_SDL "use SDL" OFF)
- list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
+ if (CMAKE_OSX_SYSROOT)
+ list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
+ endif (CMAKE_OSX_SYSROOT)
endif (APPLE)

..which I think only adds the variable if it's defined, and leaves it out if not.

That seemed to work, as now the constructed fltk-config works.
Not sure if that's the right solution though.

Albrecht Schlosser

unread,
Aug 30, 2020, 8:07:57 PM8/30/20
to fltkc...@googlegroups.com
At least it seems to be better than setting it unconditionally. Manolo
wrote before that some compiler commands don't need the '-isysroot' flag
but we don't know exactly when this is the case and when it's needed. We
should probably "trust" CMake and use it only if it's defined.

Manolo, what do you think?

Albrecht Schlosser

unread,
Aug 30, 2020, 8:11:12 PM8/30/20
to fltkc...@googlegroups.com
Please see also issue #129
https://github.com/fltk/fltk/issues/129

This is WIP.

Albrecht Schlosser

unread,
Aug 30, 2020, 8:16:53 PM8/30/20
to fltkc...@googlegroups.com
On 8/29/20 5:15 PM Greg Ercolano wrote:
> Question about the cmake constructed fltk-config(s):
>
> Maybe it's a work in progress, but it seems like after a 'cmake .. && make',
> /two/ fltk-config's are constructed:
>
> > "build/fltk-config" (which works)
> > "build/bin/fltk-config" (which doesn't)
>
> The one in bin seems as if it's configured for a 'make install', since if I
> try to use it, it fails to find libfltk.a because it's looking in /usr/local/lib64,
> which would probably be the install directory.

Yep, that's what it is intended to be.

> But since I never ran 'make install', the one in bin is a bit confusing.

The one in `bin` is the one that's going to be installed in `bin` in the
installation path. See CMAKE_INSTALL_PREFIX.

> If we need the one in bin for an eventual 'make install' by the user,
> perhaps it can be moved somewhere else with a different name until
> it's actually installed, so people don't get confused and use the wrong one.

Sure, we could move it elsewhere, but that wouldn't help much WRT
confusing people since we'd still have two distinct files.

Manolo

unread,
Aug 31, 2020, 2:32:10 AM8/31/20
to fltk.coredev
I will modify CMake/options.cmake to use the -isysroot option only
when CMAKE_OSX_SYSROOT is defined.

Since cmake defines it in my hands, I would like to try and understand why it doesn't
in Greg's.
Greg, could you, please try these:
1) run cmake -D CMAKE_VERBOSE_MAKEFILE and report whether the -isysroot option is present
in compile commands when make runs after cmake.
2) run cmake through its macOS bundle, and report whether CMAKE_OSX_SYSROOT appears
in the list of cmake variables shown with red background at the end of the configure step.
TIA

I'm using cmake version 3.16.2 today.

Manolo

unread,
Aug 31, 2020, 2:35:03 AM8/31/20
to fltk.coredev

About cmake creating 2 distinct fltk-config files:

Would it be possible to give the copy in BUILD/bin/ a different name until it's installed?

Manolo

unread,
Aug 31, 2020, 8:13:09 AM8/31/20
to fltk.coredev
On Sunday, August 30, 2020 at 8:27:15 PM UTC+2 Greg wrote:

if (APPLE)
option (OPTION_APPLE_X11 "use X11" OFF)
option (OPTION_APPLE_SDL "use SDL" OFF)
- list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
+ if (CMAKE_OSX_SYSROOT)
+ list (APPEND FLTK_CFLAGS "-isysroot ${CMAKE_OSX_SYSROOT}")
+ endif (CMAKE_OSX_SYSROOT)
endif (APPLE)

That change to CMake/options.cmake is now committed in the git repository.

Albrecht Schlosser

unread,
Aug 31, 2020, 2:16:39 PM8/31/20
to fltkc...@googlegroups.com
Short answer: yes.

Long answer follows (no need to read unless you're really interested):

Either that (another name) or even another directory as suggested by
Greg. One problem I'm still working on is the multi-config build feature
of IDE's like Xcode, Visual Studio, and maybe others.

Since we have two or more different build types (Debug, Release, ...) we
can't create `fltk-config` statically at configure time as it is done
now. We must either postpone creating it at build time or even later at
installation time. I don't know what the final solution will be, but
I'll try to take care of the concerns regarding multiple instances of
fltk-config.

Some preliminary thoughts:

(1) the fltk-config file to be used in the build tree may need to be
created in the specific build directory, i.e. for instance in Xcode builds:

- BUILD/bin/Debug/fltk-config
- BUILD/bin/Release/fltk-config
- etc. for more build types

For single config builds (Makefiles, Ninja, ...) this would collapse to

- BUILD/bin/fltk-config

Note that this is different from now where the file to be used with the
build tree is:

- BUILD/fltk-config

This seems to be wrong from my POV of today.

This fltk-config file would most likely have to be created during the
build process (`make` ...) rather than at configure time (same as the
macOS wrapper scripts).

(2) the fltk-config file to be installed can be created elsewhere or
maybe only at `install` time. We have other files in the folder `etc`
(CMake config files to be installed). This is a possible place but maybe
not optimal.


I still need to find out how this can all be done to be able to support
both single- and multi-config builds and to avoid confusion.
Reply all
Reply to author
Forward
0 new messages