stack build failure due to Base version.

[djduke]

I have ghc 8.10.1 so surprised by:

stack build threadscope

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for Cabal-2.0.1.1:
containers-0.6.2.1 from stack configuration does not match >=0.4 && <0.6 (latest matching version is 0.5.11.0)
time-1.9.3 from stack configuration does not match >=1.4 && <1.9 (latest matching version is 1.8.0.4)
needed due to threadscope-0.2.13 -> Cabal-2.0.1.1

In the dependencies for gio-0.13.6.1:
gtk2hs-buildtools must match >=0.13.2.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
needed due to threadscope-0.2.13 -> gio-0.13.6.1

In the dependencies for glib-0.13.7.1:
gtk2hs-buildtools must match >=0.13.2.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
needed due to threadscope-0.2.13 -> glib-0.13.7.1

In the dependencies for gtk-0.15.4:
cairo must match >=0.13.0.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
gtk2hs-buildtools must match >=0.13.2.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
needed due to threadscope-0.2.13 -> gtk-0.15.4

In the dependencies for pango-0.13.6.1:
cairo must match >=0.13.0.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
gtk2hs-buildtools must match >=0.13.2.0 && <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
needed due to threadscope-0.2.13 -> pango-0.13.6.1

In the dependencies for process-1.4.3.0:
base-4.13.0.0 from stack configuration does not match >=4.4 && <4.11 (latest matching version is 4.10.1.0)
needed due to threadscope-0.2.13 -> process-1.4.3.0

In the dependencies for threadscope-0.2.13:
cairo must match <0.14, but the stack configuration has no specified version (latest matching version is 0.13.8.0)
needed since threadscope is a build target.

Some different approaches to resolving this:

• Build requires unattainable version of base. Since base is a part of GHC, you most likely need to use a different GHC version with the matching base.

Plan construction failed.

[maoe]

gtk2hs doesn't support GHC 8.10.1 yet so threadscope cannot build with 8.10.1 unfortunately. Can you try with GHC 8.8.3?

[djduke]

It doesn't build with 8.8.3. Looking on hackage Its hard to see a combination of threadscope and ghc versions that do work
Apparently threadscope 0.1 built with ghc 8.0.1 but that was two years ago. I'm cautious abut regressing ghc version too are as (a) I might run into other old bugs; (b) it will make any performance measurements I make seem obsolete. Asa suggestion it would be helpful if hackage packages more clearly listed the most recent ghc version on which they successfully built.
thanks
David

[maoe]

It doesn't build with 8.8.3.

Could you please elaborate? What commands did you run on what platform and how did it fail etc? FYI the instructions to build threadscope are available at https://github.com/haskell/ThreadScope#building-from-source.

Also the latest binaries are available at https://github.com/haskell/ThreadScope/releases/tag/v0.2.13 so you don't have to build it yourself unless you develop something in threadscope or to run it on a platform where a pre-built binary is unavailable.

Looking on hackage Its hard to see a combination of threadscope and ghc versions that do work

Currently supported (tested) range is 8.2-8.8.

This info is also available at https://matrix.hackage.haskell.org/#/package/threadscope, which is linked from https://hackage.haskell.org/package/threadscope. Search for 'Status'. The Haskell CI badge links to the matrix builder page.

Asa suggestion it would be helpful if hackage packages more clearly listed the most recent ghc version on which they successfully built.

You can propose such a feature at https://github.com/haskell/hackage-server. I'm in favor of making supported GHC range stand out more on Hackage.

[djduke]

Thanks. I started a fresh build from the git repo and made more progress. Howeever it looks lie te core issue isn't threadscope per se but Gtk(glib)

Configuring glib-0.13.8.0...
glib > build
glib > Preprocessing library for glib-0.13.8.0..
glib > setup: Error in C header file.
glib >
glib > /usr/include/time.h:153: (column 17) [FATAL]
glib > >>> Syntax error!
glib > The symbol `attribute' does not fit here.

I've tried both OSX an Ubuntu. I'm using ghc-8.8.3
This was a known problem but apparently not completely removed I'll poke around and flag with on the gtk repo. Thought I'd mailed the mailing list.
Anyhow The reason I'm trying to build from source rather than install a binary isthar I was hoping to continue the work I'd done with Peter Wortman, Karolis Velicka on enhancing profiling support:

• taking events from a running process
• extending visualization to include stack use
  'Lag, drag, void & use' ala Runciman & Rojemo

thanks - David

[maoe]

I see. That build failure is a known issue in gtk2hs. See gtk2hs/gtk2hs#291. Hopefully it'll be fixed upstream soon but for now you can install gcc using homebrew and use stack.osx.yaml to build the project.

See the instructions I updated a few days ago.

Anyhow The reason I'm trying to build from source rather than install a binary isthar I was hoping to continue the work I'd done with Peter Wortman, Karolis Velicka on enhancing profiling support:

• taking events from a running process
• extending visualization to include stack use 'Lag, drag, void & use' ala Runciman & Rojemo

That sounds great!

[djduke]

After another ghc upgrade 8.10.4 I've run into different issues with stack build for Threadscope, this time tge culprit is libiconv
build (exe)
Preprocessing executable 'threadscope' for threadscope-0.2.14..
Building executable 'threadscope' for threadscope-0.2.14..
Linking .stack-work/dist/x86_64-osx/Cabal-3.0.1.0/build/threadscope/threadscope ...
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
_hs_iconv in libHSbase-4.13.0.0.a(iconv.o)
(maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure )
"_iconv_open", referenced from:
_hs_iconv_open in libHSbase-4.13.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_open)
"_iconv_close", referenced from:
_hs_iconv_close in libHSbase-4.13.0.0.a(iconv.o)
(maybe you meant: _hs_iconv_close)
"_locale_charset", referenced from:
_localeEncoding in libHSbase-4.13.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gcc' failed in phase Linker'. (Exit code: 1)

-- While building package threadscope-0.2.14 (scroll up to its section to see the error) using:
/Users/scsdjd/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.4 --builddir=.stack-work/dist/x86_64-osx/Cabal-3.0.1.0 build exe:threadscope --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1

No iconv issues have been a known issue with ghc on OSX for a while. Unfortunately I found stack's output a bit cryptic its not clear what actions I can take - does anyone have any insight:
I'm on OSX 11.1 (Big Sur)
I tried to fallback on incrementally building components usin cabal.However I run into a problem with a package chain. when I raised this as an issue o the packages I was advised to use stack instead...

[maoe]

stack --stack-yaml=stack.osx.yaml build works for me on Big Sur with stack 2.5.1.

A quick google search turned up commercialhaskell/stack#825, which looks quite similar.

[djduke]

thank you for the suggestions However neither * install ihaskell, nor * add extra-lib-dir: to stack.yaml resolved the issue * * * IIRC whenit last cropped up the solution ws to rebuild ghc and using * config flags to set various iconv flags. However this is not an option for me at present due to various unrelated issues with building ghc. ore fundamentally it points as per the disussion to something fundamentally broke i the the build system. thanks anyway. *

…

________________________________ From: Mitsutoshi Aoe <notifications@github.com> Sent: 19 February 2021 15:49 To: haskell/ThreadScope <ThreadScope@noreply.github.com> Cc: David Duke <D.J.Duke@leeds.ac.uk>; Author <author@noreply.github.com> Subject: Re: [haskell/ThreadScope] stack build failure due to Base version. (#114) stack --stack-yaml=stack.osx.yaml build works for me on Big Sur with stack 2.5.1. A quick google search turned up commercialhaskell/stack#825<commercialhaskell/stack#825>, which looks quite similar. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#114 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADVIHP7GMU2ABX5OF6TZOB3S72B73ANCNFSM4NSMH6BQ>.