cmake, mingw64, HAVE_DLFCN_H and HAVE_DLSYM maybe weird? [General Use]

[MacArthur, Ian (Leonardo, UK)]

All,

I'm seeing something weird with a cmake build (mostly I'm thinking of the 1.4 branch here, but I suspect the 1.3.x branch may be the same.)

Specifically, when doing a 64-bit cmake Windows build using mingw64, I'm seeing the macro HAVE_DLFCN_H set to 1 and the macro HAVE_DLSYM set to zero, which seems to then lead to invalid file #includes in some of the source files and the build chokes.

For comparison:

A 32-bit or 64-bit VS build sets both HAVE_DLFCN_H and HAVE_DLSYM to 0, and that seems to be correct.

A mingw32 build with either autoconf or cmake, sets both HAVE_DLFCN_H and HAVE_DLSYM to 1, and that seems to be OK, too. (Though arguably wrong! I think that mingw32 fakes up dlfcn.h and dlsym, which is why this "works", but likely we do not use it at all in practice since it is likely we actually use wglGetProcAddress() et al instead anyway in a win32/win64 build.)

A mingw64 autoconf build sets both HAVE_DLFCN_H and HAVE_DLSYM to 0, and that seems to be correct.

A mingw64 cmake build sets HAVE_DLFCN_H to 1 and HAVE_DLSYM to 0, and that seems to be problematic.


I can't even tell why it is doing this (it may well be some weirdness in my setup, for example) but I have seen this now on two "different" Windows machines.
(Though both configured by me, so actually not all that "different" in practice!)

This leads to problems because the mingw64 headers *do not* include a header file for dlfcn.h, but if HAVE_DLFCN_H is set we try to include dlfcn.h in several places.


In practice, most places we have this test:-

#if HAVE_DLSYM && HAVE_DLFCN_H
#include <dlfcn.h> // for dlopen et al
#endif


So since HAVE_DLSYM is (correctly, for mingw64) set to zero, this works fine.

But in a few places we only have this test:-

# if HAVE_DLFCN_H
# include <dlfcn.h>
# endif // HAVE_DLFCN_H

Since my cmake is erroneously setting HAVE_DLFCN_H, this then chokes.

The possibly "afflicted" files are glut_compatability.cxx, Fl_Window_shape.cxx, Fl_Preferences.cxx.

In practice, due to other compile time guards, only "glut_compatability.cxx" actually fails to build.
(Manually editing config.h to correct the setting of HAVE_DLFCN_H makes the build work.)


I don't know enough cmake to know why it is setting HAVE_DLFCN_H in config.h, and can't tell if this is unique to my set up or is a more general issue.

Cheers,
--
Ian




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Albrecht Schlosser]

On 29.11.2016 12:50 MacArthur, Ian (Leonardo, UK) wrote:

> I'm seeing something weird with a cmake build (mostly I'm thinking of the 1.4 branch here, but I suspect the 1.3.x branch may be the same.)
>
> Specifically, when doing a 64-bit cmake Windows build using mingw64, I'm seeing the macro HAVE_DLFCN_H set to 1 and the macro HAVE_DLSYM set to zero, which seems to then lead to invalid file #includes in some of the source files and the build chokes.

I can confirm your findings and I also see the build using mingw64 fail.

> I can't even tell why it is doing this (it may well be some weirdness in my setup, for example) but I have seen this now on two "different" Windows machines.
> (Though both configured by me, so actually not all that "different" in practice!)

It's in my setup as well.

> This leads to problems because the mingw64 headers *do not* include a header file for dlfcn.h, but if HAVE_DLFCN_H is set we try to include dlfcn.h in several places.

I'm looking into this ...

> I don't know enough cmake to know why it is setting HAVE_DLFCN_H in config.h, and can't tell if this is unique to my set up or is a more general issue.

So far I can see (or at least assume) why it is setting HAVE_DLFCN_H in
config.h, but I don't know exactly *what* is happening yet.

The difference between configure and CMake seems to be (and this is pure
guessing) that configure uses a compilation test to find out if a header
file exists and can be compiled, whereas *our CMake script* uses
find_file() to test if a header file exists, which is obviously done
without compilation.

Indeed, on my MinGW system I have:

$ ls /mingw/include/pthread.h /mingw/include/dlfcn.h
/mingw/include/dlfcn.h /mingw/include/pthread.h

I included pthread.h because I can also see a difference related to
pthread.h with configure vs. CMake.

Stripped output of the relevant parts of the diff:

$ diff -rubw config.h build/mingw-w64/config.h
...
-/* #undef HAVE_PTHREAD */
-/* #undef HAVE_PTHREAD_H */
+#define HAVE_PTHREAD 1
+#define HAVE_PTHREAD_H 1
...
-#define HAVE_DLFCN_H 0
+#define HAVE_DLFCN_H 1

So, although the header file exists _somewhere_ it can't be compiled
because it is not in the preprocessor's search path - and I don't know
if it would be useful to have/use it anyway. The question is: why does
CMake find the headers in this location (what are the search paths used
for find_file()), why does the compiler not user these files, and why
are they there in the first place. Or any variations of these questions.

There are several ways how the CMake test(s) can be changed, but so far
I don't know of a good solution. This needs more investigation. It's too
late now, I just wanted to tell you I'm working on it. I'll dive further
into it and let you know when (if!) I found a solution.

PS: you can search the CMake variables in cmake-gui or run 'cmake -L' or
'cmake -LA' to check CMake variables. In this case I see:

$ cmake -LA 2>/dev/null | grep 'HAVE_PTHREAD\|HAVE_DLFCN'
HAVE_DLFCN_H:FILEPATH=/MinGW/include/dlfcn.h
HAVE_PTHREAD_H:FILEPATH=/MinGW/include/pthread.h

which shows that CMake found the (wrong??) files.

To be continued...

[Albrecht Schlosser]

Status update:

Our CMake script adds '/mingw' to CMake's (header) search path if CMake
runs under MinGW and this directory exists. Standard gcc uses this path
for header searches, but my installed mingw-w64 gcc does not use this
path (use 'gcc -v' to see the configured include path).

For the standard gcc this additional CMake search path is really
necessary, otherwise some GL/GLU headers are not found and some of the
demo programs (for instance glpuzzle and fractals) don't work.

If I omit this additional path with mingw-w64 FLTK builds w/o problems
but lacks GL/GLU support (and maybe something else). The relevant
statement is in CMake/setup.cmake, line #124:

list(APPEND CMAKE_PREFIX_PATH /mingw)

Comment that line out if you want to test yourself...


I don't have a working (good) solution yet...

[MacArthur, Ian (Leonardo, UK)]

> Status update:

Thanks for taking the time to look at this Albrecht.

> Our CMake script adds '/mingw' to CMake's (header) search path if CMake
> runs under MinGW and this directory exists. Standard gcc uses this path
> for header searches, but my installed mingw-w64 gcc does not use this
> path (use 'gcc -v' to see the configured include path).

OK, so if I understand, what is going on is:-

1. Using mingw32 "requires" us to add "/mingw" to the header search path, so that it will work (find GL support files).

2 mingw32 also provides a stub for dlfcn.h, and wrapper function to "emulate" the behaviour of dlsym() et al at runtime (which we detect but do not actually use, AFAICT, under mingw32.)

3. But mingw64 provides its own headers (not in the "/mingw" path) and *does not* provide stubs for dlfcn.h et al.

4. When we configure with mingw64 using cmake, it does not find dlfcn.h in amongst mingw64's own headers, but does then find it amongst the added search paths in "/mingw", and erroneously reports than dlfcn.h is therefore available for mingw64 to use

5. But at compile time, mingw64 (correctly) does not use the headers from "/mingw", and so we get a fail.

6. This does not happen with autoconf, since that tests for the headers by attempting to compile test files (which fails as expected) rather than by using find_file.

> I don't have a working (good) solution yet...

It might be enough simply to edit glut_compatability.cxx to change the conditional test


#if HAVE_DLFCN_H
# include <dlfcn.h>
#endif // HAVE_DLFCN_H


To replace it with

#if HAVE_DLSYM && HAVE_DLFCN_H
#include <dlfcn.h

#endif


That will "fix" the issue since we correctly detect that HAVE_DLSYM is *not* available under mingw64 already, and thereafter everything ought to be fine.

[Albrecht Schlosser]

On 30.11.2016 16:09 MacArthur, Ian (Leonardo, UK) wrote:
>> Status update:
>
> Thanks for taking the time to look at this Albrecht.
>
>> Our CMake script adds '/mingw' to CMake's (header) search path if CMake
>> runs under MinGW and this directory exists. Standard gcc uses this path
>> for header searches, but my installed mingw-w64 gcc does not use this
>> path (use 'gcc -v' to see the configured include path).
>
> OK, so if I understand, what is going on is:-
>
> 1. Using mingw32 "requires" us to add "/mingw" to the header search path, so that it will work (find GL support files).
>
> 2 mingw32 also provides a stub for dlfcn.h, and wrapper function to "emulate" the behaviour of dlsym() et al at runtime (which we detect but do not actually use, AFAICT, under mingw32.)
>
> 3. But mingw64 provides its own headers (not in the "/mingw" path) and *does not* provide stubs for dlfcn.h et al.
>
> 4. When we configure with mingw64 using cmake, it does not find dlfcn.h in amongst mingw64's own headers, but does then find it amongst the added search paths in "/mingw", and erroneously reports than dlfcn.h is therefore available for mingw64 to use
>
> 5. But at compile time, mingw64 (correctly) does not use the headers from "/mingw", and so we get a fail.

Ack to all (1-5).

> 6. This does not happen with autoconf, since that tests for the headers by attempting to compile test files (which fails as expected) rather than by using find_file.

I'm not sure about 6, i.e. I don't know if configure really compiles
anything to test the existence of headers. That was an early assumption
only.

>> I don't have a working (good) solution yet...
>
> It might be enough simply to edit glut_compatability.cxx to change the conditional test
>
>
> #if HAVE_DLFCN_H
> # include <dlfcn.h>
> #endif // HAVE_DLFCN_H
>
>
> To replace it with
>
>
> #if HAVE_DLSYM && HAVE_DLFCN_H
> #include <dlfcn.h
> #endif
>
>
> That will "fix" the issue since we correctly detect that HAVE_DLSYM is *not* available under mingw64 already, and thereafter everything ought to be fine.

Yep, that would be a working solution, but IMHO not a good one. I'd
rather want to find out what's going on. And, BTW, this wouldn't fix
HAVE_GL_GLU_H which is necessary to compile glpuzzle and fractals.

Ian, let's go one step back to see how we installed and how we use
'mingw64' compilers. What did you do to make it work with configure, and
how do you use it with CMake? Could you please describe your installation?

Note: I could describe my installation and usage, but I experimented
with so many different options that this would be hard to do. I think we
both did not install msys2, but I have no idea how you installed and how
you use the 64-bit compilers. This might help to find out common things.

[Ian MacArthur]

On Wed Nov 30 2016 17:03:49, Albrecht Schlosser wrote:
>
>>> I don't have a working (good) solution yet...
>>
>> It might be enough simply to edit glut_compatability.cxx to change the conditional test
>>
>>
>> #if HAVE_DLFCN_H
>> # include <dlfcn.h>
>> #endif // HAVE_DLFCN_H
>>
>>
>> To replace it with
>>
>>
>> #if HAVE_DLSYM && HAVE_DLFCN_H
>> #include <dlfcn.h
>> #endif
>>
>>
>> That will "fix" the issue since we correctly detect that HAVE_DLSYM is *not* available under mingw64 already, and thereafter everything ought to be fine.
>
> Yep, that would be a working solution, but IMHO not a good one. I'd rather want to find out what's going on. And, BTW, this wouldn't fix HAVE_GL_GLU_H which is necessary to compile glpuzzle and fractals.

It might not be “wrong” for the HAVE_DLFCN_H case though - it matches what we have done in most other files, and indeed matches what is later done in the same file before we actually call in dlopen() and so forth, so would at least be consistent! ;-)

Though it doesn’t resolve the underlying issue of *why* cmake reports finding dlfcn.h in the first place.

Can you clarify on the HAVE_GL_GLU_H issue?

Last time I tried this (yesterday) the GL samples of both the mingw32 and mingw-64 *appeared* to be running OK for me. I think...!

>
> Ian, let's go one step back to see how we installed and how we use 'mingw64' compilers. What did you do to make it work with configure, and how do you use it with CMake? Could you please describe your installation?

I have only a few machines with the mingw-64 tools, and they were all set up “the same”.

All started with a working mingw32/Msys install, which is “up to date” with mingw-get.

I then installed the mingw-64 tools in a separate location (well away from the mingw32 stuff!) but I access them from an Msys shell - all I do to make this work is that the “64-bit tools” version of the shell is launched with it’s PATH modified to go to the mingw-64 bin (and etc.) folders first; then various other places, then eventually to the “normal” mingw32 and Msys places.

(This does mean that the “64-bit” tool shell can still end up in mingw32 territory though, if it doesn’t find what it needs in the mingw-64 locations.)

So far, this has Just Worked for me; from the “64-bit tools” shell I can run autoconf et al as normal and it appears to work fine, and the generated binaries work OK and are compiled / linked using the mingw-64 tools, and “file" reports them as "PE32+”, which initially confused me but apparently is correct for Win64 binaries!

Except that cmake doesn’t seem to like this quite so well, as noted.

It’s entirely likely there are better ways to install the mingw-64 tools, of course.

[Albrecht Schlosser]

On 30.11.2016 22:55 Ian MacArthur wrote:

> Can you clarify on the HAVE_GL_GLU_H issue?

Sorry, I don't have enough time right now (today), so here's the short
form for now...

$ diff -ubw config.h build/mingw64_OFF/
--- config.h 2016-11-30 21:05:39 +0000
+++ build/mingw64_OFF//config.h 2016-11-30 16:09:39 +0000
@@ -1,4 +1,4 @@
-/* config.h. Generated from configh.in by configure. */
+/* config.h. Generated from configh.cmake.in by CMake. */
/*
...

@@ -56,7 +56,7 @@
* (many broken Mesa RPMs do not...)
*/

-#define HAVE_GL_GLU_H 1
+#define HAVE_GL_GLU_H 0

This means that everything builds okay, but glpuzzle and fractals "don't
work", i.e. they display an error message.

> Last time I tried this (yesterday) the GL samples of both the mingw32 and mingw-64 *appeared* to be running OK for me. I think...!

Other GL test programs are fine.

>> Ian, let's go one step back to see how we installed and how we use 'mingw64' compilers. What did you do to make it work with configure, and how do you use it with CMake? Could you please describe your installation?
>
>
> I have only a few machines with the mingw-64 tools, and they were all set up “the same”.
>
> All started with a working mingw32/Msys install, which is “up to date” with mingw-get.
>
> I then installed the mingw-64 tools in a separate location (well away from the mingw32 stuff!) but I access them from an Msys shell - all I do to make this work is that the “64-bit tools” version of the shell is launched with it’s PATH modified to go to the mingw-64 bin (and etc.) folders first; then various other places, then eventually to the “normal” mingw32 and Msys places.
>
> (This does mean that the “64-bit” tool shell can still end up in mingw32 territory though, if it doesn’t find what it needs in the mingw-64 locations.)
>
> So far, this has Just Worked for me; from the “64-bit tools” shell I can run autoconf et al as normal and it appears to work fine, and the generated binaries work OK and are compiled / linked using the mingw-64 tools, and “file" reports them as "PE32+”, which initially confused me but apparently is correct for Win64 binaries!
>
> Except that cmake doesn’t seem to like this quite so well, as noted.
>
> It’s entirely likely there are better ways to install the mingw-64 tools, of course.

Thanks, that's basically what I did. I also tried to run CMake with a
cross-compiling "toolchain file", but that didn't change much.

[Albrecht Schlosser]

On 01.12.2016 09:06 Albrecht Schlosser wrote:
> On 30.11.2016 22:55 Ian MacArthur wrote:
>
>> Can you clarify on the HAVE_GL_GLU_H issue?
>
> Sorry, I don't have enough time right now (today), so here's the short
> form for now...
>
> $ diff -ubw config.h build/mingw64_OFF/
> --- config.h 2016-11-30 21:05:39 +0000
> +++ build/mingw64_OFF//config.h 2016-11-30 16:09:39 +0000
> @@ -1,4 +1,4 @@
> -/* config.h. Generated from configh.in by configure. */
> +/* config.h. Generated from configh.cmake.in by CMake. */
> /*
> ...
>
> @@ -56,7 +56,7 @@
> * (many broken Mesa RPMs do not...)
> */
>
> -#define HAVE_GL_GLU_H 1
> +#define HAVE_GL_GLU_H 0
>
> This means that everything builds okay, but glpuzzle and fractals "don't
> work", i.e. they display an error message.

Well, I should have mentioned that build/mingw64_OFF/ was very likely a
build where I removed the additional '/mingw' search path. Maybe that's
not the case in a default CMake build.

[MacArthur, Ian (Leonardo, UK)]

Albrecht (et al)

Just to note that at r12136 I pushed a minor change to Fl_Gl_Window.cxx that ducks the cmake/mingw-64 issue with HAVE_DLFCN_H and the build is now "correct".

(Though I acknowledge Albrecht's concern that this is a workaround, not really a fix, for whatever the underlying issue really is with the cmake configure phase.)


Also:

> >> Can you clarify on the HAVE_GL_GLU_H issue?

> > This means that everything builds okay, but glpuzzle and fractals
> "don't
> > work", i.e. they display an error message.

I tried all the GL examples in the test folder, for fltk-1.4 current built with all 4 of:-

configure/mingw32
cmake/mingw32
configure/mingw-64
cmake/mingw-64

So far as I could see, the GL examples, including "glpuzzle" and "fractals", seemed to Just Work, in all cases.

Perhaps the GL issue you were reporting has been fixed?
Or is not manifest in my set-up for some reason? (Which might be more of a worry, if it is hard to reproduce!)

Cheers,
--
Ian

[Albrecht Schlosser]

On 06.12.2016 11:11 MacArthur, Ian (Leonardo, UK) wrote:
> Albrecht (et al)
>
> Just to note that at r12136 I pushed a minor change to Fl_Gl_Window.cxx that ducks the cmake/mingw-64 issue with HAVE_DLFCN_H and the build is now "correct".

Thanks for fixing this.

I lost momentum in my research, although I made some progress. However,
I don't have a clear and simple solution for end users yet.

> I tried all the GL examples in the test folder, for fltk-1.4 current built with all 4 of:-
>
> configure/mingw32
> cmake/mingw32
> configure/mingw-64
> cmake/mingw-64
>
> So far as I could see, the GL examples, including "glpuzzle" and "fractals", seemed to Just Work, in all cases.
>
> Perhaps the GL issue you were reporting has been fixed?
> Or is not manifest in my set-up for some reason? (Which might be more of a worry, if it is hard to reproduce!)

Don't worry, I'm pretty sure this was caused by my experimental setup.

Still investigating... Meanwhile I made a little more progress, but I
have a few questions:

(1) Please post your gcc version. This is mine:

$ gcc --version | head -n1
gcc.exe (x86_64-win32-seh, Built by MinGW-W64 project) 6.1.0

----------------^^^^^-^^^

The interesting part is the thread model (win32) and exception handling
(seh). Both options must be selected when installing mingw-w64. Other
options for thread model would be 'posix' and for exception handling
that would be 'sjlj'. I'm particularly interested in the thread model,
but I'm also interested in any insight in what exception handling (seh
or sjlj) we should recommend for end users (although I'm aware that FLTK
doesn't use exceptions). Any clues?


(2) Please start a "Windows Explorer" Window and cd to your build/bin
and/or build/bin/examples folder(s), resp. Can you start the Windows
exe's by clicking on the resp. .exe files in the explorer window:

(a) bin/fluid
(b) bin/examples/demo and others, particularly:
(c) bin/glpuzzle and
(d) bin/threads ?


(3) How did you configure your CMake build, which options did you enter
on the command line, which options did you change elsewhere (cmake-gui)?


(4) Can you please run cmake with this command line and report if this
works for you?

$ cmake -G"Unix Makefiles" -DCMAKE_EXE_LINKER_FLAGS='-static-libgcc
-static-libstdc++' -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_THREADS=OFF
<path/to/fltk>

This is my latest command line to build FLTK with mingw-w64 (gcc 6.1.0)
as shown above, after modifying the PATH in the same way you described.

FWI: echo $PATH
/c/mingw-w64_win32/bin:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32

I'm always trying to use the _minimal_ PATH I can find for development.


Side note: -DOPTION_USE_THREADS=OFF was used intentionally (threads.exe
still works with Windows Threads). If I don't use this (OFF), then CMake
obviously finds pthreads in my mingw and/or mingw-w64 environment and
links with -pthread which leads to threads.exe depending on
winpthread.dll or similar.

I'm sure I can "fix" this but the "correct" solution is not yet clear to
me. Basically we shouldn't even look for libpthread under WIN32/MinGW,
but someone might want to use pthreads (or C++11 threads?) in their build.

[Ian]

On 06/12/2016 14:40:53, "Albrecht Schlosser" wrote:

>
>Still investigating... Meanwhile I made a little more progress, but I
>have a few questions:
>
>(1) Please post your gcc version. This is mine:
>
>$ gcc --version | head -n1
>gcc.exe (x86_64-win32-seh, Built by MinGW-W64 project) 6.1.0
>

For mingw32 I have: gcc.exe (GCC) 5.3.0

For mingw-64 I have: gcc.exe (x86_64-win32-seh, Built by MinGW-W64
project) 6.1.0

Which looks to be "the same" I think.

>
>The interesting part is the thread model (win32) and exception handling
>(seh). Both options must be selected when installing mingw-w64. Other
>options for thread model would be 'posix' and for exception handling
>that would be 'sjlj'. I'm particularly interested in the thread model,
>but I'm also interested in any insight in what exception handling (seh
>or sjlj) we should recommend for end users (although I'm aware that
>FLTK doesn't use exceptions). Any clues?

I believe "seh" is the model that recent MS compilers use, so is what I
selected.
I think "sjlj" is "short jump, long jump" or some such thing, and is
maybe the "older" way or something? Do not really know though!

>(2) Please start a "Windows Explorer" Window and cd to your build/bin
>and/or build/bin/examples folder(s), resp. Can you start the Windows
>exe's by clicking on the resp. .exe files in the explorer window:
>
>(a) bin/fluid
>(b) bin/examples/demo and others, particularly:
>(c) bin/glpuzzle and
>(d) bin/threads ?
>

Well, that was interesting.

All work fine from the shell, in both mingw32 and mingw-64 builds,
whether built via configure or cmake. (4 cases tested.)

However, when double-clicking the exe from Explorer, they all work
*except* for the cmake builds of the threads examples.
These fail as follows:

cmake/mingw32 threads fails - pthreadGC-3.dll missing

cmake/mingw-64 - libwinpthread-1.dll missing

So both look to be trying to use win-pthreads rather than native Windows
threads. The configure based builds are fine however.

>
> (3) How did you configure your CMake build, which options did you
>enter on the command line, which options did you change elsewhere
>(cmake-gui)?

I use the cli cmake -G "Msys Makefiles", then once that completes I use
cmake-gui to update the config to add in -static-libstdc++
-static-libgcc to the linker settings.

It's not a very sophisticated approach, but so far it (mostly!) works.

>
>(4) Can you please run cmake with this command line and report if this
>works for you?
>
>$ cmake -G"Unix Makefiles" -DCMAKE_EXE_LINKER_FLAGS='-static-libgcc
>-static-libstdc++' -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_THREADS=OFF
><path/to/fltk>

Will do - I'll report back later though, can't get to it right now.

>
>This is my latest command line to build FLTK with mingw-w64 (gcc 6.1.0)
>as shown above, after modifying the PATH in the same way you described.
>
>FWI: echo $PATH
>/c/mingw-w64_win32/bin:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32
>
>I'm always trying to use the _minimal_ PATH I can find for development.
>
>
>Side note: -DOPTION_USE_THREADS=OFF was used intentionally (threads.exe
>still works with Windows Threads). If I don't use this (OFF), then
>CMake obviously finds pthreads in my mingw and/or mingw-w64 environment
>and links with -pthread which leads to threads.exe depending on
>winpthread.dll or similar.

Yes, looks like I'm seeing something similar above.

[Albrecht Schlosser]

On 06.12.2016 19:07 Ian wrote:
>
> On 06/12/2016 14:40:53, "Albrecht Schlosser" wrote:
>
>> Still investigating... Meanwhile I made a little more progress, but I
>> have a few questions:
>>
>> (1) Please post your gcc version. This is mine:
>>
>> $ gcc --version | head -n1
>> gcc.exe (x86_64-win32-seh, Built by MinGW-W64 project) 6.1.0
>>
> For mingw32 I have: gcc.exe (GCC) 5.3.0
>
> For mingw-64 I have: gcc.exe (x86_64-win32-seh, Built by MinGW-W64
> project) 6.1.0
>
> Which looks to be "the same" I think.

Yep, so do I. I had 'posix' threading installed before, but that didn't
work since I couldn't get rid of the pthreads dependency even if I
didn't use threads. Seems to be built into the compiler/runtime system.
See below.

>> The interesting part is the thread model (win32) and exception
>> handling (seh). Both options must be selected when installing
>> mingw-w64. Other options for thread model would be 'posix' and for
>> exception handling that would be 'sjlj'. I'm particularly interested
>> in the thread model, but I'm also interested in any insight in what
>> exception handling (seh or sjlj) we should recommend for end users
>> (although I'm aware that FLTK doesn't use exceptions). Any clues?
>
> I believe "seh" is the model that recent MS compilers use, so is what I
> selected.
> I think "sjlj" is "short jump, long jump" or some such thing, and is
> maybe the "older" way or something? Do not really know though!

That's what I seem to remember as well. AFAICT sjlj == setjmp, longjmp,
the way resolve exceptions.

>> (2) Please start a "Windows Explorer" Window and cd to your build/bin
>> and/or build/bin/examples folder(s), resp. Can you start the Windows
>> exe's by clicking on the resp. .exe files in the explorer window:
>>
>> (a) bin/fluid
>> (b) bin/examples/demo and others, particularly:
>> (c) bin/glpuzzle and
>> (d) bin/threads ?
>>
> Well, that was interesting.
>
> All work fine from the shell, in both mingw32 and mingw-64 builds,
> whether built via configure or cmake. (4 cases tested.)

Yep, that was to be expected.

> However, when double-clicking the exe from Explorer, they all work
> *except* for the cmake builds of the threads examples.
> These fail as follows:
>
> cmake/mingw32 threads fails - pthreadGC-3.dll missing
>
> cmake/mingw-64 - libwinpthread-1.dll missing

Same here.

> So both look to be trying to use win-pthreads rather than native Windows
> threads. The configure based builds are fine however.

Exactly, that's what I found out and was working on meanwhile. I fixed
the CMake build (WRT pthreads) in svn r12138. configure explicitly did
not check for pthreads under Windows except when Cygwin
(--enable-cygwin) is used. I did it similar in CMake now.

BTW (OT): I think that 'configure --enable-cygwin' is obsolete, i.e. it
should be the default for Cygwin builds (as well as --enable-x11). This
is the only combination that works with "real" Cygwin builds for some
time (several months, maybe years). The previous -mno-cygwin compiler
switch has been removed since gcc 4.0 and building native Windows
executables works with the MinGW cross compiler tools anyway. Hence
there's no need to have such an option. Either build a Cygwin program
(with cygwin1.dll and X11) or cross-compile a native (GDI) program. We
don't have a third option (Cygwin with GDI) for years now. But that's
another story.

>> (3) How did you configure your CMake build, which options did you
>> enter on the command line, which options did you change elsewhere
>> (cmake-gui)?
> I use the cli cmake -G "Msys Makefiles", then once that completes I use
> cmake-gui to update the config to add in -static-libstdc++
> -static-libgcc to the linker settings.
>
> It's not a very sophisticated approach, but so far it (mostly!) works.

Yep, that should do it. See below for a command line option w/o
cmake-gui. So far I couldn't find a difference between "Msys Makefiles"
and "Unix Makefiles".

My plans are to make the linker flags '-static-libstdc++ -static-libgcc'
the default for MinGW builds. We might add an option to switch them off,
but that would hopefully not be necessary. If we had this new default,
running CMake with all defaults should produce native (redistributable)
Windows programs, which is (AFAICT) what most users building with MinGW
would expect. Thoughts?

>> (4) Can you please run cmake with this command line and report if this
>> works for you?
>>
>> $ cmake -G"Unix Makefiles" -DCMAKE_EXE_LINKER_FLAGS='-static-libgcc
>> -static-libstdc++' -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_THREADS=OFF
>> <path/to/fltk>
> Will do - I'll report back later though, can't get to it right now.

Okay, that would still be interesting, but with the latest svn (r 12138)
'-DOPTION_USE_THREADS=OFF' should no longer be necessary. :-)

-DCMAKE_BUILD_TYPE=Debug is optional anyway, but adds some compiler
flags for debugging, so I recommend to use it.

>> This is my latest command line to build FLTK with mingw-w64 (gcc
>> 6.1.0) as shown above, after modifying the PATH in the same way you
>> described.
>>
>> FWI: echo $PATH
>> /c/mingw-w64_win32/bin:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32
>>
>> I'm always trying to use the _minimal_ PATH I can find for development.
>>
>>
>> Side note: -DOPTION_USE_THREADS=OFF was used intentionally
>> (threads.exe still works with Windows Threads). If I don't use this
>> (OFF), then CMake obviously finds pthreads in my mingw and/or
>> mingw-w64 environment and links with -pthread which leads to
>> threads.exe depending on winpthread.dll or similar.

> Yes, looks like I'm seeing something similar above.

Should be fixed with r12138.

[Ian]

On 06/12/2016 19:50:05, "Albrecht Schlosser" wrote:
>That's what I seem to remember as well. AFAICT sjlj == setjmp, longjmp,
>the way resolve exceptions.

Yes! That! That's what I meant!

>
>BTW (OT): I think that 'configure --enable-cygwin' is obsolete, i.e. it
>should be the default for Cygwin builds (as well as --enable-x11). This
>is the only combination that works with "real" Cygwin builds for some
>time (several months, maybe years). The previous -mno-cygwin compiler
>switch has been removed since gcc 4.0 and building native Windows
>executables works with the MinGW cross compiler tools anyway. Hence
>there's no need to have such an option. Either build a Cygwin program
>(with cygwin1.dll and X11) or cross-compile a native (GDI) program. We
>don't have a third option (Cygwin with GDI) for years now. But that's
>another story.

Agree.

>
>My plans are to make the linker flags '-static-libstdc++
>-static-libgcc' the default for MinGW builds. We might add an option to
>switch them off, but that would hopefully not be necessary. If we had
>this new default, running CMake with all defaults should produce native
>(redistributable) Windows programs, which is (AFAICT) what most users
>building with MinGW would expect. Thoughts?

My experience, with people using mingw on Windows, is that *everybody*
gets caught out by the '-static-libstdc++ -static-libgcc', so we should
make it the default. And provide the mean to suppress it for folk who
actually know what they are doing.

>>>
>>>(4) Can you please run cmake with this command line and report if
>>>this
>>>works for you?
>>>
>>>$ cmake -G"Unix Makefiles" -DCMAKE_EXE_LINKER_FLAGS='-static-libgcc
>>>-static-libstdc++' -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_THREADS=OFF
>>><path/to/fltk>
>>Will do - I'll report back later though, can't get to it right now.
>>
>Okay, that would still be interesting, but with the latest svn (r
>12138) '-DOPTION_USE_THREADS=OFF' should no longer be necessary. :-)

OK; tested this "twice" - once with the checkout that I had (the changed
worked to correct the pthreads issue) then I cleaned out the build, did
an svn update and built it again. This also worked. So that looks good.

>
>Should be fixed with r12138.

Seems to be working.

[Manolo]

On Tuesday, 6 December 2016 20:50:16 UTC+1, Albrecht Schlosser wrote:

My plans are to make the linker flags '-static-libstdc++ -static-libgcc'
the default for MinGW builds. We might add an option to switch them off,
but that would hopefully not be necessary. If we had this new default,
running CMake with all defaults should produce native (redistributable)
Windows programs, which is (AFAICT) what most users building with MinGW
would expect. Thoughts?

This is a must.

[Albrecht Schlosser]

Okay, will do. But please don't hold your breath, I'll be very busy with
(other) work for the next three weeks or so...

[Albrecht Schlosser]

On 06.12.2016 23:41 Ian wrote:

>>>> (4) Can you please run cmake with this command line and report if this
>>>> works for you?
>>>>
>>>> $ cmake -G"Unix Makefiles" -DCMAKE_EXE_LINKER_FLAGS='-static-libgcc
>>>> -static-libstdc++' -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_THREADS=OFF
>>>> <path/to/fltk>
>>> Will do - I'll report back later though, can't get to it right now.
>>>
>> Okay, that would still be interesting, but with the latest svn (r
>> 12138) '-DOPTION_USE_THREADS=OFF' should no longer be necessary. :-)

> OK; tested this "twice" - once with the checkout that I had (the changed
> worked to correct the pthreads issue) then I cleaned out the build, did
> an svn update and built it again. This also worked. So that looks good.

Thanks for testing. I think this issue is fixed.

Remaining issues:

- make '-static-libgcc -static-libstdc++' default for MinGW

- fix CMake header search for MinGW-w64 (subject of this thread)

I'll do that, but don't hold your breath...