Cross-compiling from Ubuntu/mingw to Windows 10 needs X11 ?

[Julien Vernay]

Hello,

I am trying to cross-compile the FTLK library from a Ubuntu system to Windows 10. I am using Windows Subsystem for Linux (with Ubuntu 18.04). Mingw-w64 is installed on the Ubuntu system (with apt-get). I have configured CXX and CC environment variables to use mingw compiler.

When I try ./configure, I get "error: Configure could not find required X11 libraries, aborting." .

But X11 is for Unix system, for what I could find on Internet. So it should'nt be needed for Windows ? Moreover, I couldn't find any X11 built library for mingw.

I already managed to install SDL with built libraries, and to cross-compile Emscripten from source. So I was wondering if I configure badly the library ?

Thanks for any answer :)

[Albrecht Schlosser]

On 27.08.2018 14:14 Julien Vernay wrote:
>
> I am trying to cross-compile the FTLK library from a Ubuntu system to
> Windows 10. I am using Windows Subsystem for Linux (with Ubuntu 18.04).
> Mingw-w64 is installed on the Ubuntu system (with apt-get). I have
> configured CXX and CC environment variables to use mingw compiler.

Why do you want to cross-compile under Windows using Linux? Building
FLTK under Windows with mingw-w64 (installed directly under Windows)
works pretty straightforward.

> When I try ./configure, I get *"error: Configure could not find required
> X11 libraries, aborting." *.

>
> But X11 is for Unix system, for what I could find on Internet. So it
> should'nt be needed for Windows ? Moreover, I couldn't find any X11
> built library for mingw.

Yes, X11 is for Linux or Unix (or Cygwin under Windows, if you like).

> I already managed to install SDL with built libraries, and to
> cross-compile Emscripten from source. So I was wondering if I configure
> badly the library ?

You need to tell configure if you want to cross compile, there are extra
options --target, --host, and --build. I think --target is the key here,
and you need to use platform "triplets" to specify the target platform.

I'm short of time now, so I hope this helps you going. Maybe someone
else can help with more details.

That said, building for Windows under Windows is a lot of easier if you
use MinGW or MinGW-w64 directly...

[Albrecht Schlosser]

On 27.08.2018 16:30 Albrecht Schlosser wrote:
> On 27.08.2018 14:14 Julien Vernay wrote:
>>
>> I am trying to cross-compile the FTLK library from a Ubuntu system to
>> Windows 10. I am using Windows Subsystem for Linux (with Ubuntu
>> 18.04). Mingw-w64 is installed on the Ubuntu system (with apt-get). I
>> have configured CXX and CC environment variables to use mingw compiler.
>

>> When I try ./configure, I get *"error: Configure could not find
>> required X11 libraries, aborting." *.
>

> You need to tell configure if you want to cross compile, there are extra
> options --target, --host, and --build. I think --target is the key here,
> and you need to use platform "triplets" to specify the target platform.

FYI: I just managed to build FLTK (1.4.0) and many example programs (all
demo programs that don't use fluid) on my Ubuntu 14.04 system in a
Virtualbox VM under Windows 10 and I could execute the built programs
under Windows 10. I used configure and make with these commands:

$ make clean
$ LDFLAGS='-static-libgcc -static-libstdc++' ./configure
--host=x86_64-w64-mingw32
$ make -k
$ cp fluid/*.exe test/*.exe /path/to/win10/
$ cp /usr/x86_64-w64-mingw32/lib/libwinpthread-1.dll /path/to/win10/

This configuration builds fluid but can obviously not use this fluid.exe
to generate the sources from all test/*.fl files (you need a native
fluid program to do that). Since this was only for a test I ignored this
fact...

Notes:

(1) `make clean' does "nothing", but generates ./configure and some
essential files

(2) LDFLAGS='...' links statically with some system libs

(3) '--host=x86_64-w64-mingw32' is the host triplet of my installed
cross compiler for windows. You may want to use another config

(4) I used 'make -k' to ignore errors when fluid was used (see above)

(5) I copied *.exe to a shared file system (/path/to/win10/)

(6) I also copied the missing file libwinpthread-1.dll to this shared
file system

Now I could run the built FLTK programs on /path/to/win10/ from the
Windows 10 system (using explorer to run the executables).

So this is how it can *basically* work. YMMV, you may need to tweak the
host triplet and some other options. The missing dll can maybe be
avoided but I can't help with this right now.

I don't know if it is possible to tweak configure to use a native fluid
to build the test files. Maybe the cross-compiled fluid in your
configuration can work because you're running under Windows?

Anyway, I hope this is of any value for you and others and helps you to
get your build of FLTK going. Feedback welcome...

[Julien Vernay]

> (3) '--host=x86_64-w64-mingw32' is the host triplet of my installed
> cross compiler for windows. You may want to use another config

It was what I needed, thank you :)

> (6) I also copied the missing file libwinpthread-1.dll to this shared
> file system

After building the tests, it seems I don't need it, but thank you anyway !

[Julien Vernay]

Thanks for your answer ! TL;DR : it works !

> Why do you want to cross-compile under Windows using Linux? Building
> FLTK under Windows with mingw-w64 (installed directly under Windows)
> works pretty straightforward.

I am more confident in bash than powershell. Moreover, between MinGW/MSYS,

and an official supported bash (WSL), I prefer the latter.

> You need to tell configure if you want to cross compile, there are extra

> options --target, --host, and --build. I think --target is the key here,
> and you need to use platform "triplets" to specify the target platform.

After searching what were platform triplets, I found what I needed, thanks :)

The correct command is ./configure --host=x86_64-w64-mingw32

[imm]

On Mon, 27 Aug 2018 at 16:33, Albrecht Schlosser wrote:
>
> (6) I also copied the missing file libwinpthread-1.dll to this shared
> file system

Hi Albrecht,

This last step seems a bit... odd...? I don't think we'd normally
expect a mingw build to depend on pthreads, would we?

When I do a "native" mingw build on WinXX, it always picks the native
thread model not pthreads,which seems like the *right* thing to do.

I assume your regular WinXX hosted mingw builds are not using pthreads?

Cheers,
--
Ian

[imm]

On Mon, 27 Aug 2018 at 17:40, Julien Vernay wrote:
>
> I am more confident in bash than powershell. Moreover, between MinGW/MSYS,
> and an official supported bash (WSL), I prefer the latter.

I don't think *anyone* actually uses powershell, do they?

FWIW, I've been using Msys as my main shell on WinXX machines for many
years now, and it is an *adequate* ba(sh) for most purposes, and
(arguably) better integrated with my normal tool chain than WSL is.

And, being pedantic, ISTR that the "bash" that Ubuntu ship isn't
actually bash either, it's, um... well, I dunno; maybe it is bash...

[Albrecht Schlosser]

On 27.08.2018 22:13 imm wrote:
> On Mon, 27 Aug 2018 at 16:33, Albrecht Schlosser wrote:
>>
>> (6) I also copied the missing file libwinpthread-1.dll to this shared
>> file system
>
> Hi Albrecht,
>
> This last step seems a bit... odd...? I don't think we'd normally
> expect a mingw build to depend on pthreads, would we?

Hi Ian,

when I saw this dependency I remembered that I had such issues with
different compiler (gcc) "features" (configurations) when I experimented
with MinGW-w64. IIRC you had to select the *right* compiler
option/version/build to get the exception and threads model you wanted.
ISTR that it is a gcc built-in issue so the compiled programs require
this dll. I didn't have time to investigate and wanted to make it short
so I copied the dll and it worked for me.

I described the case only as a starting point, and I consider this as a
workaround a proof of concept. I'll try to investigate this on one of my
newer VM's when time permits. It's always good to know that (and how)
you can cross-compile FLTK on Linux.

> When I do a "native" mingw build on WinXX, it always picks the native
> thread model not pthreads,which seems like the *right* thing to do.

I never had the above issue with native (32-bit) MinGW tool chains as well.

> I assume your regular WinXX hosted mingw builds are not using pthreads?

Sure.

[Ian MacArthur]

> On 28 Aug 2018, at 08:34, Albrecht Schlosser wrote:
>
>> This last step seems a bit... odd...? I don't think we'd normally
>> expect a mingw build to depend on pthreads, would we?
>
> Hi Ian,
>
> when I saw this dependency I remembered that I had such issues with different compiler (gcc) "features" (configurations) when I experimented with MinGW-w64. IIRC you had to select the *right* compiler option/version/build to get the exception and threads model you wanted. ISTR that it is a gcc built-in issue so the compiled programs require this dll. I didn't have time to investigate and wanted to make it short so I copied the dll and it worked for me.

Ah - OK; yes, I remember now that some of the mingw64 ports offer different compilation-mode variants, i.e. different exception handling conventions and, as in this case, different threading models.

I’ve generally contrived to pick a mingw64 variant that uses native Win32 threads, and the same exception model as the MS tools use, so in practice I’ve not seen the pthreads dependency that you hit here, but I now comprehend why it could happen!

Checking: The mingw64 on the Windows VM on this Mac seems to be called "x86_64-6.3.0-win32-seh-rt_v5-rev1" - I guess that says it is gcc-6.3.0 for x86-64, with Win32 threads and SEH exception handling? I dunno...



FWIW (and this is not a recommendation, just an observation) I’ve used the TDM port of mingw64 for a few things (though not this machine, as noted above!)
It seems to be OK, and seems *not* to offer the confusing range of choices I’ve seen with other mingw64 offerings (i.e. it defaults to native threads and so forth.)

It also doesn’t appear to need the LDFLAGS='-static-libgcc -static-libstdc++’ workaround - I guess they changed the defaults for that internally or something, as code compiled without explicitly setting the static libs options still “works right”.

Though, TBH, I’ve used a few different mingw64 ports now, and they all seem to work well, for the most part!

>
> I described the case only as a starting point, and I consider this as a workaround a proof of concept. I'll try to investigate this on one of my newer VM's when time permits. It's always good to know that (and how) you can cross-compile FLTK on Linux.

The Cmake build ought to be able to do a cross-compile too; indeed it might be better able to do so than our autoconf build - though I think that recent iterations of our autoconf build do handle the cross-targeting OK now (that has not always been the case, IIRC.)

That said, although I’ve seen it discussed, I don’t recall *ever* doing a cross-compile via cmake (and I do a lot of cross-compilation in my day job... we don’t use cmake for those builds though!)

[Albrecht Schlosser]

On 28.08.2018 16:23 Ian MacArthur wrote:
>
>> On 28 Aug 2018, at 08:34, Albrecht Schlosser wrote:

[Note: replying only to a part of your mail (time constraints)]

>>
>> I described the case only as a starting point, and I consider this as a workaround a proof of concept. I'll try to investigate this on one of my newer VM's when time permits. It's always good to know that (and how) you can cross-compile FLTK on Linux.
>
> The Cmake build ought to be able to do a cross-compile too; indeed it might be better able to do so than our autoconf build - though I think that recent iterations of our autoconf build do handle the cross-targeting OK now (that has not always been the case, IIRC.)

I /did/ successfully "cross-compile" with autoconf on windows, using
Cygwin with their MinGW-w64 based cross compilers to build "native"
Windows apps, at least since 1.3.x (don't know 'x').

I also cross-compiled on Linux with CMake, building native Windows apps
(both 32-bit and 64-bit).

> That said, although I’ve seen it discussed, I don’t recall *ever* doing a cross-compile via cmake (and I do a lot of cross-compilation in my day job... we don’t use cmake for those builds though!)

Notes:

As I reported in this thread, the 'fluid.exe' built with autogen could
not be used to generate the .cxx and .h files from test/*.fl. The
generated fluid is the cross-compiled (Windows) program and runs
perfectly under Windows.

OTOH: our CMake build requires a native (for the build host) fluid
executable somewhere and uses it to generate the .cxx and .h source
files *but* it doesn not build a cross-targeted 'fluid.exe'. So,
although the CMake cross build works well, there is no fluid.exe for the
target system (Windows). This is a known issue and I'd like to fix it in
the future.

[Daniel G.]

I just want to add my experience here. I use following receipe to cross compile fltk using mingw on an dabian stretch machine:

https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/master/entry/_template/packages/fltk/Makefile

From my experience using pthreads instead of windows native threads can make life much easier in cross platform development when fiddeling aroun with other libraries aswell.
MinGW allows static linking of pthreads using "-static -lpthread".

I have read that some of you have problems with fluid.exe while cross compiling. You can overcome this problem using wine (At least on debian. I mentiont that here: https://projects.nwrk.biz/projects/c-projektvorlage/wiki/Entwicklerhandbuch)

Install and configure wine:

$ sudo apt install -y wine wine32 wine64 libwine libwine:i386 fonts-wine wine-binfmt

$ sudo update-binfmts --import /usr/share/binfmts/wine

This should allow you a full cross  compiled build.

Hope this helps,

giri