Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GTK4 - Windows - Linking problems - GHC 9.0.2 and GHC 9.2.3 #384

Open
mpilgrem opened this issue Jul 2, 2022 · 3 comments
Open

GTK4 - Windows - Linking problems - GHC 9.0.2 and GHC 9.2.3 #384

mpilgrem opened this issue Jul 2, 2022 · 3 comments

Comments

@mpilgrem
Copy link

mpilgrem commented Jul 2, 2022

I think that due to a bug in GHC affecting at least GHC 9.0.2 and GHC 9.2.3 - see https://gitlab.haskell.org/ghc/ghc/-/issues/21111 - GTK4 does not work with gi-gtk on Windows. I think that is because [1] mingw-w64-x86_64-gtk4 (unlike gtk3) requires mingw-w64-x86_64-crt-git-10.0.0.r32.g89bacd2be-1, as a dependency of ffmpeg \ frei0r-plugins \ opencv \ ogre3d \ winpthreads and [2] GHC cannot cope with a change in symbols used by that MSYS2 package.

Building results in errors like:

Linking .stack-work\dist\8a54c84f\build\gtkTest\gtkTest.exe ...
C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/ld.exe: C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_app_type[.refptr.mingw_app_type]+0x0): undefined reference to `mingw_app_type'
C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/ld.exe: C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initcharmax[.refptr.mingw_initcharmax]+0x0): undefined reference to `mingw_initcharmax'
C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/ld.exe: C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltssuo_force[.refptr.mingw_initltssuo_force]+0x0): undefined reference to `mingw_initltssuo_force'
C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/ld.exe: C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdyn_force[.refptr.mingw_initltsdyn_force]+0x0): undefined reference to `mingw_initltsdyn_force'
C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/ld.exe: C://Users//mike//AppData//Local//Programs//stack//x86_64-windows//ghc-9.2.3//mingw//bin/../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdrot_force[.refptr.mingw_initltsdrot_force]+0x0): undefined reference to `mingw_initltsdrot_force'
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
@garetxe
Copy link
Collaborator

garetxe commented Jul 2, 2022

Thanks for the report!

From reading the bug reports you link to I think I see why the issue arose, but I don't quite see how to work around this in gi-gtk itself. Just for curiosity, does the workaround mentioned in https://gitlab.haskell.org/ghc/ghc/-/issues/21111#note_418314 fix things for you?

I don't have easy access to a Windows machine at the moment, but I should get one in a week or two, so I can try to take a more careful look then. But if in the interim you have any suggestions for workarounds that we could add in gi-gtk / haskell-gi I would be happy to do so!

@mpilgrem
Copy link
Author

mpilgrem commented Jul 2, 2022

I suspect there is no fix in gi-gtk. I published the issue here because I thought it might help other Windows users who experienced it to understand the likely cause. I am a stack user and finding the work-around a little difficult to interpret.

@mpilgrem
Copy link
Author

I did have success with GTK4 on Windows 11 with Stack and GHC-9.4.1-alpha3 (which comes with base-4.17.0.0). In case it helps other Windows users, this is what I did:

I used stack exec -- pacman -S mingw-w64-x86_64-gtksourceview5 to install the GTK4 libraries into the Stack-supplied MSYS2.

There is no Stackage resolver yet for GHC 9.4.1 (it is in alpha). So, I created a my-stack-setup.yaml to be used to download and install GHC-9.4.1-alpha3 for use by Stack, namely:

ghc:
  windows64:
    9.4.1:
      url: "https://downloads.haskell.org/ghc/9.4.1-alpha3/ghc-9.4.0.20220623-x86_64-unknown-mingw32.tar.xz"
      content-length: 281104480

sevenzexe-info:
  url: "https://github.com/fpco/minghc/blob/master/bin/7z.exe?raw=true"
  content-length: 73728
  sha1: 187dff8a3327da87050f678579816e5bae40c632

sevenzdll-info:
  url: "https://github.com/fpco/minghc/blob/master/bin/7z.dll?raw=true"
  content-length: 447488
  sha1: 168a288d4456f0473f66e86a2d6fec4eb6f4b993

I then used the stack --setup-info-yaml=my-stack-setup.yaml ... option to trigger the download and installation. This option only needs to be used once.

