Boot GHC's libffi installation path leaks into stage1 build

changed milestone to %⊥

changed weight to 5

The libffi bit seems to be pulled in from rts, which itself isn't mentioned as include dir:

{sourcePackageId = PackageIdentifier {pkgName = PackageName "rts", pkgVersion = mkVersion [1,0]}, sourceLibName = LMainLibName, installedComponentId_ = ComponentId "", installedUnitId = UnitId "rts", instantiatedWith = [], compatPackageKey = "rts", license = Left (License (ELicense (ELicenseId BSD_3_Clause) Nothing)), copyright = "", maintainer = "glasgow-haskell-users@haskell.org", author = "", stability = "", homepage = "", pkgUrl = "", synopsis = "", description = "", category = "", abiHash = AbiHash "", indefinite = False, exposed = True, exposedModules = [], hiddenModules = [], trusted = False, importDirs = [], libraryDirs = ["/nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3/rts","/nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/lib"], libraryDynDirs = [], dataDir = "", hsLibraries = ["HSrts"], extraLibraries = ["m","rt","dl","ffi","pthread"], extraGHCiLibraries = [], includeDirs = ["/nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3/include","/nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include"], includes = ["Stg.h"], depends = [], abiDepends = [], ccOptions = [], cxxOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = [], haddockHTMLs = [], pkgRoot = Just "/nix/store/23ndnrb11m3k7zh4p84vjmdgand0p45b-ghc-8.6.3-with-packages/lib/ghc-8.6.3", libVisibility = LibraryVisibilityPrivate}

I could probably fix this by the following patch:

diff --git a/utils/ghc-cabal/Main.hs b/utils/ghc-cabal/Main.hs
index 8b776499fd..f4a2313194 100644
--- a/utils/ghc-cabal/Main.hs
+++ b/utils/ghc-cabal/Main.hs
@@ -338,14 +338,22 @@ generate directory distdir config_args
               [(_,[rts])] ->
                  PackageIndex.insert rts{
                      Installed.ldOptions = [],
-                     Installed.libraryDirs = filter (not . ("gcc-lib" `isSuffixOf`)) (Installed.libraryDirs rts)} index
-                        -- GHC <= 6.12 had $topdir/gcc-lib in their
-                        -- library-dirs for the rts package, which causes
-                        -- problems when we try to use the in-tree mingw,
-                        -- due to accidentally picking up the incompatible
-                        -- libraries there.  So we filter out gcc-lib from
-                        -- the RTS's library-dirs here.
+                     Installed.libraryDirs = filter_dirs (Installed.libraryDirs rts),
+                     Installed.includeDirs = filter_dirs (Installed.includeDirs rts)
+                  } index
               _ -> error "No (or multiple) ghc rts package is registered!!"
+          filter_dirs = filter (\dir -> not (or [is_gcc_lib dir, is_libffi dir]))
+          -- GHC <= 6.12 had $topdir/gcc-lib in their
+          -- library-dirs for the rts package, which causes
+          -- problems when we try to use the in-tree mingw,
+          -- due to accidentally picking up the incompatible
+          -- libraries there.  So we filter out gcc-lib from
+          -- the RTS's library-dirs here.
+          is_gcc_lib = ("gcc-lib" `isSuffixOf`)
+          -- In Trac #16368, we noticed that libffi paths
+          -- from the boot GHC shadow the local libffi tarballs
+          -- in a similar manner.
+          is_libffi = ("libffi" `isInfixOf`)
 
           dep_ids  = map snd (externalPackageDeps lbi)
           deps     = map display dep_ids

Are there any other packages in the list of paths from the OP look from to you? bgamari, perhaps?

changed the description

That patch doesn't help at all. It seems we really depend on the libffi bundled with boot GHC(?).

The problem is probably with my Nix shell and this recent change https://github.com/NixOS/nixpkgs/commit/a7c774300b7eab779afb9a81b3f02f3bed69c943. So, Nix provides a boot GHC that is built and bundled with the system libffi. I still have to figure out where it stores libffi's headers.

Nix stores headers in /nix/store/xxx-libffi-3.2.1-dev/include, so it separates build artifacts from headers. So the problem is with the wrong setting here.

closed

Fixed in https://github.com/NixOS/nixpkgs/pull/56573.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

added Pnormal label

Boot GHC's libffi installation path leaks into stage1 build

Child items 0

Activity