Skip to content
Snippets Groups Projects

No working gcc with 7.10.3 on Windows

    • Open Issue created by Jaro Reinders @jaro

    Main problem

    After installing and switching to GHC 7.10.3 on Windows I get the following message when trying to compile the package OpenGLRaw:

    Configuring library for OpenGLRaw-3.3.4.1..
cabal-3.6.2.0.exe: No working gcc
This package depends on foreign library but we cannot find a working C
compiler. If you have it in a non-standard location you can use the --with-gcc
flag to specify it.

    I also noticed a message about missing the 'ar' program with another package.

    Attempted fix

    I tried opening a msys mingw shell and installing the mingw-w64-x86_64-gcc and mingw-w64-x86_64-binutils packages, but then I get messages like this (also with other GHC versions):

    C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: In function `pre_c_init':
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:133: undefined reference to `_encode_pointer'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: In function `__tmainCRTStartup':
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:283: undefined reference to `__mingw_init_ehandler'
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:183: undefined reference to `__security_init_cookie'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: In function `mainCRTStartup':
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:211: undefined reference to `__security_init_cookie'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.__onexitbegin[.refptr.__onexitbegin]+0x0): undefined reference to `__onexitbegin'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.__onexitend[.refptr.__onexitend]+0x0): undefined reference to `__onexitend'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_app_type[.refptr.mingw_app_type]+0x0): undefined reference to `mingw_app_type'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initcharmax[.refptr.mingw_initcharmax]+0x0): undefined reference to `mingw_initcharmax'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdyn_force[.refptr.mingw_initltsdyn_force]+0x0): undefined reference to `mingw_initltsdyn_force'
C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdrot_force[.refptr.mingw_initltsdrot_force]+0x0): undefined reference to `mingw_initltsdrot_force'
    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Jaro Reinders changed title from No working gcc with 7.10.3 to No working gcc with 7.10.3 on Windows

      changed title from No working gcc with 7.10.3 to No working gcc with 7.10.3 on Windows

    • Jaro Reinders changed the description

      changed the description

    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      Hi, just in case i tried with a newer version of ghc (well it is pretty old too :-P) and it works for me with this versions:

      user@system MSYS /d/ws/haskell/OpenGLRaw-3.3.4.1
# ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5

user@system MSYS /d/ws/haskell/OpenGLRaw-3.3.4.1
# pacman -Q base-devel
base-devel 2022.01-1

user@system MSYS /d/ws/haskell/OpenGLRaw-3.3.4.1
# pacman -Q gcc
gcc 11.2.0-3

user@system MSYS /d/ws/haskell/OpenGLRaw-3.3.4.1
# pacman -Q msys2-runtime-devel
msys2-runtime-devel 3.3.3-7

      also with other GHC versions

      which is the not working newer version?

      I've observed the posted errors mention ghc-8.6.5 and no 7.10.3:

      C:/ghcup/ghc/8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: In function `pre_c_init':
      Edited by Javier Neira
    • Jaro Reinders
      Jaro Reinders @jaro ·
      Author Contributor

      I've observed the posted errors mention ghc-8.6.5 and no 7.10.3:

      Yeah, that is the other GHC version I meant. But note that this is not my main problem. This is just a problem caused by me trying to fix it myself by intalling mingw-w64-x86_64-gcc and mingw-w64-x86_64-binutils manually.

      Edited by Jaro Reinders
    • Jaro Reinders changed the description

      changed the description

    • Julian Ospald added scopewindows label

      added scopewindows label

    • Julian Ospald added typesupport label

      added typesupport label

    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      I can reproduce, it even does not build the fixeddependency:

      D:\ws\haskell\OpenGLRaw-3.3.4.1>cabal build -w ghc-7.10.3
Build profile: -w ghc-7.10.3 -O1
In order, the following will be built (use -v for more details):
 - fixed-0.3 (lib) (requires build)
 - half-0.3.1 (lib) (requires build)
 - text-1.2.4.1 (lib) (requires build)
 - OpenGLRaw-3.3.4.1 (lib) (first run)
Configuring library for fixed-0.3..
Preprocessing library for fixed-0.3..
Building library for fixed-0.3..
[1 of 1] Compiling Numeric.Fixed    ( src\Numeric\Fixed.hs, dist\build\Numeric\F
ixed.o )
Error: cabal: The program 'ar' is required but it could not be found.

Error: cabal: Failed to build fixed-0.3 (which is required by
OpenGLRaw-3.3.4.1).
    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      It is weird that ghc does not find the mingw installation shipped with the ghc distribution (in my env it is in D:\ghcup\ghc\8.10.7\mingw). That is the location for the appropiate posix programs (ar, gcc, etc) for ghc internal use.

      So an immediate workaround which works for me is:

      D:\ws\haskell\OpenGLRaw-3.3.4.1>cabal build --extra-prog-path=D:\ghcup\ghc\7.10.3\mingw\bin -w ghc-7.10.3
Build profile: -w ghc-7.10.3 -O1
In order, the following will be built (use -v for more details):
 - fixed-0.3 (lib) (requires build)
 - half-0.3.1 (lib) (requires build)
 - text-1.2.4.1 (lib) (requires build)
 - OpenGLRaw-3.3.4.1 (lib) (first run)
Configuring library for fixed-0.3..
Preprocessing library for fixed-0.3..
Building library for fixed-0.3..
[1 of 1] Compiling Numeric.Fixed    ( src\Numeric\Fixed.hs, dist\build\Numeric\Fixed.o )
Installing library in D:\cabal\store\ghc-7.10.3\incoming\new-2948\cabal\store\ghc-7.10.3\fixed-0.3-1887ea1e7c2b7e5c3c8d69291184976f27805a5e\lib
Configuring library for half-0.3.1..

      That works even having

      extra-prog-path: D:\ghcup\bin,
                 D:\cabal\bin,
                 D:\msys64\mingw64\bin,
                 D:\msys64\usr\bin

      in the global cabal config as the cli arg overrides it

    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      I think the use of shims inside D:\ghcup\bincould be the culprit, as using directly the ghc executable inside D:\ghcup\ghc\... works:

      D:\ws\haskell\OpenGLRaw-3.3.4.1>cabal build -w D:\ghcup\ghc\7.10.3\bin\ghc-7.10.3
Resolving dependencies...
Build profile: -w ghc-7.10.3 -O1
In order, the following will be built (use -v for more details):
 - fixed-0.3 (lib) (requires build)
 - half-0.3.1 (lib) (requires build)
 - text-1.2.4.1 (lib) (requires build)
 - OpenGLRaw-3.3.4.1 (lib) (first run)
Configuring library for fixed-0.3..
Preprocessing library for fixed-0.3..
Building library for fixed-0.3..
[1 of 1] Compiling Numeric.Fixed    ( src\Numeric\Fixed.hs, dist\build\Numeric\F
ixed.o )
Installing library in D:\cabal\store\ghc-7.10.3\incoming\new-10896\cabal\store\g
hc-7.10.3\fixed-0.3-1887ea1e7c2b7e5c3c8d69291184976f27805a5e\lib
Configuring library for half-0.3.1..
Preprocessing library for half-0.3.1..
Building library for half-0.3.1..

      It also works for D:\ghcup\ghc\7.10.3\bin\ghc

    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      Well the culprit would not be the use of shims per se, but the location of the executable outside the standard ditribution, combined with the way ghc < 8.0 locates the mingw dir

      Given there is a relatively easy workaround, the fact it is a relatively less used and old ghc version and the fix would be no so easy i think a note in docs could be the way to go.

      Edited by Javier Neira
    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      @Noughtmare

      Given there is a relatively easy workaround, the fact it is a relatively less used and old ghc version and the fix would be no so easy i think a note in docs could be the way to go.

      do you agree or do you think something else could be done in ghcup about?

      also, did the workarounds work for you?

      Edited by Javier Neira
    • Jaro Reinders
      Jaro Reinders @jaro ·
      Author Contributor

      I didn't have time to try it yet. What do you actually suggest as the main workaround? Just using that --extra-prog-path or using the compiler directly instead of the shim?

      I think a post-install message like in #123 (closed) would also be a good idea.

      If that all works, then I'm satisfied with this solution.

      Update: both solutions work for me, thanks! I think I slightly prefer the --extra-prog-path solution.

      Edited by Jaro Reinders
    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      I didn't have time to try it yet. What do you actually suggest as the main workaround? Just using that --extra-prog-path or using the compiler directly instead of the shim?

      Update: both solutions work for me, thanks! I think I slightly prefer the --extra-prog-path solution.

      I would say that use -w will be a little bit more reliable. It is a well known and widely used config option and it is better to not touch the PATH variable. ghc will use its internal mingw in int the aproppiate code points and cabal will be able to use another c toolchain for other programs (like hschs and other ones)

    • Javier Neira
      Javier Neira @jneira ·
      Contributor

      I think a post-install message like in #123 (closed) would also be a good idea.

      It would be a good idea, specially if it possible to use it for that specific combination of windows and ghc-7.10.3

      Edited by Javier Neira
    Please register or sign in to reply