Opened 3 years ago

Last modified 3 years ago

#12200 new bug

ghc-pkg check complains about missing libCffi on dynamic-only install

Reported by: dudebout Owned by:
Priority: normal Milestone:
Component: ghc-pkg Version: 7.10.2
Keywords: libCffi Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

After installing the Linux (x86_64) version of ghc 7.10.2, I removed all the .a files as I was interested in a dynamic libraries only install. Everything works fine but ghc-pkg check fails with the following error:

cannot find any of ["libCffi.a","libCffi.p_a","libCffi-ghc7.10.2.so","libCffi-ghc7.10.2.dylib","Cffi-ghc7.10.2.dll"] on library path

Adding a symbolic link from lib/ghc-7.10.2/rts/libffi.so to lib/ghc-7.10.2/rts/libCffi-ghc7.10.2.so silences that warning. I am not sure that this is the correct way to handle this.

Change History (1)

comment:1 Changed 3 years ago by thomie

Commit b30015e78db99d79cdb48c6c810e3fd49573c5cd is relevant:

Author: Ian Lynagh <ian@well-typed.com>
Date:   Sat Mar 23 23:55:56 2013 +0000

    Change how we handle libffi
    
    I think overall the new approach is simpler. Rather than unpacking
    the libffi.a and putting the .o files into our libHSrts.a, we just
    use the libffi.a.
    
    This change also means that when compiling programs for the dyn
    way, they get explicitly linked against libffi.so (rather than
    relying on librts.so being linked against it). This might
    fix a problem on FreeBSD, where programs cannot find libffi.so.

In compiler/main/Packages.hs:

           -- For non-Haskell libraries, we use the name "Cfoo". The .a
           -- file is libCfoo.a, and the .so is libfoo.so. That way the
           -- linker knows what we mean for the vanilla (-lCfoo) and dyn
           -- (-lfoo) ways. We therefore need to strip the 'C' off here.

I don't know why in rts/package.conf.in, FFI_LIB is listed in hs-libraries. It isn't a Haskell library, but because of its listing there, this code in utils/ghc-pkg/Main.hs is triggered:

checkHSLib :: Verbosity -> [String] -> String -> Validate ()
checkHSLib _verbosity dirs lib = do
  let filenames = ["lib" ++ lib ++ ".a",
                   "lib" ++ lib ++ ".p_a",
                   "lib" ++ lib ++ "-ghc" ++ Version.version ++ ".so",
                   "lib" ++ lib ++ "-ghc" ++ Version.version ++ ".dylib",
                            lib ++ "-ghc" ++ Version.version ++ ".dll"]
  b <- liftIO $ doesFileExistOnPath filenames dirs
  when (not b) $
    verror ForceFiles ("cannot find any of " ++ show filenames ++
                       " on library path")

Note: See TracTickets for help on using tickets.