| |
| |
On 11/16/22 16:52 Ian MacArthur wrote:
On Wednesday, 16 November
2022 at 15:36:19 UTC Albrecht Schlosser wrote:
You seem to miss `mingw32-make`. Please try this command
(output from my system):
$ mingw32-make --version
GNU Make 4.3
Built for Windows32
...
I've generally found "MSYS Makefiles" to be fine with
MSYS2/mingw64, so worth trying that first...
Yes, that's another option. But recently I found "MinGW Makefiles"
to work more reliably (with MSYS2 on my installation) and I used
that for a while. Now I tried one of the other generators (including
Ninja) and it worked fine - surprisingly.
MSYS2 setup is still a mystery for me. But once you got it working
... never touch a running (ehm, working) system. ;-)
3. CMAKE_EXE_LINKER_FLAGS="-static-libgcc
-static-libstdc++": make sure you don't need these DLL's
My mingw64 builds DO NOT need these set.
Does "mingw64" mean MSYS2/mingw64? If yes I'd be interested to know
how to setup this so we can document it for other users.
My mingw32 builds DO need these set.
I assume this means classic "MinGW" where I made this experience as
well.
I have no idea what is "normal".
Neither do I. Did I already say that it's a mystery? ;-)
Probably does no harm to have these settings enabled
though?
Yes, I think so. It should be safe even if it's not needed. Unless
you are working with a very old system that doesn't have
these options.
4. Remaining issue: unfortunately the build (still) depends
on `libwinpthread-1.dll =>
/mingw64/bin/libwinpthread-1.dll` as output by `ldd`
Point 4 is something I need to investigate because it makes
the executables depend on this DLL. You can either run the
programs from your MSYS shell or copy the DLL to the binary
directory side by side with the executables if you want to
run these programs under pure Windows.
That's linked against winpthread rather than using Win32
native threads?
That's.... unexpected... and not what we would want.
Is it a mis-setting in the config? Or the wrong version of
the mingw64 tools?
Weird...
That's exactly what I would like to know. I always get these
dependencies when I use MSYS2/mingw64. Maybe I did something wrong
when I installed it, maybe too many packages where one of those
makes the build depend on that DLL? I dunno.
However, after a quick web search I found out how I can avoid the
DLL dependency by adding "-static" to the build. Since I want to
link statically anyway it doesn't matter and it doesn't seem to
affect the output. The resulting programs work fine when I run them
from an explorer window and I can't see any dependencies on
non-Windows DLL's with `ldd`.
Whether this uses the "wrong" threading library/features I can't
tell. I think we're still using Windows threading in FLTK and that
should make it work correctly. Why the dependency is created in the
first place when linking with MSYS2 on my system ... is still a
mystery.
Anyway, here is what I found to work w/o dependencies on non-Windows
(i.e. MSYS2) dll's:
$ cmake -G Ninja -D CMAKE_BUILD_TYPE=Debug \
-D OPTION_USE_SYSTEM_LIBJPEG:BOOL=OFF -D OPTION_USE_SYSTEM_LIBPNG:BOOL=OFF \
-D OPTION_USE_SYSTEM_ZLIB:BOOL=OFF \
-D CMAKE_EXE_LINKER_FLAGS='-static-libgcc -static-libstdc++ -static' \
../..
Note the added "-static" flag to CMAKE_EXE_LINKER_FLAGS
. That's all I needed to change.
As far as I can tell the build is not affected except for removing
the unwanted dependency. However it would be another problem if you
wanted to link with the shared FLTK libs (dll's) but that's
off-topic for now.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/477b7fe1-98ac-584e-258f-164d560a3d0d%40online.de.
[ Direct Link to Message ] | |
|
| |
