Opened 9 years ago

Closed 9 years ago

#4901 closed bug (fixed)

Possible bug in GHCi archive loading:

Reported by: batterseapower Owned by:
Priority: high Milestone: 7.2.1
Component: Compiler Version: 7.0.1
Keywords: Cc: pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I'm not sure if this is a bug or an error in my understanding.

In trying to work around http://hackage.haskell.org/trac/hackage/ticket/791. I forced Cabal to install the library with a dummy .o file. Opening the library with GHCi caused the error:

*Main> :m Text.Highlighting.Kate.Syntax
Prelude Text.Highlighting.Kate.Syntax> languages
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package bytestring-0.9.1.8 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-pcre-builtin-0.94.2.1.7.7 ... linking ... done.
Loading package xhtml-3000.2.0.1 ... linking ... done.
Loading package highlighting-kate-0.2.8.1 ... <interactive>: mmap 0 bytes at 0x0: Invalid argument
<interactive>: Try specifying an address with +RTS -xm<addr> -RTS

So GHCi must prefer objects to archives. Fine. However, after I delete the object file totally I get this error:

Loading package highlighting-kate-0.2.8.1 ... linking ... done.

During interactive linking, GHCi couldn't find the following symbol:
  highlightingzmkatezm0zi2zi8zi1_TextziHighlightingziKateziSyntax_languages_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

I'm sure the symbol exists (admittedly with a _ prefix), because nm reports it in the archive:

$ nm libHShighlighting-kate-0.2.8.1.a | grep highlightingzmkatezm0zi2zi8zi1_TextziHighlightingziKateziSyntax_languages_closure
00009e24 D _highlightingzmkatezm0zi2zi8zi1_TextziHighlightingziKateziSyntax_languages_closure

I tried doing as the error suggested, and supplying a -l flag to GHCi. However, this was also unsuccessful:

mbolingbroke@equinox /usr/local/lib/highlighting-kate-0.2.8.1/ghc-7.0.1.20101215
$ ghci -L. -lHShighlighting-kate-0.2.8.1
GHCi, version 7.0.1.20101215: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) HShighlighting-kate-0.2.8.1 ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (dlopen(libHShighlighting-kate-0.2.8.1.dylib, 9): image not found)
Whilst trying to load:  (dynamic) HShighlighting-kate-0.2.8.1
Additional directories searched:   .

How do I use the GHCi archive loading functionality? If it works, we could stop Cabal from generating the object files and hence close bug 791, which is preventing libraries like highlighting-kate from being installed on OS X.

Attachments (1)

4901.dpatch (1.4 KB) - added by batterseapower 9 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by PHO

Cc: pho@… added

comment:2 Changed 9 years ago by igloo

Milestone: 7.0.3
Priority: normalhigh

comment:3 Changed 9 years ago by igloo

Is this 32bit OS X?

With 7.0.3, on OS X 32,

$ cabal install highlighting-kate

fails with

[111 of 111] Compiling Text.Highlighting.Kate ( Text/Highlighting/Kate.hs, dist/build/Text/Highlighting/Kate.o )
ld: scattered reloc r_address too large for inferred architecture i386
cabal: Error: some packages failed to install:
highlighting-kate-0.2.9 failed during the building phase. The exception was:
ExitFailure 1

but

$ cabal install highlighting-kate --disable-library-for-ghci

succeeds, and

$ ghci -package highlighting-kate
GHCi, version 7.0.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package bytestring-0.9.1.10 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-pcre-builtin-0.94.2.1.7.7 ... linking ... done.
Loading package xhtml-3000.2.0.1 ... linking ... done.
Loading package highlighting-kate-0.2.9 ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> 

comment:4 Changed 9 years ago by batterseapower

Thanks for the reply Ian. The problem is that although ghci succeeds at that stage, actually trying to *use* anything from the library fails. Try doing what I did in my original report:

:m Text.Highlighting.Kate.Syntax
languages

I tried it again with highlighting-kate 0.2.9 with the same result:

During interactive linking, GHCi couldn't find the following symbol:
  highlightingzmkatezm0zi2zi9_TextziHighlightingziKateziSyntax_languages_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

comment:5 Changed 9 years ago by igloo

Owner: set to igloo

Ah, sorry, must have misread it. OK, I can reproduce this now.

comment:6 Changed 9 years ago by igloo

Blocked By: 5062 added
Owner: igloo deleted

#5062 might fix this

Changed 9 years ago by batterseapower

Attachment: 4901.dpatch added

comment:7 Changed 9 years ago by batterseapower

Status: newpatch

The problem is that GCC is generating BSD-format archives with filenames of the form #120, but where the filename stored in the field is actually null-terminated in such a way that is is less than 20 bytes long. However, our current code assumes that the archive-supplied length is exactly the length of the string when indexing backwards to determine the file extension, which means that it fails to detect that the files in the archives are actually object files!

Simple fix is just to call strlen once we have copied the string out of the object file.

comment:8 Changed 9 years ago by igloo

Thanks. The patch in #5062 does the same thing.

comment:9 Changed 9 years ago by igloo

Blocked By: 5062 removed

comment:10 Changed 9 years ago by igloo

Resolution: fixed
Status: patchclosed

I applied the relevant part of #5062.

Note: See TracTickets for help on using tickets.