I used the following package.yaml (I discovered that vector-algorithms needs vector < 0.13 - see erikd/vector-algorithms#38):

name:                gtkTest
version:             0.1.0.0

dependencies:
- base >= 4.17 && < 5
- gi-gtk >= 4
- haskell-gi-base
- vector < 0.13

executables:
  gtkTest:
    main:                Main.hs
    source-dirs:         app
    ghc-options:
    - -threaded
    - -rtsopts
    - -with-rtsopts=-N

I used the following stack.yaml (I discovered that I needed allow-newer: true):

resolver: ghc-9.4.1
packages:
- .
allow-newer: true
extra-deps:
- ansi-terminal-0.11.3
- async-2.2.4
- attoparsec-0.14.4
- blaze-builder-0.4.2.2
- blaze-html-0.9.1.2
- blaze-markup-0.8.2.8
- cabal-doctest-1.0.9
- colour-2.3.6
- conduit-1.3.4.2
- conduit-extra-1.3.6
- data-default-class-0.1.2.0
- gi-atk-2.0.24
- gi-cairo-1.0.26
- gi-freetype2-2.0.1
- gi-gdk-4.0.4
- gi-gdkpixbuf-2.0.28
- gi-gio-2.0.29
- gi-glib-2.0.26
- gi-gmodule-2.0.2
- gi-gobject-2.0.27
- gi-graphene-1.0.4
- gi-gsk-4.0.4
- gi-gtk-4.0.5
- gi-harfbuzz-0.0.6
- gi-pango-1.0.26
- happy-1.20.0
- hashable-1.4.0.2
- haskell-gi-0.26.0
- haskell-gi-base-0.26.0
- haskell-gi-overloading-1.0
- haskell-lexer-1.1
- integer-logarithms-1.0.3.1
- mintty-0.1.4
- mono-traversable-1.0.15.3
- network-3.1.2.7
- pretty-show-1.10
- primitive-0.7.4.0
- random-1.2.1.1
- regex-base-0.94.0.2
- regex-tdfa-1.3.1.3
- resourcet-1.2.6
- safe-0.3.19
- scientific-0.3.7.0
- split-0.2.3.4
- splitmix-0.1.0.4
- streaming-commons-0.2.2.4
- typed-process-0.2.10.1
- unliftio-core-0.2.0.1
- unordered-containers-0.2.19.1
- vector-0.12.3.1
- vector-algorithms-0.8.0.4
- vector-stream-0.1.0.0
- xdg-basedir-0.2.2
- xml-conduit-1.9.1.1
- xml-types-0.3.8
- zlib-0.6.3.0

This was my source code in Main.hs:

{-# LANGUAGE LexicalNegation   #-}
{-# LANGUAGE OverloadedLabels  #-}
{-# LANGUAGE OverloadedStrings #-}

import           Data.GI.Base  (AttrOp ((:=)), new, on, set)
import qualified GI.Gtk        as Gtk

import           Control.Monad (void)

main :: IO ()
main = do
  app <- new Gtk.Application []
  on app #activate (activate app)
  void $ #run app Nothing

activate :: Gtk.Application -> IO ()
activate app = do
  win <- new Gtk.Window [ #title := "Hi there" ]
  button <- new Gtk.Button [ #label := "Click me" ]
  on button #clicked (set button [ #sensitive := False,
                                   #label := "Thanks for clicking me" ])
  #setChild win (Just button)
  #setDefaultSize win 400 -1
  #show win
  #addWindow app win

I then commanded stack build --flag mintty:-win32-2-13-1 (I discovered that allow-newer caused Stack to force Win32 to be a version before 2.13.1. mintty needs to be told expressly that has happened), which yielded (extract):

Stack has not been tested with GHC versions above 9.0, and using 9.4.1, this may fail
Stack has not been tested with Cabal versions above 3.4, but version 3.8.0.20220526 was found, this may fail
Building all executables for `gtkTest' once. After a successful build of all of them, only specified executables will be rebuilt.
gtkTest> configure (exe)
Configuring gtkTest-0.1.0.0...
gtkTest> build (exe)
Preprocessing executable 'gtkTest' for gtkTest-0.1.0.0..
Building executable 'gtkTest' for gtkTest-0.1.0.0..
[1 of 3] Compiling Main
[2 of 3] Compiling Paths_gtkTest
[3 of 3] Linking .stack-work\\dist\\0ef4d674\\build\\gtkTest\\gtkTest.exe

Warning: Failed to decode module interface:
         C:\Users\mikep\Documents\Code\Haskell\gtkTest\.stack-work\dist\0ef4d674\build\gtkTest\gtkTest-tmp\Paths_gtkTest.hi
         Decoding failure: not enough bytes

Warning: Failed to decode module interface:
         C:\Users\mikep\Documents\Code\Haskell\gtkTest\.stack-work\dist\0ef4d674\build\gtkTest\gtkTest-tmp\Main.hi
         Decoding failure: not enough bytes
gtkTest> copy/register
Installing executable gtkTest in C:\Users\mikep\Documents\Code\Haskell\gtkTest\.stack-work\install\9c220015\bin

For some reason C:\Users\mikep\Documents\Code\Haskell\gtkTest\.stack-work\install\9c220015\bin was not in the stack exec environment's PATH (that seems to be a Stack bug; stack also struggled with decoding module interfaces with GHC 9.4.1, as above). However, using the express path to the executable in the stack exec environment :

stack exec -- C:\Users\mikep\Documents\Code\Haskell\gtkTest\.stack-work\install\9c220015\bin\gtkTest

resulted in the gtkTest application window appearing and behaving as expected.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants