Building: Bad interface file/Cannot continue after interface file error #328
Comments
|
Thanks for the bug report. Unfortunately, I'm out of my depth here, because I have never used the Setup.hs interface directly. #315 does sound related. Could you provide a self-contained script for reproduction? I tried the following for It would help to know what exactly triggers the error. |
|
Thanks for your quick action!
The PKGBUILD contains the necessary information. The interesting instructions for our specific case: runhaskell Setup configure -O --enable-shared --enable-executable-dynamic --disable-library-vanilla \
--prefix=/usr --docdir=/usr/share/doc/happy --datasubdir=happy --enable-tests \
--dynlibdir=/usr/lib --libsubdir=\$compiler/site-local/\$pkgid \
--ghc-option=-optl-Wl\,-z\,relro\,-z\,now \
--ghc-option='-pie'
runhaskell Setup buildTo run tests: Edit: The issue also occurs with Note: The Haskell packages on Arch are built as shared libraries, which is reflected in above instructions. You might need to remove the related options, but I included them for full transparency. |
Thanks, I had seen that file, but I don't know what to do with it, nor what precise commands you executed. I cannot reproduce with the following commands, using the setup from my last message: Perhaps you can try a newer Cabal and see if it works? Sadly I don't know how to install an older version of cabal locally... |
|
Same error with GHC 9.6 and Cabal 3.10. It's interesting that the issue gets ignored in Cabal 3.6, but leads to failure in 3.8 and 3.10. I can't test GHC 9.8, as that would need My build environmentAs for the PKGBUILD, it's basically a bash script executed in a newly created systemd container. When the dependencies are installed and the source archive extracted, the The only command I execute personally is More logshappy-2.1.3-1-x86_64-build.log Here is another log with |
|
Just to check, I've created a PKGBUILD to do the normal install (without polluting my system): The important observation is that So likely a Cabal issue like the other one, even if potentially not the same one. Edit: For my own convenience, here is the latest version of the testscript: |
It's a bit sad that I can't really help here, but I think you are correct. Is it possible for you to simply use |
Not really, because the container would need to be set up for that which means at least redownloading the package list every time. And then it's questionable if it would even work with the system-provided GHC. For now, I've resorted to downgrading happy to continue building. That's not a long-term solution. The packaging changes in happy 2.0.2 did provide some advantages, like finally enabling the tests. |
|
Yes, I think downgrading It is not unlikely that GHC 9.14 (due in 2025) will require |
|
The issue with private sublibraries is probably very old. But it was never a problem (in terms of compilation), because the relevant function (
Maybe an issue could be opened there to find a solution. The error is initially raised in compiler/GHC/Iface/Load.hs#L912. Another point for context: This is about as far as I got. @sgraf812 Can you talk to the people over at GHC? Perhaps you can figure out a way together. -- Vekhir |
|
Sorry for the silence; I was on holiday and then busy. I see you already opened https://gitlab.haskell.org/ghc/ghc/-/issues/25603. That's great, especially because I don't have a clue as to what is going on.
Note that in your workflow, you call I'm not sure if it's actually a bug in GHC; the commit you link sounds reasonable. If you force GHC to load a library defining a type |
|
One bit I'm continually puzzled about: How do you build If I do at the top-level (to build If I run to build which makes sense, because there is no Setup.hs in |
|
Using GHC 9.6 and Cabal 3.10.3, I can confirm that the following instructions successfully build Can you try this locally on a clean checkout? Note the See also Section 5.3 of the Cabal user guide which has a few remarks about internal sublibrary components. I'm not sure if it's relevant to you. |
No problem, happy holidays!
That makes two of us.
Part of it is just involving any people that might be able to bring some clarity into the situation. The commit is fine; but it's the reason why GHC 9.2 works and 9.4 doesn't. And this issue is apparently something that they might have encountered previously? At least, they say it should never happen, so no idea how Cabal can produce this level of garbage. At this stage, my best guess is that the Paths_happy_lib.dyn.hi file is corrupted; It seems to be generated from an (also generated) Paths_happy_lib.hs which is the same with v1-build and v2-build (which I've checked out in the meantime). So, the issue probably lies in the step Paths_happy_lib.hs -> Paths_happy_lib.dyn.hi, which I'd assume only GHC can do anything about.
We follow the structure on Hackage, i.e. The missing I'll try out your instructions and report back the results. |
|
OK, I turned your example into this PKGBUILD: It clones the github repo and switches to it, then executes the instructions as above. I had to add With that, building Well, we need to switch back to the top-level :) Interestingly, there is no error message at all - previously, it would complain, but nothing happens. I then confirmed with GHC 9.6.6 and it actually works! |
|
Hm, tests are failing with since we don't install happy-lib. I'm going to try building GHC. |
|
Indeed, in the end you will need to run |
|
Here is a tweakable script that successfully build, packages, installs and tests
Thanks! #! /usr/bin/env bash
TMP=${TMP:-/tmp}
DIST_DIR=$TMP/happy-lib-dist
DB=$TMP/db
INSTALL_DIR=$TMP/usr/local
CONFIGURE_FLAGS="-O --enable-shared --enable-executable-dynamic --disable-library-vanilla \
--prefix=$INSTALL_DIR --package-db=$DB --enable-tests \
--ghc-option=-optl-Wl,-z,relro,-z,now \
--ghc-option=-pie"
rm -rf $DB $DIST_DIR $INSTALL_DIR
ghc-pkg init $DB
git clone --depth=1 https://github.com/haskell/happy $TMP/happy
cd $TMP/happy
git reset --hard HEAD
git clean -fxd
cp Setup.hs lib
# Build happy-lib
cd $TMP/happy/lib
runhaskell --ghc-arg='-package Cabal' Setup configure $CONFIGURE_FLAGS --prefix=$INSTALL_DIR
runhaskell --ghc-arg='-package Cabal' Setup build
# Package happy-lib
runhaskell --ghc-arg='-package Cabal' Setup copy --destdir=$DIST_DIR
runhaskell --ghc-arg='-package Cabal' Setup register --gen-script
runhaskell --ghc-arg='-package Cabal' Setup unregister --gen-script
install -D -m744 register.sh unregister.sh $DIST_DIR/$INSTALL_DIR
# Now we'd create the tarball for $DIST_DIR.
# Install happy-lib
# The following line emulates unpacking said tarball, which installs into
# INSTALL_DIR:
(cd $DIST_DIR; cp -r * /)
# Now call the register script for INSTALL_DIR:
$INSTALL_DIR/register.sh --package-db $DB
# Build happy
cd $TMP/happy
runhaskell --ghc-arg='-package Cabal' Setup configure $CONFIGURE_FLAGS
runhaskell --ghc-arg='-package Cabal' Setup build
runhaskell --ghc-arg='-package Cabal' Setup test
# Package happy
runhaskell --ghc-arg='-package Cabal' Setup copy --destdir=$DIST_DIR
runhaskell --ghc-arg='-package Cabal' Setup register --gen-script
runhaskell --ghc-arg='-package Cabal' Setup unregister --gen-script
install -D -m744 register.sh unregister.sh $DIST_DIR/$INSTALL_DIR
# Install happy
(cd $DIST_DIR; cp -r * /)
$INSTALL_DIR/register.sh --package-db $DB
# Run happy on a test, verifying that distribution was successlful
$INSTALL_DIR/bin/happy $TMP/happy/tests/issue91.y
echo success! |
|
Please try out appending With the success case in hand I was able to compare the build results at each stage. I then noticed that up to I also checked out your latest example, after some tweaking I got it to work. Unsurprisingly, it too doesn't feature Log (haskell-happy-lib) |
|
@sgraf812 Happy new year! Have you tried out my suggestion above? Since then, I've opened an issue in Cabal: haskell/cabal#10687 When trying to make both backends depend on the same sublibrary (let's say The best solution (although not pretty) until the issue is fixed in Cabal is probably to manually merge the two backends, so they only generate one (compare full cabal file below) |
|
Thanks for digging deeper. Indeed, I can reproduce with Is it no option for you to have |
Hi, I'm coming from Arch Linux and working on getting GHC 9.4 running. The rebuilds require
happyto compile.Building
happy2.0.2 with GHC 9.4.8 leads to this error:Investigation
The same happens with
happy2.1.3. Superficially, the error looks similar to #315. One difference is that, for bootstrapping reasons, we use the GHC includedrunhaskellscript instead ofcabal install.Building with GHC 9.2 and Cabal 3.6 emits the same
Bad interface file [...]message, but does not fail to build. See error log below for details.Conclusion
For the time being, is there anything we can do to workaround this issue?
If you need anything else from me or want me to check something, feel free to ask.
-- Vekhir.
Appendix
System information:
OS: Arch Linux
Kernel: Linux 6.12.1-arch1-1
GHC: 9.4.8
Cabal: 3.8.1.0
happy-lib: 2.0.2 and 2.1.3 (PKGBUILD)
happy: 2.0.2 and 2.1.3 (PKGBUILD)
Error log
GHC 9.4:
GHC 9.2:
The text was updated successfully, but these errors were encountered: