Opened 6 years ago

Closed 13 months ago

#2555 closed bug (worksforme)

Template Haskell does not respect -package and -hide constraints

Reported by: guest Owned by:
Priority: lowest Milestone: 7.6.2
Component: Template Haskell Version: 6.8.2
Keywords: Cc: gwern0@…
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:


(I am using 6.8.2-2ubuntu1, packaged for Ubuntu Hardy Heron, on amd64.)

Recently sjanssen added some patches to the Lambdabot darcs repository which replace a preprocessor, BotPP, with some Template Haskell. This seems to work well, however I ran into a problem with it - everytime TH was called, it would error out with a message about Bytestring

This is far from the first time I've run into this problem, but it was not fixed by forcibly removing & recompiling affected packages against bytestring 09.0.1!

After even more debugging, I finally figured it out:

The module TH was erroring out on has an 'import Text.Regex'. Text.Regex is installed by the regex-compat package. I had two regex-compats installed. regex-compat-0.91 was linked against bytestring0.9.0.1. regex-compat-0.92 was linked against (the removed) bytestring-

Now, normally Cabal detects that using 0.92 would lead to errors, and it selects 0.91, and it adds to the GHC options '-hide-all-package -package regex-compat-0.91', and everything compiles fine and the user is happy.

But! in this case, Template Haskell ignores the flags, and it uses the most recent regex-compat. And it is this that breaks the build. I ultimately resolved this issue by removing regex-compat-0.92 and reinstalling and linking it against, although I fear this may yet lead to bugs in the future.

Short summary: Cabal is smarter than TH and picks better package versions to compile against, and yet TH ignores Cabal's picks. This leads to unnecessary & difficult to figure out compile failures.

Change History (17)

comment:1 Changed 6 years ago by guest

  • Cc gwern0@… added

comment:2 Changed 6 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 6.10 branch

comment:3 Changed 6 years ago by simonpj

Simon and I discussed this, and we can't understand enough about the problem to see what is going on. So we need a way to reproduce it. Can you give us some code, and a recipe for making it happen?


comment:4 Changed 6 years ago by guest

I think I described it thoroughly; reproducing it requires carefully installing a package or two, and I'm not going to risk screwing up my installation yet again.

comment:5 Changed 6 years ago by simonpj

  • Milestone changed from 6.10 branch to 6.12 branch

OK. If you come across it again, please let us know and we'll take the opportunity to get more specific info. Meanwhile, we're stuck.


comment:6 follow-up: Changed 6 years ago by simonmar

  • Component changed from Compiler to Template Haskell

We don't dispute there's a bug here, but it can't be as simple as just "TH ignores the package flags". The compiler only has one package environment which it constructs using the package flags on the command line, there's no separate package environment just for TH. TH uses exactly the same compilation and linking code as GHCi, so if something were wrong for TH it should also be wrong for GHCi. I've tried a few simple tests with the base package (we have both base-3 and base-4 now), and I can't see any evidence that TH or GHCi are "ignoring package flags".

If we even had a copy of the precise error message, that might help shed some light.

comment:7 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:8 in reply to: ↑ 6 Changed 4 years ago by duncan

  • Type of failure set to None/Unknown

Replying to simonmar:

We don't dispute there's a bug here, but it can't be as simple as just "TH ignores the package flags".

My current guess is that stale .hi files refer to another version of a package, so despite what the -package flags say we pull in two versions of a package when TH runs.

That said, this should only happen if there are multiple versions of a package in the package graph. So perhaps this doesn't explain what gwern reported.

comment:9 Changed 4 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:10 Changed 4 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:11 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:12 Changed 3 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:13 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:14 Changed 2 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1
  • Priority changed from low to lowest

comment:15 Changed 20 months ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:16 Changed 14 months ago by morabbin

This bug seems pretty stale, and never had a good description. Kill?

comment:17 Changed 13 months ago by igloo

  • Resolution set to worksforme
  • Status changed from new to closed

Agreed; we don't have a way to reproduce it, so closing.

Note: See TracTickets for help on using tickets.