Building ghc-pkg: can't find stage0-built libs about hadrian HOT 16 CLOSED

@quchen Can you check whether the libraries have actually been built already?

I suppose this flag -optl-L/home/david/Coding/haskell/ghc/libraries/binary/stage0/build tells GHC where to find the libHSbinary-0.8.0.0.a library file. On my Windows built the library is indeed there.

from hadrian.

@snowleopard that folder has contents, so something has been built. But there's no .a file there.

λ. tree                                                                                                                                                   13:04:41  david@david-tng-laptop 
.
├── autogen
│   ├── cabal_macros.h
│   └── Paths_binary.hs
└── Data
    ├── Binary
    │   ├── Builder
    │   │   ├── Base.hi
    │   │   └── Base.o
    │   ├── Builder.hi
    │   ├── Builder.o
    │   ├── Class.hi
    │   ├── Class.o
    │   ├── Generic.hi
    │   ├── Generic.o
    │   ├── Get
    │   │   ├── Internal.hi
    │   │   └── Internal.o
    │   ├── Get.hi
    │   ├── Get.o
    │   ├── Put.hi
    │   └── Put.o
    ├── Binary.hi
    └── Binary.o

from hadrian.

If you look into Rules/Program.hs, you'll see this line responsible for building all dependencies (such as lib*.a libraries) before a program such as ghc-pkg is built:

need $ binDeps ++ libs

You can add the following debug command to check which libraries were supposed to be built:

need $ binDeps ++ libs
when (pkg == ghcPkg) . putBuild $ "Libraries built: " ++ show libs

Maybe this will help to understand what is going on.

from hadrian.

@snowleopard this produces, Libraries built: [] for me.

from hadrian.

Same thing for me.

from hadrian.

OK, thanks. I'll have a look at this tonight.

from hadrian.

For the record, when I run it on Windows I get the following output:

libs = [ "libraries/Cabal/Cabal/stage0/build/libHSCabal-1.23.0.0.a"
       , "libraries/binary/stage0/build/libHSbinary-0.8.0.0.a"
       , "libraries/ghc-boot/stage0/build/libHSghc-boot-0.0.0.0.a" ]

This is correct, since terminfo is not built on Windows.

from hadrian.

I've inspected the code and I don't see how the bug could be triggered. This must be something platform specific, beyond just the windowsHost condition being set to False.

Could one of you run the following please?

need $ binDeps ++ libs
when (pkg == ghcPkg) $ do
    putBuild $ "pkgs = " ++ show (sort pkgs)
    putBuild $ "depNames = " ++ show (map PackageName $ sort depNames)
    putBuild $ "deps = " ++ show deps

from hadrian.

I see,

pkgs = [Cabal,binary,deriveConstants,dll-split,genapply,genprimopcode,ghc,ghc-bin,ghc-boot,ghc-cabal,ghc-pkg,hoopl,hp2ps,hpc,hsc2hs,template-haskell,terminfo,transformers]
depNames = []
deps = []

It appears that the issue is that TRANSITIVE_DEP_NAMES is no longer produced by ghc-cabal. It seems that the matter of moving away from ghc-cabal is becoming more pressing by the day.

from hadrian.

@bgamari Is there a way to bring back TRANSITIVE_DEP_NAMES? Getting rid of ghc-cabal is a big task and we probably don't want to have it on the critical path.

By the way, it may be possible to use DepNames instead of TransitiveDepNames, however, if I remember correctly this is not accurate. (Logically, DepNames should do fine, but I remember having problems when using it. Maybe worth to investigate.)

from hadrian.

Done. See 3017cbc.

from hadrian.

Great!
@quchen, @bgamari Let me know if you have any other problems with stage0 libs. If not we'll close this issue.

from hadrian.

I've run into this issue as well. I'll give this a try on OS X as well, or has anyone else already?
Btw. who's testing on which platforms?

from hadrian.

Can confirm this works on OS X as well. Now I'm at the same point where @bgamari opened #35.

from hadrian.

Thanks @angerman.

I'm testing on Windows, @bgamari & @quchen on Linux, and you on OS X. I think.

from hadrian.

I'll close this now.

If anyone comes across this issue again, the solution is to update to the latest ghc-cabal version which provides the TRANSITIVE_DEP_NAMES fields.

from hadrian.