Haikuports: ghc-7.8.3-11 package on x86_gcc2 in haikudepot depends on unavailable lib:libncursesw_x86>=5.9

[ix]

Hi all,

As the title states, the HaikuDepot package ghc-7.8.3-11 for architecture x86_gcc2 has a dependency on lib:libncursesw_x86>=5.9 which it reports as being unavailable. It seems Haiku has moved completely to ncurses 6, the only available version of 5.9 being in haikuports.

Thanks to _Dario_ on IRC, I've determined that manually installing ncurses_x86-5.9-13-x86_gcc2.hpkg resolves the issue, so it seems like having that package available would result in the ghc package working again. I've included some details from steps I took to build 5.9 from haikuports below, just in case they're at all useful.

I attempted to build the haikuports recipe, however this led to a long chain of failures, the first being haikuporter itself bailing out with an error stemming from haikuporter itself relating to the use of raw_input() in python3, then it'd fail because there were no valid architectures, and amending that produced the below:

* Configuration summary for NCURSES 5.9 20110404:

     extended funcs: yes
     xterm terminfo: xterm-new

      bin directory: /packages/ncurses-5.9-13/.self/bin
      lib directory: /packages/ncurses-5.9-13/.self/lib
  include directory: /packages/ncurses-5.9-13/.self/develop/headers
      man directory: /packages/ncurses-5.9-13/.self/documentation/man
 terminfo directory: /packages/ncurses-5.9-13/.self/data/terminfo

** Include-directory is not in a standard location
cd man && make DESTDIR="" all
make[1]: Entering directory '/sources/ncurses-5.9/man'
sh ./MKterminfo.sh ./terminfo.head ./../include/Caps ./terminfo.tail >terminfo.5
Makefile:69: recipe for target 'terminfo.5' failed
make[1]: *** [terminfo.5] Error 99
make[1]: Leaving directory '/sources/ncurses-5.9/man'
Makefile:109: recipe for target 'all' failed
make: *** [all] Error 2

Disabling manpages in the build via editing the configure flags in the recipe produces another error:

** Include-directory is not in a standard location
cd include && make DESTDIR="" all
make[1]: Entering directory '/sources/ncurses-5.9/include'
cat curses.head >curses.h
sh ./MKhashsize.sh ./Caps >hashsize.h
AWK=gawk sh ./MKncurses_def.sh ./ncurses_defs >ncurses_def.h
AWK=gawk sh ./MKparametrized.sh ./Caps >parametrized.h
AWK=gawk sh ./MKkey_defs.sh ./Caps >>curses.h
touch config.h
gawk -f MKterm.h.awk ./Caps > term.h
sh ./edit_cfg.sh ../include/ncurses_cfg.h term.h
** edit: HAVE_TCGETATTR 1
sed: can't read save92613: No such file or directory
./MKkey_defs.sh: line 82: data92597: No such file or directory
cat: pass1_92597: No such file or directory
./MKkey_defs.sh: line 82: data92597: No such file or directory
** edit: HAVE_TERMIOS_H 1
sed: can't read save92613: No such file or directory
./MKkey_defs.sh: line 82: data92597: No such file or directory
./MKkey_defs.sh: line 82: data92597: No such file or directory
cat: pass2_92597: No such file or directory
cat: pass3_92597: No such file or directory
cat: pass4_92597: No such file or directory
** edit: HAVE_TERMIO_H 0
sed: can't read save92613: No such file or directory
Makefile:95: recipe for target 'curses.h' failed
make[1]: *** [curses.h] Error 1
make[1]: *** Waiting for unfinished jobs....
** edit: BROKEN_LINKER 0
sed: can't read save92613: No such file or directory
make[1]: Leaving directory '/sources/ncurses-5.9/include'
Makefile:109: recipe for target 'all' failed
make: *** [all] Error 2

This was the point I gave up at, but it seems like it's trying to reference some temporary build files...

[pulkomandy]

Argh, I thought I had fixed this but apparently I didn't finish it...

The problem with the ghc recipe is that it uses pre-built binaries cross-compiled from Linux. That makes updating it a bit difficult. I have started a new recipe (called ghc78) for a newer version of ghc but of course it requires the older one to build, and also it doesn't include most of haskell tooling (cabal, etc), just the compiler. I think the other tools should be done as separate recipes?

Anyway, the idea at the time was to:

• Temporarily re-enable the ncurses5 recipe
• Use it to install the existing ghc package
• Build the new ghc78 using ncurses6
• Once the ghc78 package is up, completely disable and delete the ncurses5 recipe

I don't know why ncurses5 is broken now. The first problem (no valid architectures) is expected, it's the way we disable recipes we don't want to build. Maybe the easiest way (sadly) is to get the ncurses packages from an older version of Haiku (beta1? is that old enough?) and use these to get the existing ghc package installed. From there it should be possible to build the new ghc78 recipe. I guess we should then manually add that ghc78 recipe in our package builders so we can use it to build later versions.

If you have some knowledge of Haskell, I'd appreciate some help in getting this up and running. I'm not a Haskell developer myself, I only looked into this while trying to port pandoc, so after these initial steps I was quickly lost in the Haskell code.

[ix]

Thanks for the insight! I'm a Haskell developer by profession, and I'm more than willing to write or modify any code necessary to bring the porting to fruition. To recap, I have the existing ncurses5 package installed manually, so I believe as per the plan the next step would be to try to build the same version with 6, yes?

I'm not particularly familiar with building GHC itself, so I will have to do some digging to ascertain whether building it with 6 is at all possible, but I will give it a shot this weekend.

[pulkomandy]

The "ghc78" recipe should be usable to build ghc with ncurses6, I think, but I don't remember how far I went with that.

Basically, run haikuporter ghc78 (or haikuporter ghc78_x86, I'm not sure) and see what happens.

[pulkomandy]

Hi,

Yesterday I managed to build a version of ncurses compatible with the version 5 ABI using ncurses 6.2 sources. It is available as ncurses5_x86 and enough to get the ghc_x86 package running again.

I am now trying to get ghc 7.8.4 to build and then will attempt to work on the next versions. There seem to be problems because ghc is built in DYNAMIC_BY_DEFAULT mode without the vanilla "way" enabled, and as a result it can't be used to build itself (this is an old, known problem from when we got it running: https://gitlab.haskell.org/ghc/ghc/-/issues/10374). Moreover it seems that DYNAMIC_BY_DEFAULT is deprecated now.

I am trying to rebuild ghc 7.8.3 with vanilla enabled, so that I can use it to build later versions of ghc.

So far my changes to the configuration are:

-               GhcLibWays = dyn
+               GhcLibWays = v dyn
-               DYNAMIC_BY_DEFAULT = YES
+               DYNAMIC_GHC_PROGRAMS = YES
+               DYNAMIC_TOO = YES

I don't know if this will be enough or if I'll have to completely disable dynamic at first, go up a few versions, and then see about enabling it again in a newer version that has more complete support.

[pulkomandy]

As for ncurses 5 vs 6, it seems that the difference is only in the ABI and not the API. So, building new versions to use ncurses 6 will be fine.

For this reason, my ncurses 5 package contains only the runtime libraries and no development files. It is then used only for running the old prebuilt ghc binaries. Anything we rebuild will use ncurses 6.

[pulkomandy]

I just pushed some more fixes to the ghc recipe and managed to build a later version (7.10) using it. I think this is solved now.