You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
collision between /nix/store/bdqq3j1bl4s6mm7cr2jmspnz9md63vkb-ghc-7.8.4/lib/ghc-7.8.4/xhtml-3000.2.1/Text/XHtml/Table.hi and /nix/store/c8p9y30f11d444qfsvl04w45s99m284h-haskell-xhtml-ghc7.8.4-3000.2.1-shared/lib/ghc-7.8.4/xhtml-3000.2.1/Text/XHtml/Table.hi at
/nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
In a previously sent pull request #5060 which was closed mentioning the problem was on GHC side, I mentioned the same issue and was redirected to https://ghc.haskell.org/trac/ghc/ticket/8919. In a
second reading, I found that it may be nix which it at fault. Indeed, from the last post by @slyfox,
it would seem that
ghc's xhtml is already a private lib
and that
I see a problem in one single case: if you install haskell libs in ghc's private subdir.
I'd strongly suggest against that practice and pick any other random dir out there.
ghc's private directory being lib/ghc-7.8.4/xhtml-3000.2.1 infix, it seem that nix is indeed
installing its haskell packages in ghc's private directory which, it would seem to me
is why we have this problem in the first place.
On gentoo we just install external haskell libs in other location: /usr/lib64/xhtml-3000.2.1/ghc-7.8.2/libHSxhtml-3000.2.1-ghc7.8.2.so
which would correspond to someting like lib/xhtml-3000.2.1/ghc-7.8.4 infix
for nix.
Shouldn't nix avoid as well installing its haskell packages in ghc's private dir
so as to avoid further problems. It is clear to me from the ghc ticket that
this is to be avoided.
The text was updated successfully, but these errors were encountered:
@jraygauthier, thank you very much for the detailed bug report. I appreciate the effort you've put into clarifying the issue. I have a couple of comments in no particular order:
The fact that haskell-defaults.nix is lacking a xhtml = null override is a bug. xhtml is a core library in GHC 7.8.4 just like base is, and it's a mistake to try and build the exact same version as a user and try to make builds use that one instead of the one that comes with the compiler.
Generally speaking, the haskellPackages set is slightly unmaintained. I wouldn't say it's dead, but it's smelling funny, IMHO, and you should probably switch to haskellngPackages instead, which doesn't have this problem.
I have no idea what @slyfox means by calling xhtml a "private library". According to ghc-pkg describe xhtml, it's by no means private: it's a core library everyone is free to use. As such, he's doing his users no favor by inventing directory trickery that allows them to install another version of xhtml, because they'll end up with broken binaries if they ever pick a combination of packages that links both the core and non-core variant of xhtml at the same time.
GHC's lib directory is not a "private" directory. No collision occur when you install different versions of the same library into that place. Collisions occur only if you try to install the exact same library twice -- and this is a good thing, because an installation that provides two competing copies of the same library is inherently broken.
As of 5e7501c building the
gitit
package.In a previously sent pull request #5060 which was closed mentioning the problem was on GHC side, I mentioned the same issue and was redirected to https://ghc.haskell.org/trac/ghc/ticket/8919. In a
second reading, I found that it may be nix which it at fault. Indeed, from the last post by @slyfox,
it would seem that
and that
ghc's private directory being
lib/ghc-7.8.4/xhtml-3000.2.1
infix, it seem that nix is indeedinstalling its haskell packages in ghc's private directory which, it would seem to me
is why we have this problem in the first place.
@slyfox also mentionned that
which would correspond to someting like
lib/xhtml-3000.2.1/ghc-7.8.4
infixfor nix.
Shouldn't nix avoid as well installing its haskell packages in ghc's private dir
so as to avoid further problems. It is clear to me from the ghc ticket that
this is to be avoided.
The text was updated successfully, but these errors were encountered: