GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary?
If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it?
Or, if that's not possible, if the library needs to be installed, please make it visible to users.
See comment 17 for a discussion on why this is causing problems for distribution vendors.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
In Fedora, so far I have been working around it by packaging the xhtml library along with the other ghc libraries. Since xhtml is in HP anyway it seems easier/cleaner just to move it to ghc now IMHO.
Investigating this further, it looks like this isn't a case of files getting accidentally included.
I found the following comment in ghc.mk
# If we have built the programs with dynamic libraries, then
# ghc will be dynamically linked against haskeline.so etc, so
# we need the dynamic libraries of everything down to here
Which looks like it includes these libs if DYNAMIC_GHC_PROGRAMS is set to "YES"
Strange, transformers and hoopl shouldn't be in that list (i.e. as mentioned earlier in this ticket, only haskeline,terminfo, and xhtml are problematic), as those are actually needed by the ghc package (and they will show up in ghc-pkg list for a properly performed GHC installation)
Strange, transformers and hoopl shouldn't be in that list (i.e. as mentioned earlier in this ticket, only haskeline,terminfo, and xhtml are problematic), as those are actually needed by the ghc package (and they will show up in ghc-pkg list for a properly performed GHC installation)
Ah, this is my fault for looking at the list of files installed. If we are only talking about ghc-pkg list then I get the following lines on a fresh install:
Also, I did some investigation and it looks like hoopl and transformers are really only required for the compiler. Transformers is also a dependency of haskeline. So really both of them should be added to line 435 rather than line 419 so that they belong to REGULAR_INSTALL_DYNLIBS
But it doesn't look like transformers is mentioned.
So I'm not sure if this is an issue anymore. Looks like they were both meant to be added to ghc. Hoopl is mentioned in the release notes. But transformers isn't but it seems like it should be. Thoughts?
So I'm not sure if this is an issue anymore. Looks like they were both meant to be added to ghc. Hoopl is mentioned in the release notes. But transformers isn't but it seems like it should be. Thoughts?
To be honest, I'm rather confused about your problems with transformers and hoopl, as those have been in fact become officially GHC-bundled (and registered) core libraries since 7.8.1 and 7.2.1 respectively (see also Commentary/Libraries/VersionHistory)
The problems are (afaics) really just only with haskeline ,terminfo, and xhtml, for which only the DSOs get installed but nothing else is done.
hoopl/transformers are only used by exported 'ghc' library.
To make users load it into, say, ghci you need to export it completely (ghci -package ghc).
xhtml used by haddock binary, terminfo/haskeline used by ghc binary (--interactive mode, aka GHCi).
Thus they need only dynamic libs, no need to export them.
This is about shared libaries: of course there is no impact on platforms without them.
Starting with ghc-7.8, ghc's own binaries are also dynamically linked on platforms with dyn Haskell libs.
Shipping the shared library without devel files on Linux seems quite unnatural and awkward.
Shipping the shared library without devel files on Linux seems quite unnatural and awkward.
I’m not sure about this: If the .so file is put in a private location (not /usr/lib, what’s wrong with that)?
I’d actually prefer if GHC would ship as few packages as little, so that as many packages as possible can be packaged and installed in the “common” way.
I've been asked to briefly summarize the issue, since simons didn't write too much about it in the ticket itself.
GHC 7.8 uses the xhtml, terminfo and haskeline packages internally. Because of the dynamic ghci transition, the related .so files have to be shipped with the build. By not shipping the devel files (not making the cabal packages visible), we force the distribution vendors to package up these libraries separately and make them available in their repos. Nothing wrong with that of course (they do this for all the other important libraries, like lens and pipes too). The problem is that they can't ship the .so files in the respective packages, because it's usually not allowed for packages to overwrite each other's files in an adhoc manner. So when they build e.g. the xhtml deb or rpm package, they have to make sure that if the resulting .so files have the same name as the ghc shipped ones, then they don't include it in the package. These kind of workarounds seem extremely kludgy and fragile to me. This naming/overwrite issue causes some headaches for NixOS too, just in a slightly different setting.
I see two solutions going forward.
As nomeata said in comment 16, we can simply ship our .so files in a private directory and make our dynamic programs search there (via RPATH or some other trick).
Or we can simply ship these packages with GHC as we ship base, time and so many others. juhpetersen posted a patch for that in comment 14.
Alternatively, we can ignore it and just force people to go with the workarounds. I'd prefer not doing that. There were also some discussion on the mailing list about discontinuing the dynamic change after 7.10 and going back to static, which would of course make this go away.