FLTK installation process on Windows is absolutely broken

[Felix Schütt]

Hi. I am trying to follow the installation instructions for installing FLTK on Windows 10: http://www.fltk.org/articles.php?L598+I100+T+P1+Q

I have done the following:

• I installed MSYS2 64 bit
  
• Via the MSYS terminal, I installed the mingw-w64-x86_64-toolchain: 
• $ pacman -S mingw-w64-x86_64-toolchain
  
  
• I downloaded fltk 1.3.3 from the website
• I unpacked it (the installation instructions have by the way not been updated, as fltk is not bzip2 compressed anymore, but gzip compressed)
• tar -xf fltk-1.3.3-source.tar.gz
  cd fltk-1.3.3/
  

  ./configure --enable-threads --enable-localjpeg --enable-localzlib --enable-localpng
• Failed with:
• checking build system type... ./config.guess: unable to guess system type

  
  

  This script, last modified 2013-06-10, has failed to recognize

  the operating system you are using. It is advised that you

  download the most up to date version of the config scripts from

  
  

    http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

  and

    http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

  
  

  If the version you run (./config.guess) is already up to date, please

  send the following data and any information you think might be

  pertinent to <config-...@gnu.org> in order to provide the needed

  information to handle your system.

  
  

  config.guess timestamp = 2013-06-10

  
  

  uname -m = x86_64

  uname -r = 2.4.1(0.294/5/3)

  uname -s = MSYS_NT-10.0

  uname -v = 2016-02-03 10:57

  
  

  /usr/bin/uname -p = unknown

  /bin/uname -X     =

  
  

  hostinfo               =

  /bin/universe          =

  /usr/bin/arch -k       =

  /bin/arch              = x86_64

  /usr/bin/oslevel       =

  /usr/convex/getsysinfo =

  
  

  UNAME_MACHINE = x86_64

  UNAME_RELEASE = 2.4.1(0.294/5/3)

  UNAME_SYSTEM  = MSYS_NT-10.0

  UNAME_VERSION = 2016-02-03 10:57

  configure: error: cannot guess build type; you must specify one
  
  
• ... because the config.guess and config.sub file in FLTK is outdated by three years, it does not recognize Windows 10 as a valid build system
• I replaced the config.guess and config.sub in the fltk folder with the newer ones, ran again

$  ./configure --enable-threads --enable-localjpeg --enable-localzlib --enable-localpng

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking for gcc... gcc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.exe

checking for suffix of executables... .exe

checking whether we are cross compiling... no

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ISO C89... none needed

checking for g++... g++

checking whether we are using the GNU C++ compiler... yes

checking whether g++ accepts -g... yes

checking for a BSD-compatible install... /usr/bin/install -c

checking for nroff... no

checking for doxygen... no

checking for ranlib... ranlib

checking for ar... /mingw64/bin/ar

checking for windres... /mingw64/bin/windres

checking how to run the C preprocessor... gcc -E

checking for grep that handles long lines and -e... /usr/bin/grep

checking for egrep... /usr/bin/grep -E

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking size of short... 2

checking size of int... 4

checking size of long... 4

checking whether byte ordering is bigendian... no

checking whether the compiler recognizes bool as a built-in type... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/stdtypes.h usability... no

checking sys/stdtypes.h presence... no

checking for sys/stdtypes.h... no

checking whether we have the POSIX compatible scandir() prototype... no

checking for scandir... no

checking for vsnprintf... yes

checking for snprintf... yes

checking for strings.h... (cached) yes

checking for strcasecmp... yes

checking for strlcat... no

checking for strlcpy... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking for localeconv... yes

checking for library containing pow... none required

checking for special C compiler options needed for large files... no

checking for _FILE_OFFSET_BITS value needed for large files... 64

checking for long long int... yes

checking for library containing dlsym... no

checking dlfcn.h usability... no

checking dlfcn.h presence... no

checking for dlfcn.h... no

checking alsa/asoundlib.h usability... no

checking alsa/asoundlib.h presence... no

checking for alsa/asoundlib.h... no

checking pthread.h usability... yes

checking pthread.h presence... yes

checking for pthread.h... yes

checking for pthread_create using -lpthreads... no

checking for pthread_create using -lpthread... yes

checking for X... no

./configure: line 410: test: aborting.: integer expression expected

configure: error: Configure could not find required X11 libraries

./configure: line 299: return: aborting.: numeric argument required

./configure: line 309: exit: aborting.: numeric argument required

I do not know what to do. I've tried installing X11 via pacman, however "pacman -S xorg" or any variant doesn't work and I can't find any information online on how to install it.

The only way I got something to work was by doing the same steps in cygwin instead of MSYS2 (which isn't documented anywhere, but I wanted to try:

• Started the Cygwin Terminal
• Unzipped the original tar.gz with the 2013 config.guess and config.sub, same command as above
• Result:

$ ./configure --enable-threads --enable-localjpeg --enable-localzlib --enable-localpng

checking build system type... x86_64-unknown-cygwin

checking host system type... x86_64-unknown-cygwin

checking for gcc... gcc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.exe

checking for suffix of executables... .exe

checking whether we are cross compiling... no

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ISO C89... none needed

checking for g++... g++

checking whether we are using the GNU C++ compiler... yes

checking whether g++ accepts -g... yes

checking for a BSD-compatible install... /usr/bin/install -c

checking for nroff... /usr/bin/nroff

checking for doxygen... no

checking for ranlib... ranlib

checking for ar... /cygdrive/c/msys64/mingw64/bin/ar

checking for windres... /cygdrive/c/msys64/mingw64/bin/windres

checking how to run the C preprocessor... gcc -E

checking for grep that handles long lines and -e... /usr/bin/grep

checking for egrep... /usr/bin/grep -E

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking size of short... 2

checking size of int... 4

checking size of long... 4

checking whether byte ordering is bigendian... no

checking whether the compiler recognizes bool as a built-in type... yes

checking for dirent.h that defines DIR... yes

checking for library containing opendir... none required

checking sys/select.h usability... no

checking sys/select.h presence... no

checking for sys/select.h... no

checking sys/stdtypes.h usability... no

checking sys/stdtypes.h presence... no

checking for sys/stdtypes.h... no

checking whether we have the POSIX compatible scandir() prototype... no

checking for scandir... no

checking for vsnprintf... yes

checking for snprintf... yes

checking for strings.h... (cached) yes

checking for strcasecmp... yes

checking for strlcat... no

checking for strlcpy... no

checking locale.h usability... yes

checking locale.h presence... yes

checking for locale.h... yes

checking for localeconv... yes

checking for library containing pow... none required

checking for special C compiler options needed for large files... no

checking for _FILE_OFFSET_BITS value needed for large files... 64

checking for long long int... yes

checking for library containing dlsym... no

checking dlfcn.h usability... no

checking dlfcn.h presence... no

checking for dlfcn.h... no

checking GL/gl.h usability... yes

checking GL/gl.h presence... yes

checking for GL/gl.h... yes

checking GL/glu.h usability... yes

checking GL/glu.h presence... yes

checking for GL/glu.h... yes

checking if GCC supports -fno-exceptions... yes

checking if GCC supports -fno-strict-aliasing... yes

checking if ld supports -Bsymbolic-functions... yes

checking if toolchain supports sections... yes

Configuration Summary

-------------------------------------------------------------------------

    Directories: prefix=/usr/local

                 bindir=${exec_prefix}/bin

                 datadir=${datarootdir}

                 datarootdir=${prefix}/share

                 exec_prefix=${prefix}

                 includedir=${prefix}/include

                 libdir=${exec_prefix}/lib

                 mandir=${datarootdir}/man

       Graphics: GDI

Image Libraries: JPEG=Builtin

                 PNG=Builtin

                 ZLIB=Builtin

    Large Files: YES

         OpenGL: YES

        Threads: YES

configure: creating ./config.status

config.status: creating makeinclude

config.status: creating fltk.list

config.status: creating fltk-config

config.status: creating fltk.spec

config.status: creating FL/Makefile

config.status: creating config.h

Then I tried make in cygwin (not installed in cygwin by default, you have to download the package manager apt-cyg, unzip, put the file in "C:\cygwin64\usr\local\bin" and run "apt-cyg install make"), which failed with:

make[1]: /cygdrive/c/msys64/mingw64/bin/ar: Command not found

Well, of course: ar.exe is located in "C:\msys64\mingw64\bin", for some reason cygwin puts a "cygdrive" before it, of course make can't find the folder. Generating the make files in cygwin, then running make in msys will result in the same error.

Then I tried using cmake-gui as a build system, because I saw a "CMakeLists.txt". Result:

The C compiler identification is GNU 5.3.0

The CXX compiler identification is GNU 5.3.0

Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe

Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe -- works

Detecting C compiler ABI info

Detecting C compiler ABI info - done

Detecting C compile features

Detecting C compile features - done

Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe

Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe -- works

Detecting CXX compiler ABI info

Detecting CXX compiler ABI info - done

Detecting CXX compile features

Detecting CXX compile features - done

Check if the system is big endian

Searching 16 bit integer

Looking for sys/types.h

Looking for sys/types.h - found

Looking for stdint.h

Looking for stdint.h - found

Looking for stddef.h

Looking for stddef.h - found

Check size of unsigned short

Check size of unsigned short - done

Using unsigned short

Check if the system is big endian - little endian

Check size of short

Check size of short - done

Check size of int

Check size of int - done

Check size of long

Check size of long - done

Check size of long long

Check size of long long - done

Looking for dlsym

Looking for dlsym - not found

Looking for localeconv

Looking for localeconv - found

Looking for png_get_valid

Looking for png_get_valid - not found

Looking for png_set_tRNS_to_alpha

Looking for png_set_tRNS_to_alpha - not found

Looking for scandir

Looking for scandir - not found

Looking for snprintf

Looking for snprintf - found

Looking for strcasecmp

Looking for strcasecmp - found

Looking for strlcat

Looking for strlcat - not found

Looking for strlcpy

Looking for strlcpy - not found

Looking for vsnprintf

Looking for vsnprintf - found

Found PkgConfig: C:/msys64/mingw64/bin/pkg-config.exe (found version "0.29")

Found OpenGL: opengl32

Looking for glXGetProcAddressARB

Looking for glXGetProcAddressARB - not found

Looking for pthread.h

Looking for pthread.h - found

Looking for pthread_create

Looking for pthread_create - not found

Looking for pthread_create in pthreads

Looking for pthread_create in pthreads - not found

Looking for pthread_create in pthread

Looking for pthread_create in pthread - not found

Check if compiler accepts -pthread

Check if compiler accepts -pthread - yes

Found Threads: TRUE

Found ZLIB: C:/msys64/mingw64/lib/libz.dll.a (found version "1.2.8")

cannot find system jpeg library - using built-in

cannot find system png library - using built-in

CMake Warning (dev) at CMake/export.cmake:48 (set):
Policy CMP0053 is not set: Simplify variable reference and escape sequence
evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

For input:

'@FLTK_INCLUDE_DIRS@'

the old evaluation rules produce:

'D:/fltk/build-1.3.3;D:/fltk/fltk-1.3.3'

but the new evaluation rules produce:

'@FLTK_INCLUDE_DIRS@'

Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
CMakeLists.txt:50 (include)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at CMake/export.cmake:49 (set):
Policy CMP0053 is not set: Simplify variable reference and escape sequence
evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

For input:

'@FLTK_BINARY_DIR@'

the old evaluation rules produce:

'D:/fltk/build-1.3.3'

but the new evaluation rules produce:

'@FLTK_BINARY_DIR@'

Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
CMakeLists.txt:50 (include)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at CMake/install.cmake:46 (set):
Policy CMP0053 is not set: Simplify variable reference and escape sequence
evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

For input:

'${CMAKE_INSTALL_PREFIX}/@FLTK_CONFIG_PATH@'

the old evaluation rules produce:

'C:/Program Files (x86)/FLTK/CMake'

but the new evaluation rules produce:

'C:/Program Files (x86)/FLTK/@FLTK_CONFIG_PATH@'

Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
CMakeLists.txt:62 (include)
This warning is for project developers. Use -Wno-dev to suppress it.

Configuring done

Then I tried using svn to checkout fltk into another directory because I saw it here: http://stackoverflow.com/questions/9779901/setting-up-fltk-on-windows-with-cmake

svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3

However it seems that the website is down (why?). So I tried cmake on the sources I had:

$ cmake CMakeLists.txt -DOPTION_BUILD_EXAMPLES=NO -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=D:\fltk\fltk-1.3.3

-- Building for: Visual Studio 14 2015      //<---- why!!! my compiler is GCC, goddammit

[...]

CMake Warning (dev) at CMake/export.cmake:48 (set):

  Policy CMP0053 is not set: Simplify variable reference and escape sequence

  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the

  cmake_policy command to set the policy and suppress this warning.

  For input:

    '@FLTK_INCLUDE_DIRS@'

  the old evaluation rules produce:

    'D:/fltk/fltk-1.3.3;D:/fltk/fltk-1.3.3'

  but the new evaluation rules produce:

    '@FLTK_INCLUDE_DIRS@'

  Using the old result for compatibility since the policy is not set.

Call Stack (most recent call first):

  CMakeLists.txt:50 (include)

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMake/export.cmake:49 (set):

  Policy CMP0053 is not set: Simplify variable reference and escape sequence

  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the

  cmake_policy command to set the policy and suppress this warning.

  For input:

    '@FLTK_BINARY_DIR@'

  the old evaluation rules produce:

    'D:/fltk/fltk-1.3.3'

  but the new evaluation rules produce:

    '@FLTK_BINARY_DIR@'

  Using the old result for compatibility since the policy is not set.

Call Stack (most recent call first):

  CMakeLists.txt:50 (include)

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMake/install.cmake:46 (set):

  Policy CMP0053 is not set: Simplify variable reference and escape sequence

  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the

  cmake_policy command to set the policy and suppress this warning.

  For input:

    '${CMAKE_INSTALL_PREFIX}/@FLTK_CONFIG_PATH@'

  the old evaluation rules produce:

    'D:fltkfltk-1.3.3/CMake'

  but the new evaluation rules produce:

    'D:fltkfltk-1.3.3/@FLTK_CONFIG_PATH@'

  Using the old result for compatibility since the policy is not set.

Call Stack (most recent call first):

  CMakeLists.txt:62 (include)

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done

-- Generating done

CMake Warning:

  Manually-specified variables were not used by the project:

    CMAKE_BUILD_TYPE

-- Build files have been written to: D:/fltk/fltk-1.3.3

Then I tried "make" in MSYS on that result:

$ make

=== making jpeg ===

Archiving ../lib/libfltk_jpeg.a...

make[1]: /cygdrive/c/msys64/mingw64/bin/ar: Command not found

Makefile:129: Rule for target „../lib/libfltk_jpeg.a“ scheiterte  //???????????? What is "target ../lib/..."??????????

make[1]: *** [../lib/libfltk_jpeg.a] Error 127

Makefile:24: Rule for target „all“ failed

make: *** [all] Error 1

Since that didn't work, I tried Cygwins make, which gave me a load of warnings, but at least it built something. If somebody is interested in the warnings given, they are available here: https://gist.github.com/sharazam/8325be7097feb785511eca2a80a760c6

Then I tried "make install" (in MSYS, because all the files were generated using the MSYS MinGW toolchain, so all files are somewhere in C:\msys64\):

$ make install

=== installing FL ===

Installing include files in /usr/local/include...

=== installing jpeg ===

Installing ../lib/libfltk_jpeg.a in /usr/local/lib...

Installing jpeg headers in /usr/local/include/FL/images...

=== installing zlib ===

Installing libfltk_z.a in /usr/local/lib...

Installing zlib headers in /usr/local/include/FL/images...

=== installing png ===

Installing libfltk_png.a in /usr/local/lib...

Installing png headers in /usr/local/include/FL/images...

=== installing src ===

Installing libraries in /usr/local/lib...

=== installing fluid ===

Installing FLUID in /usr/local/bin...

=== installing test ===

Installing example programs to /usr/local/share/doc/fltk/examples...

=== installing documentation ===

Installing documentation files in /usr/local/share/doc/fltk ...

Installing man pages in /usr/local/share/man ...

Then I could finally get to my libraries and headers.

To sum my problems up:

• The information given on http://www.fltk.org/articles.php?L598+I100+T+P1+Q misses that fltk switched from bzip2 to gzip
• The information given on http://www.fltk.org/articles.php?L598+I100+T+P1+Q is pretty much entirely wrong, at least for Windows 10
• CMake assumes MSVC compiler, why? Not everyone on Windows wants to use Visual Studio.
• Why does FLTK need X11?
• Why is the SVN server down and where is the new adress?
• The article states to use MSYS, however some things simply don't work in MSYS and I have to jump between build systems all the time. None of this is documented.
  
• The 2013 configure script does not work on Windows 10, the 2016 configure file is missing X11 and X11 can't be installed through pacman in MSYS. 
• While compiling, there are a load of warnings (mostly warning: cast to pointer from integer of different size). I do not know if this is important, but just wanted to say it.

TODO: I wrote this in the mindset that FLTK is impossible to build on Windows. I am posting it here so others in the future can find it and learn. I did not expect to finally succeed when I began this post, however, since it worked after about 20 trials I am leaving it as a documentation on how to actually build FLTK. It is sad that none of this is documented and I do not know whom to write to (maybe er...@seriss.com the site maintainer, however I do not even know how outdated the information is or if the company is still alive).

Thank you for reading,

Felix Schütt

[Albrecht Schlosser]

On 26.07.2016 23:31 Felix Schütt wrote:
> Hi. I am trying to follow the installation instructions for installing
> FLTK on Windows 10: http://www.fltk.org/articles.php?L598+I100+T+P1+Q

Hi Felix, welcome to the FLTK community. I'm sorry that you had so much
trouble, but there are certainly ways to install FLTK on Windows 10.
Unfortunately I don't have a Windows 10 system at hand right now, but I
/believe/ that it /should/ work.

I'll comment on some of your steps to help you get it going, but I also
appreciate your comments that show outdated documentation.

> I have done the following:
>

> * I installed MSYS2 64 bit

MSYS2 is not MinGW and not MSYS, it's a different toolset. The
installation instructions you mentioned above advise to use "the latest
mingw toolchain from http://www.mingw.org". I know that several FLTK
devs are using this toolchain successfully, and I'm sure it works on
Windows 8.1, but I'm not yet sure about Windows 10.

MSYS2 is a different toolchain, and I believe that none of the FLTK devs
actively uses it, so FLTK may indeed have issues with MSYS2.

> * I downloaded fltk 1.3.3 from the website
> * I unpacked it (the installation instructions have by the way not

> been updated, as fltk is not bzip2 compressed anymore, but gzip
> compressed)

Thanks for the heads-up.

> *

> |
> tar -xf fltk-1.3.3-source.tar.gz
> cd fltk-1.3.3/
> ./configure --enable-threads --enable-localjpeg --enable-localzlib
> --enable-localpng
> |

> *
> Failed with:
> *

> |
> checking build system type... ./config.guess: unable to guess system
> type
>
> This script, last modified 2013-06-10, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from

...

Hmm, well... yes, this script may be outdated, but FLTK 1.3.3 was
released in Nov 2014, which is also pretty old. Unfortunately there is
no later release yet, but FLTK 1.3.4 is to be released soon. You can
always download a weekly snapshot or current svn (see download page).
http://www.fltk.org/software.php

> ... because the config.guess and config.sub file in FLTK is outdated
> by three years, it does not recognize Windows 10 as a valid build system

Thanks for the hint. We'll update the scripts in FLTK 1.3.4.

> * I replaced the config.guess and config.sub in the fltk folder with

> the newer ones, ran again
>
> |
> $ ./configure --enable-threads --enable-localjpeg --enable-localzlib
> --enable-localpng
> checking build system type... x86_64-pc-msys
> checking host system type... x86_64-pc-msys

...

> checking for pthread_create using -lpthreads... no
> checking for pthread_create using -lpthread... yes
> checking for X... no
> ./configure: line 410: test: aborting.: integer expression expected
> configure: error: Configure could not find required X11 libraries
> ./configure: line 299: return: aborting.: numeric argument required
> ./configure: line 309: exit: aborting.: numeric argument required

X11 is not required for MinGW/MSYS builds, so this is strange. All these
"integer expression expected" messages look like a problem with line
endings of configure scripts we had a long time ago. Some scripts must
have Unix line endings (LF) and don't work with DOS line endings
(CR/LF), but I can't tell what the reason is w/o my own tests.

> I do not know what to do. I've tried installing X11 via pacman, however
> "pacman -S xorg" or any variant doesn't work and I can't find any
> information online on how to install it.

Please try to install MinGW as advised in the mentioned article. Note
that current MinGW does no longer have the "developers toolkit
(Msys-DTK)" IIRC, but the installer GUI offers a similar package, maybe
"developer tools". Sorry, I can't be more precise right now. Please make
sure to install g++ and gcc as well.

If you have MinGW, gcc, g++, and the developer tools installed, then you
can just run 'make' after unpacking the FLTK tarball. This will run
automake (which should be available) to generate current config.guess
and config.sub files. make should run in its default configuration.

> The only way I got something to work was by doing the same steps in
> cygwin instead of MSYS2 (which isn't documented anywhere, but I wanted
> to try:

Cygwin is much more difficult to get working than MinGW. We really
recommend MinGW.

> * Started the Cygwin Terminal
> * Unzipped the original tar.gz with the 2013 config.guess and

> config.sub, same command as above

> * Result:

>
> |
> $ ./configure --enable-threads --enable-localjpeg --enable-localzlib
> --enable-localpng
> checking build system type... x86_64-unknown-cygwin
> checking host system type... x86_64-unknown-cygwin

...

> <https://github.com/transcode-open/apt-cyg>, unzip, put the file in

> "C:\cygwin64\usr\local\bin" and run "apt-cyg install make"), which
> failed with:
> |
> make[1]: /cygdrive/c/msys64/mingw64/bin/ar: Command not found
> |

The latest cygwin installation I have uses its own "setup.exe" tool to
install packages. I don't think that apt-cyg is supported by Cygwin, so
you're probably on your own if you use it.

> Then I tried using cmake-gui as a build system, because I saw a
> "CMakeLists.txt". Result:

Which cmake-gui, and how did you start it? Was this the Cygwin one (if
this exists), or a Windows CMake download?

Note that CMake is not yet officially supported in FLTK 1.3.x, and the
FLTK 1.3.3 CMake files are in alpha state (really not recommended).

> The C compiler identification is GNU 5.3.0
>
> The CXX compiler identification is GNU 5.3.0
>
> Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe
>
> Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe -- works

Okay, this looks like CMake found your MSYS2 compilers.

...

Following messages look mostly okay.

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

These informational messages are normal.

> CMake Warning (dev) at CMake/export.cmake:48 (set):
> Policy CMP0053 is not set: Simplify variable reference and escape sequence
> evaluation. Run "cmake --help-policy CMP0053" for policy details. Use the
> cmake_policy command to set the policy and suppress this warning.
>
> For input:
>
> '@FLTK_INCLUDE_DIRS@'
>
> the old evaluation rules produce:
>
> 'D:/fltk/build-1.3.3;D:/fltk/fltk-1.3.3'

These are only warnings. I believe that these are fixed in FLTK 1.3.4
(current svn), but it should work anyway. But please try the current svn
version or a snapshot.

> Using the old result for compatibility since the policy is not set.
> Call Stack (most recent call first):
> CMakeLists.txt:62 (include)
> This warning is for project developers. Use -Wno-dev to suppress it.
>
> Configuring done

This means that configuring the build system succeeded. Why did you not
try to run 'make' after this ?

> Then I tried using svn to checkout fltk into another directory because I
> saw it
> here: http://stackoverflow.com/questions/9779901/setting-up-fltk-on-windows-with-cmake
> |
>
> |svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3|
>
> |
>
> However it seems that the website is down (why?).

These instructions are more than four years old (and from an external
source), and the link in these old instructions is outdated. Please take
a look at the official FLTK download page and you'll see the current
link and download instructions.

http://www.fltk.org/software.php
http://www.fltk.org/software.php#SVN

shows:

svn co http://seriss.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3

Besides that you can find our weekly snapshots at the same page,
currently 1.3.x-r11842 (changes every Friday).

> So I tried cmake on
> the sources I had:
> |
> $ cmake CMakeLists.txt -DOPTION_BUILD_EXAMPLES=NO
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=D:\fltk\fltk-1.3.3
> -- Building for: Visual Studio 14 2015 //<---- why!!! my compiler
> is GCC, goddammit

Sorry, this is not FLTK's fault. CMake tries to find the compiler(s) on
your system, but you can use another one if you give the correct command
line option (-G). In this case you may want

cmake -G"Unix Makefiles" ..

And please don't use CMake directly in the source tree. Create another
build directory and run CMake after changing to that directory, e.g.

cd /path/to/fltk-1.3
mkdir build
cd build
cmake -G"Unix Makefiles" ..

Note: '..' is part of the command line (the source directory).

> Then I tried "make" in MSYS on that result:
> |
> $ make
> === making jpeg ===
> Archiving ../lib/libfltk_jpeg.a...
> make[1]: /cygdrive/c/msys64/mingw64/bin/ar: Command not found
> Makefile:129: Rule for target „../lib/libfltk_jpeg.a“ scheiterte
> //???????????? What is "target ../lib/..."??????????
> make[1]: *** [../lib/libfltk_jpeg.a] Error 127
> Makefile:24: Rule for target „all“ failed
> make: *** [all] Error 1

Again, this is MSYS2, and I can't tell if this works. I'll try to
install it (likely in a few days, but please don't hold your breath),
and I'll try to get FLTK working with MSYS2. If this works I'll post the
results.

> Since that didn't work, I tried Cygwins make, which gave me a load of
> warnings, but at least it built something. If somebody is interested in
> the warnings given, they are available
> here: https://gist.github.com/sharazam/8325be7097feb785511eca2a80a760c6

Thanks, I'll check that, but please try current svn or a snapshot.

> Then I tried "make install" (in MSYS, because all the files were
> generated using the MSYS MinGW toolchain, so all files are somewhere in
> C:\msys64\):
> |
> $ make install

Okay, however we don't recommend to "install" FLTK, at least for tests.
You can use the libs directly from the build directory.

> Then I could finally get to my libraries and headers.
>
> To sum my problems up:
>

> * The information given

> on http://www.fltk.org/articles.php?L598+I100+T+P1+Q misses that
> fltk switched from bzip2 to gzip

Thanks, we'll check and fix this.

> * The information given

> on http://www.fltk.org/articles.php?L598+I100+T+P1+Q is pretty much
> entirely wrong, at least for Windows 10

Thanks, we'll check and fix this. But note that you used MSYS2 which is
not covered by these instructions.

> * CMake assumes MSVC compiler, why? Not everyone on Windows wants to
> use Visual Studio.

Pleasw use the correct commandline as noted above. This is CMake-specific.

> * Why does FLTK need X11?

It doesn't (under Windows).

> * Why is the SVN server down and where is the new adress?

http://www.fltk.org/software.php#SVN
(please see above).

> * The article states to use MSYS, however some things simply don't

> work in MSYS and I have to jump between build systems all the time.
> None of this is documented.

You didn't use MSYS (but MSYS2). The instructions were for using MinGW
and MSYS (from the MinGW site) which is another toolkit.

> * The 2013 configure script does not work on Windows 10, the 2016

> configure file is missing X11 and X11 can't be installed through
> pacman in MSYS.

Please use current svn and just run 'make'. This ought to work. The
instructions in Article #598 lack this important information.

> * While compiling, there are a load of warnings (mostly warning: cast

> to pointer from integer of different size). I do not know if this is
> important, but just wanted to say it.

It's generally not important, but annoying. We certainly have fixed some
of these warnings in current svn (FLRK 1.3.4) and even more of these
warnings will be removed in FLTK 1.4.0 which will be the next release
after 1.3.4.

> TODO: I wrote this in the mindset that FLTK is impossible to build on
> Windows.

You can be sure that this is not true. I'll have to try Windows 10
though to see if there are any issues.

> I am posting it here so others in the future can find it and
> learn. I did not expect to finally succeed when I began this post,
> however, since it worked after about 20 trials I am leaving it as a
> documentation on how to actually build FLTK.

I'm sorry that you had so much trouble, but I hope you'll have more
success when using my advice (comments) above.

> It is sad that none of this
> is documented and I do not know whom to write to (maybe er...@seriss.com

> <mailto:er...@seriss.com> the site maintainer, however I do not even know

> how outdated the information is or if the company is still alive).

This (fltkgeneral) is the correct place to report this. Thanks for doing
this, we'll try to improve the documentation.

> Thank you for reading,

You're welcome.

> Felix Schütt

Albrecht Schloßer

[Greg Ercolano]

See Albrecht's comments.

Wanted to address these:

On 07/26/16 14:31, Felix Schütt wrote:
> Then I tried using svn to checkout fltk into another directory because I saw it here: http://stackoverflow.com/questions/9779901/setting-up-fltk-on-windows-with-cmake
> svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3
> However it seems that the website is down (why?).

The world has changed since then; the old server "easysw.com"
no longer exists as of 2013.

For up to date download for FLTK source code, please refer to http://fltk.org/
Just click on the "Download" link.

There you will find up to date source code downloads for tar files and
SVN access info.

I've updated the stackoverflow article to indicate this,
but understand it's fairly impossible to update all stale refs on the net.
Always seek the official project server for up to date info.

[Felix Schütt]

Thanks for answering my questions.

There are a few things I wanted to correct:

- That the ./configure script fails on Windows 10 because the OS is not recognized is just my assumption. The strange thing is that the same script worked with Cygwin flawlessly (well, almost).

- I used MSYS2 because I needed the 64-bit library. I wanted to stay away from anything Visual Studio related, simply because I needed a reproducable workflow on Windows, Linux and Mac and automake + gcc seemed the way to go. I could use nmake + the VS compiler, but I am not sure about the license:

INSTALLATION AND USE RIGHTS.

1. Individual license. If you are an individual working on your own applications to sell or for any other purpose, you may use the software to develop and test those applications.
2. Organization licenses. If you are an organization, your users may use the software as follows:
   • Any number of your users may use the software to develop and test your applications released under Open Source Initiative (OSI)-approved open source software licenses.
   • Any number of your users may use the software to develop and test your applications as part of online or in person classroom training and education, or for performing academic research.
   • If none of the above apply, and you are also not an enterprise (defined below), then up to 5 of your individual users can use the software concurrently to develop and test your applications.
   • If you are an enterprise, your employees and contractors may not use the software to develop or test your applications, except for open source and education purposes as permitted above. An “enterprise” is any organization and its affiliates who collectively have either (a) more than 250 PCs or users or (b) more than one million US dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization.
3. Demo use. The uses permitted above include use of the software in demonstrating your applications.
4. Backup copy. You may make one backup copy of the software, for reinstalling the software.

I do not know if I as a individual developer fall under "individual" or "organization" or how Microsoft defines what an "organization" is. Plus, I am trying to establish a workflow that will work under Windows, Linux and Mac. 64 bit is preferred, because the application is likely to consume a lot of RAM. But MinGW is only available in 32 Bit as far as I know (or I can't find the download link for 64-bit).

- If I understand this correctly, in order to build I need to download MinGW (which comes with gcc and g++), and run "make" inside the directory. Don't I need to run "./configure" first?

- I used apt-cyg because I didn't get the setup-x86_64 thing to work, I didn't know where it was located, and apt-cyg did its job apparently, so it's more of a personal preference.

- I used the cmake-gui from the CMake download site (https://cmake.org/runningcmake/), I didn't use Cygwin one.

- If you could get FLTK to work with MSYS2, this would be great because as far as I know, MSYS2 is the only way to get mingw_w64 to work on windows, the normal MSYS is just 32-bit. For now, it worked and I seem to have built the 64-bit libraries, but using two seperate build systems so that one can make up for the failures of the other is really not what I intended. Or I could use the 32-bit compiler (which is installed with the standard MinGW installer). The problem is that I do not know which version of MinGW is intended for 64-bit and the only MinGW installer is 32-bit. The only way I could get a 64-bit gcc-compiler was by using MSYS2.

- I'm fine for now, but I'll try again with MSYS 32-bit, and another one on Windows 7. I'll also try using CMake or nmake. I'll try again using the current svn.

- I didn't know where exactly the make process installed the libraries. With "make install" I could at least get them into one directory.

I'm sorry for my tone yesterday, I was a bit tired.

 

Please use current svn and just run 'make'. This ought to work. The
instructions in Article #598 lack this important information.

Please add them (or delegate this to somebody who can). I'll try and see if it works

Thanks,

Felix Schütt

[bat]

Hello, 

I had a similar problem last year on 64 bit Windows which was solved entirely by using MSYS instead of MSYS2. 

https://groups.google.com/d/msg/fltkgeneral/oeQd6IYp1e4/Bq5Tm3R2AQAJ

It worked exactly as described in the documentation if you use the right MSYS. Basically, the answer is forget MSYS2.

[Ian MacArthur]

On Wed Jul 27 2016 21:56:25, Felix Schütt wrote:
> Thanks for answering my questions.
>
> There are a few things I wanted to correct:
>
> - That the ./configure script fails on Windows 10 because the OS is not recognized is just my assumption. The strange thing is that the same script worked with Cygwin flawlessly (well, almost).
> - I used MSYS2 because I needed the 64-bit library.

Be careful here, and recall that which compiler toolchain you use is pretty much orthogonal to what shell you choose.

In particular my experiences with MSYS2 have not been good, but running the mingw64 tools from within my existing Msys/mingw setup has worked out pretty well, though to do that I had to be explicit in setting the paths for the compiler I wanted to use in any given build, and lib paths and etc. : since I had both mingw32 and mingw64 compiler toolchains available, I had to do a lot of setting “CXX = /path/to/compiler/gcc-ming64” and so forth before calling configure, or it all went a bit awry.

Indeed, you can invoke almost any compiler toolchain from Msys; as recently as last Wednesday I was using the MS cl compiler from a gnu Makefile in an Msys shell, with quite happy results.

> I wanted to stay away from anything Visual Studio related, simply because I needed a reproducable workflow on Windows, Linux and Mac and automake + gcc seemed the way to go. I could use nmake + the VS compiler, but I am not sure about the license:

The MS cl compiler works in an Msys shell, and with gnu make, in my experience.

The licensing is more of an issue: I can’t ship product built with the free MS tools, but I’m only using them as a “second opinion” when cleaning my code so I think that’s probably OK! YMMV of course.


My main issue with cl as a compiler is actually that it’s dependency generation scheme is incompatible with what gcc, icc and clang do, so I had to write a little wrapper around cl that fakes it up so that dependency generation in my Makefile works as expected.

With that in place, the same Makefile now works on WinXX, Linux and OSX pretty well, and on WinXX if I set USE_CC=cl when invoking make, it will use cl rather than gcc to execute the build.

>
>
> - If I understand this correctly, in order to build I need to download MinGW (which comes with gcc and g++), and run "make" inside the directory. Don't I need to run "./configure" first?

Our Makefile will run configure if it needs to. Or you can run it yourself, of course. If you want to change the defaults (probably on Windows you do not) then you’d want to run configure yourself.
What I usually do (on any platform) is run configure once with the default settings, see what happens, then re-run configure again with the settings that I think I want...

>
> - I used apt-cyg because I didn't get the setup-x86_64 thing to work, I didn't know where it was located, and apt-cyg did its job apparently, so it's more of a personal preference.

Don’t know apt-cyg. From the name I assume it is cygwin related? I abandoned cygwin some years ago after getting burnt one time too many and have not used it since. Maybe it got better... I am not an advocate for cygwin, shall we say...

>
> - I used the cmake-gui from the CMake download site (https://cmake.org/runningcmake/), I didn't use Cygwin one.
>
> - If you could get FLTK to work with MSYS2, this would be great because as far as I know, MSYS2 is the only way to get mingw_w64 to work on windows,

Not so; I have run it from a stock Msys shell, and I think from a plain old DOS box, IIRC.

What makes you think you need to use MSYS2 for this?

> the normal MSYS is just 32-bit.

The shell you use has very little bearing on the compiler toolchain that they invoke; you can build 64-bit code from a 32-bit shell. I do it often.

[Albrecht Schlosser]

On 28.07.2016 23:16 Ian MacArthur wrote:

> Indeed, you can invoke almost any compiler toolchain from Msys; as recently as last Wednesday I was using the MS cl compiler from a gnu Makefile in an Msys shell, with quite happy results.

> ...

>> - If you could get FLTK to work with MSYS2, this would be great because as far as I know, MSYS2 is the only way to get mingw_w64 to work on windows,
>
> Not so; I have run it from a stock Msys shell, and I think from a plain old DOS box, IIRC.

Note: I managed to install MinGW-W64 and to build FLTK with
x86_64-w64-mingw32-gcc to build 64-bit executables in a standard MinGW
(32-bit) environment. I need more checks before I may give detailed
instructions or write an article, but in a nutshell:


Download mingw-w64-install.exe from sourceforge

Run mingw-w64-install.exe
Use default values except:
Target: x86_64
Directory: "C:\mingw-w64"

Maybe change pthreads to Windows threads (don't recall exactly).

$ export PATH=/c/mingw-w64/mingw64/bin:$PATH

Note: MinGW-W64 PATH must be /before/ all other paths.

$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (x86_64-posix-seh, Built by MinGW-W64
project) 6.1.0

$ cd /path/to/fltk-1.3.4
$ make distclean

Run configure in cross compilation mode. Maybe you don't need "-static
-pthread" if you selected "Windows threads", but you need
"-static-libstdc++ -static-libgcc" to build native Windows executable
w/o dependencies on MinGW libs.

$ LDFLAGS="-static-libstdc++ -static-libgcc -static -pthread" \
./configure --host=x86_64-w64-mingw32

Now run make to build everything:

$ make

Note: I did not need to change anything in makeinclude (paths or libs),
because the cross compilation mode /and/ the MinGW-W64 path /before/ all
other paths makes sure that everything is detected correctly.

Note2: I got some warnings that gcc 6.1 detected. Some of these need
fixes, others are benign:

warning summary:
42 cast to pointer from integer of different size
[-Wint-to-pointer-cast]
2 suggest parentheses around operand of '!' or change '&' to '&&'
or '!' to '~' [-Wparentheses]
1 this 'while' clause does not guard... [-Wmisleading-indentation]
1 this 'for' clause does not guard... [-Wmisleading-indentation]
1 this 'else' clause does not guard... [-Wmisleading-indentation]

[Albrecht Schlosser]

On 29.07.2016 02:40 Albrecht Schlosser wrote:

> $ export PATH=/c/mingw-w64/mingw64/bin:$PATH
>
> Note: MinGW-W64 PATH must be /before/ all other paths.
>
> $ x86_64-w64-mingw32-gcc --version
> x86_64-w64-mingw32-gcc.exe (x86_64-posix-seh, Built by MinGW-W64
> project) 6.1.0
>
> $ cd /path/to/fltk-1.3.4
> $ make distclean
>
> Run configure in cross compilation mode. Maybe you don't need "-static
> -pthread" if you selected "Windows threads", but you need
> "-static-libstdc++ -static-libgcc" to build native Windows executable
> w/o dependencies on MinGW libs.
>
> $ LDFLAGS="-static-libstdc++ -static-libgcc -static -pthread" \
> ./configure --host=x86_64-w64-mingw32

FWIW: I just tested to execute configure w/o cross compilation mode (w/o
"--host=x86_64-w64-mingw32") since the PATH is set anyway, and it worked
as expected.

So if we used Windows threads (instead of posix threads when
downloading/installing MinGW-W64), I believe that we could simplify the
configure command to:

$ LDFLAGS="-static-libstdc++ -static-libgcc" ./configure

... options like --enable-local-* notwithstanding.

Ian, I'd like to know if you can confirm this - and also how (and with
which options) you installed MinGW-W64. I could not find anything except
the described installer or sources, but didn't want to compile MinGW-W64
myself. Any hints or links?

[Albrecht Schlosser]

On 29.07.2016 03:24 Albrecht Schlosser wrote:

> FWIW: I just tested to execute configure w/o cross compilation mode (w/o
> "--host=x86_64-w64-mingw32") since the PATH is set anyway, and it worked
> as expected.

I should have mentioned that the MinGW-W64 installer installed both
prefixed and unprefixed compiler executables etc., for instance

$ ls -1 /c/mingw-w64/mingw64/bin/*gcc.exe
/c/mingw-w64/mingw64/bin/gcc.exe
/c/mingw-w64/mingw64/bin/x86_64-w64-mingw32-gcc.exe

(identical files) which made me think that it /should/ work once the
PATH is set with /c/mingw-w64/mingw64/bin as the first entry in the path
list. And it did.

[Albrecht Schlosser]

On 29.07.2016 03:30 Albrecht Schlosser wrote:
> On 29.07.2016 03:24 Albrecht Schlosser wrote:
>
>> FWIW: I just tested to execute configure w/o cross compilation mode (w/o
>> "--host=x86_64-w64-mingw32") since the PATH is set anyway, and it worked
>> as expected.

Update: Meanwhile I downloaded MinGW-W64 with "win32" threads and "seh"
exception handling and used it to build native Windows 64-bit
executables both with configure/make and CMake/make under MinGW (32-bit).

Instructions in a nutshell (CMake build log appended):

(1) Install MinGW from mingw.org. Make sure you install gcc, g++, and
development tools. Not further documented here.

(2) Download and install MinGW-W64 from sourceforge. The easiest way I
found so far is to download the installer and to execute it.


https://sourceforge.net/projects/mingw-w64/files/latest/download?source=files

Run mingw-w64-install.exe:

Settings: Value: Comment/alternate options
Version: 6.1.0 YMMV: 5.4.0, 5.3.0, ...
Architecture: x86_64 (64-bit) i686 (32-bit)
Threads: win32 posix
Exception: seh seh | sjlj
Build revision: 0 (?)

See above for options I used successfully. YMMV.

(3) Now, in a MinGW shell:

$ export PATH=/c/mingw-w64/mingw64/bin:$PATH

$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (x86_64-posix-seh, Built by MinGW-W64
project) 6.1.0

Copyright (C) 2016 Free Software Foundation, Inc.
...

(4) Configure and build FLTK:

$ cd /path/to/fltk-1.3.4
$ make distclean

$ LDFLAGS="-static-libstdc++ -static-libgcc" ./configure

You may want to set more configure options.

(5) Execute 'make' to build FLTK.

(6) Done.

Hopefully this works for anybody.
Feedback appreciated.


As said above, I also built FLTK with CMake + make. Note that you should
never run CMake directly in the source directory. You shoud rather
create a separate build directory (optionally inside the FLTK source
tree, but this can be "anywhere").

I chose to use two levels of build directories inside the FLTK tree:

$ cd /path/to/fltk
$ mkdir -p build/mingw-w64
$ cd build/mingw-w64

I used a bash script file to generate the CMake files. This particular
file uses '../..' as the FLTK source directory and some compiler options
to enable all sorts of warnings. You may safely omit the line that sets
the CMake variable OPTION_OPTIM if you like.

I attach the CMake build log. Note that there were (only) three warnings
in the bundled libs which the log doesn't show for brevity (no warnings
in FLTK).

Again, feedback appreciated.

Note to the OP (Felix) and everybody else: I won't try to get MSYS2
working (see Ian's comments for some reasons). Since you can use MinGW
combined with the MinGW-W64 toolchain you should be able to build 64-bit
Windows executables following the instructions above and/or in the
attached log with either configure or CMake.

You should use current svn, at least r 11851 to get the best we can
offer today (this commit fixed a lot of warnings).

[Albrecht Schlosser]

On 29.07.2016 13:56 Albrecht Schlosser wrote:

> $ x86_64-w64-mingw32-gcc --version
> x86_64-w64-mingw32-gcc.exe (x86_64-posix-seh, Built by MinGW-W64
> project) 6.1.0
> Copyright (C) 2016 Free Software Foundation, Inc.
> ...

Correction: the above lines were taken from an old log. The correct
lines are:

$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (x86_64-win32-seh, Built by MinGW-W64
project) 6.1.0

Note 'win32-seh' instead of 'posix-seh'.

[Ian MacArthur]

On Fri Jul 29 2016 02:24:55, Albrecht Schlosser wrote:

> Ian, I'd like to know if you can confirm this - and also how (and with which options) you installed MinGW-W64. I could not find anything except the described installer or sources, but didn't want to compile MinGW-W64 myself. Any hints or links?

I’m going to give this a shot on that Win10 laptop: the machines I tried this on before I do not have ready access to, and I can’t really remember what we did. It was a while ago!
Once it was set up, it all pretty much just worked though, and AFAIK it still does.

(The machines are used by a colleague who works on a (largely fltk based) “kiosk” application, and she needed to do some testing of a 64-bit Windows build. The code normally runs on WinXX and Linux, but there’s no really heavy memory demands so a 32-bit build is generally fine...)

[Ian MacArthur]

Used Albrecht's recipe and it worked as described. Observations would be:

- Installing mingw64 was *really slow* on this laptop!
- The compiler seems slower than the 32-bit version; it is a much later version of gcc, and I think it is being much more "thorough" a it goes along...

The resulting binaries are reported by file as:-

$ file test/demo.exe
test/demo.exe: PE32+ executable for MS Windows (GUI) Mono/.Net assembly

Which looks about right - well, PE32+ is right, since that means 64-bit, bizarrely, not sure what "Mono/.Net assembly" means, but the 64-bit exe's I built with VS report the same, so I assume that is the correct answer.

For comparison, the mingw32 versions report:

$ file test/demo.exe
test/demo.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

[Albrecht Schlosser]

On 30.07.2016 18:46 Ian MacArthur wrote:

> Used Albrecht's recipe and it worked as described.

Thanks for testing.

> Observations would be:
> - Installing mingw64 was *really slow* on this laptop!

I installed another version (gcc 4.8.1). Yes, it took a while to
download, unpack, and install, but I think it was acceptable. I don't
know the exact time though.

> - The compiler seems slower than the 32-bit version; it is a much later
> version of gcc, and I think it is being much more "thorough" a it goes
> along...

You're right, I tested different versions, and there are significant
differences. I used CMake / make for all versions. I compiled the first
four tests with 'make' and the last one with 'make -j3' for comparison.
Note that you can't compile with 'make -j3' (-j<n> with n > 1) under
MinGW, although it works under Cygwin.

Test Summary:

(1) gcc 4.8.1 (MinGW 32-bit) 155 sec = 100 %
(2) gcc 4.8.1 (MinGW-w64 64-bit) 217 sec = 140 %
(3) gcc 6.1.0 (MinGW-w64 64-bit) 339 sec = 219 %
(4) gcc 4.8.4 (Ubuntu 64-bit) 46 sec = 30 %
(5) gcc 4.8.4 (dto.: make -j3) 32 sec = 21 %

As you can see in (1 vs. 2) the 64-bit compiler adds about 40% to the
compile time. gcc 6.1, compared with 4.8.1 (2 vs. 3) adds additional 50%
(119% compared to 4.8.1/32-bit).

Linux gcc 4.8.4 is *much* faster, and you can compile with -j3 which
reduces compile time even more. The Linux compilation was done on the
same notebook in a Virtualbox VM. When executing the tests, Windows task
manager showed comparable CPU usage (36% - 40%).

BTW (OT): That's one reason why I chose to do all FLTK (and other
software) development under Linux (in a VM on a Windows host), unless I
want to test Windows specific features. Meanwhile I converted
(upgraded??? ;-) my notebook and my PC to Windows 10, hence I don't have
Win7 and Win8 for development and tests any longer.

> The resulting binaries are reported by file as:-
>
> $ file test/demo.exe
> test/demo.exe: PE32+ executable for MS Windows (GUI) Mono/.Net assembly

Same here:

$ file bin/examples/demo.exe
bin/examples/demo.exe: PE32+ executable for MS Windows (GUI) Mono/.Net
assembly

[Brian Tilley]

> On 30 July 2016 at 22:44, Albrecht Schlosser

>
> Note that you can't compile with 'make -j3' (-j<n> with n > 1) under MinGW, although it works under Cygwin.

>

Hi,

I use MSys and MinGW32 all the time at work and am therefore surprised you state that make -j3 doesn't work.

I use make -j which determines how many cores you have and uses them all.

So make -j is equivalent on my corei5 to make -j4

And I can confirm that all four cores ARE used.

But it occurs to me that you may not be using MSys. The version of make in MSys does work.

Whereas (at least in MinGW32) the MinGW make is said to be inferior.

So if (as suggested by Ian) you use MSys32 with MinGW64,

Then make -j (or make -j3) should work OK.

[Albrecht Schlosser]

On 31.07.2016 07:58 'Brian Tilley' via fltk.general wrote:
>
>> On 30 July 2016 at 22:44, Albrecht Schlosser
>>
>> Note that you can't compile with 'make -j3' (-j<n> with n > 1) under
> MinGW, although it works under Cygwin.
>

> I use MSys and MinGW32 all the time at work and am therefore surprised
> you state that make -j3 doesn't work.
> I use make -j which determines how many cores you have and uses them all.
> So make -j is equivalent on my corei5 to make -j4
> And I can confirm that all four cores ARE used.

Thanks for your comment and the correction. I had an older MinGW install
that really didn't work with -jn (n>1). After the first n compiled files
the process hung reproducibly. The only way to recover was to kill one
or more make processes (with kill or Windows task manager). With that in
mind I had never tried make -jn in my more recent MinGW version, but now
I see that it works. Thanks for the hint.

I verified today that this was still the case in my old MinGW
installation. I could not upgrade the installation (at least selective
upgrades didn't help), but a full new install works now - almost. I
still get some hangs after lots of compiled files with make -j (4
cores), but I can restart after that. The problem is if it hangs: then
one make process obviously uses 100% CPU of one core (~25% total).

However, I had almost always success with make -j3. I don't know if this
is a race condition in MinGW / MSYS / make.

> But it occurs to me that you may not be using MSys. The version of make
> in MSys does work.

I do use MSYS, and I use msys make (/bin/make which is mapped by mount
to C:\MinGW\msys\1.0\bin\make).

[Ian MacArthur]

On Sun Jul 31 2016 13:53:06, Albrecht Schlosser wrote:
>
> On 31.07.2016 07:58 'Brian Tilley' via fltk.general wrote:
>>
>>> On 30 July 2016 at 22:44, Albrecht Schlosser
>>>
>>> Note that you can't compile with 'make -j3' (-j<n> with n > 1) under
>> MinGW, although it works under Cygwin.
>>
>> I use MSys and MinGW32 all the time at work and am therefore surprised
>> you state that make -j3 doesn't work.
>> I use make -j which determines how many cores you have and uses them all.
>> So make -j is equivalent on my corei5 to make -j4
>> And I can confirm that all four cores ARE used.
>
> Thanks for your comment and the correction. I had an older MinGW install that really didn't work with -jn (n>1). After the first n compiled files the process hung reproducibly. The only way to recover was to kill one or more make processes (with kill or Windows task manager). With that in mind I had never tried make -jn in my more recent MinGW version, but now I see that it works. Thanks for the hint.

Well... I’m not sure it’s clear cut though.

(As Brian knows) I have an assortment of machines, all with ostensibly “the same” Msys setup, and on some of these "make -j2" works without issues, on others it tends to hang stuck in some sort of loop. On at least one machine “mingw32-make -j2” will work whilst “make -j2” will hang.

I think *all* of Brian’s machines (usually) work, and they are set up broadly “the same” as mine are... It does seem to be sensitive to something in the environment, perhaps the specific CPU, or the specific libraries installed, or something. DOn’t know what.

[Felix Schütt]

Code hier eingeben...

I can still not build and I've followed your advice.

(1) Install MinGW from mingw.org. Make sure you install gcc, g++, and 
development tools. Not further documented here. 

I did:

 

 (2) Download and install MinGW-W64 from sourceforge. The easiest way I 

found so far is to download the installer and to execute it. 

I did, it installed in the default location of "C:\Program Files\mingw-w64\x86_64-6.1.0-win32-seh-rt_v5-rev0".

(3) Now, in a MinGW shell: 

$ export PATH=/c/mingw-w64/mingw64/bin:$PATH 

Now, here I am wondering how you did this and what it should do. As far as I can see, you are adding the location of the mingw-w64\bin to your PATH variable.

So did I (see the last two variables):

Here is the problem, though: mingw-64 does not come with any autotools, so I have to take them from the mingw32 installation. When I try to run anything without adding mingw32 to PATH, it tells me that automake, autoconf, etc. were not found.

The mingw32 installation is installed in C:\MinGW\bin. However, when I now echo "gcc --version", I of course get two gcc compilers found.

Second, what are you referring to as a "MinGW shell"? 

I installed MSYS (not MSYS2) and edited the /etc/fstab file to point to the 32-bit MinGW installation.

An MSYS shell looks like this (1):

An MinGW terminal looks like this:

As you can see, the "MinGW terminal" does not recognize the commands make or automake, however, they are added to the PATH.

echoing the PATH in an MSYS shell gives me the same file paths as the built-in Windows editor (see above). So I am not sure if I completed this step correctly.

I checked out the latest svn copy, unzipped it, went into the directory and ran "make distclean".

The result:

Felix@FELIX ~

$ gcc --version

Felix@FELIX /d/fltk/fltk-1.3

$ ls

ANNOUNCEMENT    DartConfig.cmake      README.OSX.txt          cairo             fltk.spec.in  mac_endianness.h

CHANGES         FL                    README.Unix.txt         configh.cmake.in  fltk.xpm      makeinclude.in

CHANGES_1.0     GL                    README.abi-version.txt  configh.in        fluid         makesrcdist

CHANGES_1.1     Makefile              VERSION                 configure.in      forms.h       misc

CMake           README                abi-version.cmake.in    documentation     ide           png

CMakeLists.txt  README.CMake.txt      abi-version.ide         examples          install-sh    src

COPYING         README.Cairo.txt      abi-version.in          fltk-config.in    jpeg          test

CREDITS         README.MSWindows.txt  autogen.sh              fltk.list.in      lib           zlib

Felix@FELIX /d/fltk/fltk-1.3

$ make distclean

Makefile:19: makeinclude: No such file or directory

autoconf

/mingw/autoconf-2.68: line 501: /mingw/bin/autom4te-2.68: No such file or directory

/mingw/autoconf-2.68: line 501: exec: /mingw/bin/autom4te-2.68: cannot execute: No such file or directory

make: *** [configure] Error 126

Why does this fail? autom4te-2.68 is in "C:\MinGW\bin", the mingw32 installation directory, that I added to the PATH. It should be found.

What is "makeinclude"?

I am still not any closer to building FLTK and actually doing something with it, if anybody could help, that'd be great.

Thanks in advance,

Felix

[Albrecht Schlosser]

On 01.08.2016 22:14 Felix Schütt wrote:

> I can still not build and I've followed your advice.

> (1) Install MinGW from mingw.org <http://mingw.org/>. Make sure you

> install gcc, g++, and
> development tools. Not further documented here.
>
> I did:

> <http://i.imgur.com/xAAY88R.png>

Okay, that seems to be okay so far.

> (2) Download and install MinGW-W64 from sourceforge. The easiest way I
> found so far is to download the installer and to execute it.
>
> I did, it installed in the default location of "C:\Program
> Files\mingw-w64\x86_64-6.1.0-win32-seh-rt_v5-rev0".

That's not okay. Never install any MinGW, Cygwin etc. tools in paths
with spaces like "C:\Program Files\...". Unix tools don't like spaces
unless you escape them, and that calls for trouble.

> (3) Now, in a MinGW shell:
> $ export PATH=/c/mingw-w64/mingw64/bin:$PATH
>
> Now, here I am wondering how you did this and what it should do.

You should have _typed_ that literally (w/o the '$' that represents the
shell prompt). However, it's too late now to tell you how exactly you
should proceed to start a MinGW shell. I can do that tomorrow, since I
took some notes when I installed my new MinGW and MinGW-w64 versions.

> As far
> as I can see, you are adding the location of the mingw-w64\bin to your
> PATH variable.
> So did I (see the last two variables):
>

> <http://i.imgur.com/7jnOG05.png>

You _can_ change the Windows PATH variable, but this is not recommended.
The way I showed you (see above) was to do this in the MinGW shell. The
most important point (given in my command and IIRC somewhere in my
posts) is that the MinGW-w64 path is _before_ all other MinGW paths.
Otherwise some of the tools will be used from the MinGW and some from
the MinGW-w64 installation which doesn't work.

> Here is the problem, though: mingw-64 does not come with any autotools,
> so I have to take them from the mingw32 installation. When I try to run
> anything without adding mingw32 to PATH, it tells me that automake,
> autoconf, etc. were not found.

If you run a MinGW shell, then the mingw32 tools are in the PATH. This
is necessary.

> The mingw32 installation is installed in C:\MinGW\bin. However, when I
> now echo "gcc --version", I of course get two gcc compilers found.

If you execute "gcc --version" you can see only one gcc version (the
first one in the PATH).

> Second, what are you referring to as a "MinGW shell"?

I'll tell you exactly how to do that tomorrow.

> I installed MSYS (not MSYS2) and edited the /etc/fstab file to point to
> the 32-bit MinGW installation.

I know it is said so in the MinGW "Getting started" page, but actually
it's not necessary if you used the graphical installer (as your first
image indicates). The graphical installer does this for you.

> An MSYS shell looks like this (1):
>

> <http://i.imgur.com/7odPOa3.png>

>
>
> An MinGW terminal looks like this:
>

> <http://i.imgur.com/wPeVfHa.png>

>
>
> As you can see, the "MinGW terminal" does not recognize the commands
> make or automake, however, they are added to the PATH.
>
> echoing the PATH in an MSYS shell gives me the same file paths as the
> built-in Windows editor (see above). So I am not sure if I completed
> this step correctly.

Probably not. But I see that "autoconf" works. The error message in your
image (BTW: please cut & paste text wherever possible, this is easier to
read and comment on here) is:

$ autoconf
autoconf-2.68: error: no input file

This shows that autoconf works, but there is no _input_ file (you ran
that command in your home directory). Please try this in the FLTK root
directory again, or use 'autoconf --version':

$ autoconf --version
autoconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>,
<http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

> I checked out the latest svn copy, unzipped it, went into the directory
> and ran "make distclean".
>
>
> The result:

make should work, there must be something wrong with your setup. I'll
post step by step instructions tomorrow.

> Felix@FELIX ~
> $ gcc --version

This doesn't show anything in your post. Did you forget to copy the output?

> Felix@FELIX /d/fltk/fltk-1.3
> $ ls
...

that looks okay.

> Felix@FELIX /d/fltk/fltk-1.3
> $ make distclean
> Makefile:19: makeinclude: No such file or directory

This part is normal when you run make for the first time. The file
makeinclude doesn't exist but will be created. You can safely ignore
this warning.

> autoconf
> /mingw/autoconf-2.68: line 501: /mingw/bin/autom4te-2.68: No such file
> or directory
> /mingw/autoconf-2.68: line 501: exec: /mingw/bin/autom4te-2.68: cannot
> execute: No such file or directory
> make: *** [configure] Error 126

That looks definitely wrong.

> Why does this fail? autom4te-2.68 is in "C:\MinGW\bin", the mingw32
> installation directory, that I added to the PATH. It should be found.

/mingw is a mount point in MinGW (something that can be created with
'mount', but MinGW should do this for you. That's what /etc/fstab is
good for. There must be something wrong.

Please run these two commands and post the output:

mount
echo $PATH


> What is "makeinclude"?

See above, a generated file that is later used (included) in all Makefile's.

> I am still not any closer to building FLTK and actually doing something
> with it, if anybody could help, that'd be great.

I'll see what I can do tomorrow. I'm sure we'll get you going. I did a
fresh install on another PC and Ian did the same and confirmed that it
worked, so it should work for you as well.

Before we start, please prepare your system:

(1) remove all (mingw-32 and mingw-64) PATH settings from the Windows
PATH variable. These are absolutely not necessary and can make problems.
Once you have a working installation all PATH changes will be done
inside the MinGW shell.

(2) remove the mingw-w64 installation. I'll give you detailed
instructions how to install it (and where). Basically every path w/o
spaces should work (don't use the default). I recommend 'C:\mingw-w64',
but please wait ...

(3) remove the mingw32 installation as well. I'll tell you which
packages you should install to get the best out of MinGW.

[t8r...@gmail.com]

On Tue, Jul 26, 2016, at 23:31, Felix Schütt wrote:

Hi. I am trying to follow the installation instructions for installing FLTK on Windows 10: http://www.fltk.org/articles.php?L598+I100+T+P1+Q

I have done the following:

• I installed MSYS2 64 bit
  
• Via the MSYS terminal, I installed the mingw-w64-x86_64-toolchain: 
  
• 
  

  $ pacman -S mingw-w64-x86_64-toolchain
  

  
  
  
  
• I downloaded fltk 1.3.3 from the website
  
• I unpacked it (the installation instructions have by the way not been updated, as fltk is not bzip2 compressed anymore, but gzip compressed)
  

• tar -xf fltk-1.3.3-source.tar.gz
cd fltk-1.3.3/


• ./configure --enable-threads --enable-localjpeg --enable-localzlib --enable-localpn
  

I managed to compile FLTK with msys2 (gcc 6.1.0) in 64 bit mode using following configure:

./configure --build=mingw32 --enable-localjpeg  --enable-localzlib  --enable-localpng LDFLAGS=-static

Static flag is for stdc++ so you don't have to rely on libstdc++-6.dll from msys2.

And build flag is to tell msys2 that we are compiling for windows and not X.

[bat]

Brilliant. Worth a mention in the manual.