Update Trac ticket URLs to point to GitLab
[ghc.git] / docs / users_guide / bugs.rst
1 .. _bugs-and-infelicities:
2
3 Known bugs and infelicities
4 ===========================
5
6 .. _vs-Haskell-defn:
7
8 Haskell standards vs. Glasgow Haskell: language non-compliance
9 --------------------------------------------------------------
10
11 .. index::
12    single: GHC vs the Haskell standards
13    single: Haskell standards vs GHC
14
15 This section lists Glasgow Haskell infelicities in its implementation of
16 Haskell 98 and Haskell 2010. See also the “when things go wrong” section
17 (:ref:`wrong`) for information about crashes, space leaks, and other
18 undesirable phenomena.
19
20 The limitations here are listed in Haskell Report order (roughly).
21
22 .. _haskell-standards-divergence:
23
24 Divergence from Haskell 98 and Haskell 2010
25 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26
27 By default, GHC mainly aims to behave (mostly) like a Haskell 2010
28 compiler, although you can tell it to try to behave like a particular
29 version of the language with the :ghc-flag:`-XHaskell98` and
30 :ghc-flag:`-XHaskell2010` flags. The known deviations from the standards are
31 described below. Unless otherwise stated, the deviation applies in Haskell 98,
32 Haskell 2010 and the default modes.
33
34 .. _infelicities-lexical:
35
36 Lexical syntax
37 ^^^^^^^^^^^^^^
38
39 -  Certain lexical rules regarding qualified identifiers are slightly
40    different in GHC compared to the Haskell report. When you have
41    ⟨module⟩\ ``.``\ ⟨reservedop⟩, such as ``M.\``, GHC will interpret it
42    as a single qualified operator rather than the two lexemes ``M`` and
43    ``.\``.
44
45 -  ``forall`` is always a reserved keyword at the type level, contrary
46    to the Haskell Report, which allows type variables to be named ``forall``.
47    Note that this does not imply that GHC always enables the
48    :ghc-flag:`-XExplicitForAll` extension. Even without this extension enabled,
49    reserving ``forall`` as a keyword has significance. For instance, GHC will
50    not parse the type signature ``foo :: forall x``.
51
52 .. _infelicities-syntax:
53
54 Context-free syntax
55 ^^^^^^^^^^^^^^^^^^^
56
57 -  In Haskell 98 mode and by default (but not in Haskell 2010 mode), GHC
58    is a little less strict about the layout rule when used in ``do``
59    expressions. Specifically, the restriction that "a nested context
60    must be indented further to the right than the enclosing context" is
61    relaxed to allow the nested context to be at the same level as the
62    enclosing context, if the enclosing context is a ``do`` expression.
63
64    For example, the following code is accepted by GHC: ::
65
66        main = do args <- getArgs
67                  if null args then return [] else do
68                  ps <- mapM process args
69                  mapM print ps
70
71    This behaviour is controlled by the ``NondecreasingIndentation``
72    extension.
73
74 -  GHC doesn't do the fixity resolution in expressions during parsing as
75    required by Haskell 98 (but not by Haskell 2010). For example,
76    according to the Haskell 98 report, the following expression is
77    legal: ::
78
79            let x = 42 in x == 42 == True
80
81    and parses as: ::
82
83            (let x = 42 in x == 42) == True
84
85    because according to the report, the ``let`` expression “extends as
86    far to the right as possible”. Since it can't extend past the second
87    equals sign without causing a parse error (``==`` is non-fix), the
88    ``let``\-expression must terminate there. GHC simply gobbles up the
89    whole expression, parsing like this: ::
90
91            (let x = 42 in x == 42 == True)
92
93 .. _infelicities-exprs-pats:
94
95 Expressions and patterns
96 ^^^^^^^^^^^^^^^^^^^^^^^^
97
98 In its default mode, GHC makes some programs slightly more defined than
99 they should be. For example, consider ::
100
101     f :: [a] -> b -> b
102     f [] = error "urk"
103     f (x:xs) = \v -> v
104
105     main = print (f [] `seq` True)
106
107 This should call ``error`` but actually prints ``True``. Reason: GHC
108 eta-expands ``f`` to
109
110 ::
111
112     f :: [a] -> b -> b
113     f []     v = error "urk"
114     f (x:xs) v = v
115
116 This improves efficiency slightly but significantly for most programs,
117 and is bad for only a few. To suppress this bogus "optimisation" use
118 ``-fpedantic-bottoms``.
119
120 .. _infelicities-decls:
121
122 Declarations and bindings
123 ^^^^^^^^^^^^^^^^^^^^^^^^^
124
125 In its default mode, GHC does not accept datatype contexts, as it has
126 been decided to remove them from the next version of the language
127 standard. This behaviour can be controlled with the ``DatatypeContexts``
128 extension. See :ref:`datatype-contexts`.
129
130 .. _infelicities-recursive-groups:
131
132 Typechecking of recursive binding groups
133 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
134
135 The Haskell Report specifies that a group of bindings (at top level, or
136 in a ``let`` or ``where``) should be sorted into strongly-connected
137 components, and then type-checked in dependency order
138 (`Haskell Report, Section
139 4.5.1 <http://www.haskell.org/onlinereport/decls.html#sect4.5.1>`__). As
140 each group is type-checked, any binders of the group that have an
141 explicit type signature are put in the type environment with the
142 specified polymorphic type, and all others are monomorphic until the
143 group is generalised (`Haskell Report, Section
144 4.5.2 <http://www.haskell.org/onlinereport/decls.html#sect4.5.2>`__).
145
146 Following a suggestion of Mark Jones, in his paper `Typing Haskell in
147 Haskell <https://web.cecs.pdx.edu/~mpj/thih/>`__, GHC implements a
148 more general scheme. In GHC *the dependency analysis ignores references to
149 variables that have an explicit type signature*. As a result of this refined
150 dependency analysis, the dependency groups are smaller, and more bindings will
151 typecheck. For example, consider: ::
152
153       f :: Eq a => a -> Bool
154       f x = (x == x) || g True || g "Yes"
155
156       g y = (y <= y) || f True
157
158 This is rejected by Haskell 98, but under Jones's scheme the definition
159 for ``g`` is typechecked first, separately from that for ``f``, because
160 the reference to ``f`` in ``g``\'s right hand side is ignored by the
161 dependency analysis. Then ``g``\'s type is generalised, to get ::
162
163       g :: Ord a => a -> Bool
164
165 Now, the definition for ``f`` is typechecked, with this type for ``g``
166 in the type environment.
167
168 The same refined dependency analysis also allows the type signatures of
169 mutually-recursive functions to have different contexts, something that is
170 illegal in Haskell 98 (Section 4.5.2, last sentence). GHC only insists that the
171 type signatures of a *refined* group have identical type signatures; in practice
172 this means that only variables bound by the same pattern binding must have the
173 same context. For example, this is fine: ::
174
175       f :: Eq a => a -> Bool
176       f x = (x == x) || g True
177
178       g :: Ord a => a -> Bool
179       g y = (y <= y) || f True
180
181 .. _infelicities-default-exports:
182
183 Default Module headers with -main-is
184 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
185
186 The Haskell2010 Report specifies in <https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-990005.1> that
187
188     "An abbreviated form of module, consisting only of the module body,
189      is permitted. If this is used, the header is assumed to be
190      `module Main(main) where`."
191
192 GHC's ``-main-is`` option can be used to change the name of the top-level entry
193 point from ``main`` to any other variable.  When compiling the main module and
194 ``-main-is`` has been used to rename the default entry point, GHC will also use
195 the alternate name in the default export list.
196
197 Consider the following program: ::
198
199     -- file: Main.hs
200     program :: IO ()
201     program = return ()
202
203 GHC will successfully compile this module with
204 ``ghc -main-is Main.program Main.hs``, because the default export list
205 will include ``program`` rather than ``main``, as the Haskell Report
206 typically requires.
207
208 This change only applies to the main module.  Other modules will still export
209 ``main`` from a default export list, regardless of the ``-main-is`` flag.
210 This allows use of ``-main-is`` with existing modules that export ``main`` via
211 a default export list, even when ``-main-is`` points to a different entry
212 point, as in this example (compiled with ``-main-is MainWrapper.program``). ::
213
214     -- file MainWrapper.hs
215     module MainWrapper where
216     import Main
217
218     program :: IO ()
219     program = putStrLn "Redirecting..." >> main
220
221     -- file Main.hs
222     main :: IO ()
223     main = putStrLn "I am main."
224
225 .. _infelicities-Modules:
226
227 Module system and interface files
228 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
229
230 GHC requires the use of ``hs-boot`` files to cut the recursive loops
231 among mutually recursive modules as described in
232 :ref:`mutual-recursion`. This more of an infelicity than a bug: the
233 Haskell Report says (`Section
234 5.7 <http://haskell.org/onlinereport/modules.html#sect5.7>`__)
235
236     "Depending on the Haskell implementation used, separate compilation of
237     mutually recursive modules may require that imported modules contain
238     additional information so that they may be referenced before they are
239     compiled. Explicit type signatures for all exported values may be
240     necessary to deal with mutual recursion. The precise details of separate
241     compilation are not defined by this Report."
242
243 .. _infelicities-numbers:
244
245 Numbers, basic types, and built-in classes
246 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
247
248 ``Num`` superclasses
249     The ``Num`` class does not have ``Show`` or ``Eq`` superclasses.
250
251
252     You can make code that works with both Haskell98/Haskell2010 and GHC
253     by:
254
255     -  Whenever you make a ``Num`` instance of a type, also make
256         ``Show`` and ``Eq`` instances, and
257
258     -  Whenever you give a function, instance or class a ``Num t``
259         constraint, also give it ``Show t`` and ``Eq t`` constraints.
260
261 ``Bits`` superclass
262     The ``Bits`` class does not have a ``Num`` superclass. It
263     therefore does not have default methods for the ``bit``, ``testBit``
264     and ``popCount`` methods.
265
266     You can make code that works with both Haskell 2010 and GHC by:
267
268     -  Whenever you make a ``Bits`` instance of a type, also make a
269         ``Num`` instance, and
270
271     -  Whenever you give a function, instance or class a ``Bits t``
272         constraint, also give it a ``Num t`` constraint, and
273
274     -  Always define the ``bit``, ``testBit`` and ``popCount`` methods
275         in ``Bits`` instances.
276
277 ``Read`` class methods
278     The ``Read`` class has two extra methods, ``readPrec`` and
279     ``readListPrec``, that are not found in the Haskell 2010 since they rely
280     on the ``ReadPrec`` data type, which requires the :ghc-flag:`-XRankNTypes`
281     extension. GHC also derives ``Read`` instances by implementing ``readPrec``
282     instead of ``readsPrec``, and relies on a default implementation of
283     ``readsPrec`` that is defined in terms of ``readPrec``. GHC adds these two
284     extra methods simply because ``ReadPrec`` is more efficient than ``ReadS``
285     (the type on which ``readsPrec`` is based).
286
287 ``Monad`` superclass
288     The ``Monad`` class has an ``Applicative`` superclass. You cannot write
289     ``Monad`` instances that work for GHC and also for a Haskell 2010
290     implementation that does not define ``Applicative``.
291
292 Extra instances
293     The following extra instances are defined: ::
294
295         instance Functor ((->) r)
296         instance Monad ((->) r)
297         instance Functor ((,) a)
298         instance Functor (Either a)
299         instance Monad (Either e)
300
301 Multiply-defined array elements not checked
302     This code fragment should elicit a fatal error, but it does not: ::
303
304         main = print (array (1,1) [(1,2), (1,3)])
305
306     GHC's implementation of ``array`` takes the value of an array slot
307     from the last (index,value) pair in the list, and does no checking
308     for duplicates. The reason for this is efficiency, pure and simple.
309
310 .. _infelicities-Prelude:
311
312 In ``Prelude`` support
313 ^^^^^^^^^^^^^^^^^^^^^^
314
315 Arbitrary-sized tuples
316     Tuples are currently limited to size 100. However, standard
317     instances for tuples (``Eq``, ``Ord``, ``Bounded``, ``Ix``, ``Read``,
318     and ``Show``) are available *only* up to 16-tuples.
319
320     This limitation is easily subvertible, so please ask if you get
321     stuck on it.
322
323 ``splitAt`` semantics
324     ``Data.List.splitAt`` is more strict than specified in the Report.
325     Specifically, the Report specifies that ::
326
327        splitAt n xs = (take n xs, drop n xs)
328
329     which implies that ::
330
331        splitAt undefined undefined = (undefined, undefined)
332
333     but GHC's implementation is strict in its first argument, so ::
334
335        splitAt undefined [] = undefined
336
337 ``Show``\ ing records
338     The Haskell 2010 definition of ``Show`` stipulates that the rendered
339     string should only include parentheses which are necessary to unambiguously
340     parse the result. For historical reasons, ``Show`` instances derived by GHC
341     include parentheses around records despite the fact that record syntax
342     binds more tightly than function application; e.g., ::
343
344         data Hello = Hello { aField :: Int } deriving (Show)
345
346         -- GHC produces...
347         show (Just (Hello {aField=42})) == "Just (Hello {aField=42})"
348
349         -- whereas Haskell 2010 calls for...
350         show (Just (Hello {aField=42})) == "Just Hello {aField=42}"
351
352 ``Read``\ ing integers
353     GHC's implementation of the ``Read`` class for integral types
354     accepts hexadecimal and octal literals (the code in the Haskell 98
355     report doesn't). So, for example, ::
356
357         read "0xf00" :: Int
358
359     works in GHC.
360
361     A possible reason for this is that ``readLitChar`` accepts hex and
362     octal escapes, so it seems inconsistent not to do so for integers
363     too.
364
365 ``isAlpha``
366     The Haskell 98 definition of ``isAlpha`` is: ::
367
368         isAlpha c = isUpper c || isLower c
369
370     GHC's implementation diverges from the Haskell 98 definition in the
371     sense that Unicode alphabetic characters which are neither upper nor
372     lower case will still be identified as alphabetic by ``isAlpha``.
373
374 ``hGetContents``
375     Lazy I/O throws an exception if an error is encountered, in contrast
376     to the Haskell 98 spec which requires that errors are discarded (see
377     Section 21.2.2 of the Haskell 98 report). The exception thrown is
378     the usual IO exception that would be thrown if the failing IO
379     operation was performed in the IO monad, and can be caught by
380     ``System.IO.Error.catch`` or ``Control.Exception.catch``.
381
382 .. _infelicities-ffi:
383
384 The Foreign Function Interface
385 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
386
387 ``hs_init()``, ``hs_exit()``
388     The FFI spec requires the implementation to support re-initialising
389     itself after being shut down with ``hs_exit()``, but GHC does not
390     currently support that. See :ghc-ticket:`13693`.
391
392     .. index::
393         single: hs_init
394         single: hs_exit
395
396 .. _infelicities-operator-sections:
397
398 Operator sections
399 ^^^^^^^^^^^^^^^^^
400
401 The Haskell Report demands that, for infix operators ``%``, the following
402 identities hold:
403
404 ::
405
406     (% expr) = \x -> x % expr
407     (expr %) = \x -> expr % x
408
409 However, the second law is violated in the presence of undefined operators,
410
411 ::
412
413     (%) = error "urk"
414     (() %)         `seq` () -- urk
415     (\x -> () % x) `seq` () -- OK, result ()
416
417 The operator section is treated like function application of an undefined
418 function, while the lambda form is in WHNF that contains an application of an
419 undefined function.
420
421 .. _haskell-98-2010-undefined:
422
423 GHC's interpretation of undefined behaviour in Haskell 98 and Haskell 2010
424 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
425
426 This section documents GHC's take on various issues that are left
427 undefined or implementation specific in Haskell 98.
428
429 ``Char``
430     .. index::
431        single: Char; size of
432
433     Following the ISO-10646 standard, ``maxBound :: Char`` in GHC is
434     ``0x10FFFF``.
435
436 ``Int``
437     .. index::
438        single: Int; size of
439        single: fromInteger function
440        single: fromIntegral function
441
442     In GHC the ``Int`` type follows the size of an address on the host
443     architecture; in other words it holds 32 bits on a 32-bit machine,
444     and 64-bits on a 64-bit machine.
445
446     Arithmetic on ``Int`` is unchecked for overflowoverflow\ ``Int``, so
447     all operations on ``Int`` happen modulo 2\ :sup:`⟨n⟩` where ⟨n⟩ is
448     the size in bits of the ``Int`` type.
449
450     The ``fromInteger`` (and hence also ``fromIntegral``) is a special case when
451     converting to ``Int``. The value of ``fromIntegral x :: Int`` is
452     given by taking the lower ⟨n⟩ bits of ``(abs x)``, multiplied by the
453     sign of ``x`` (in 2's complement ⟨n⟩-bit arithmetic). This behaviour
454     was chosen so that for example writing ``0xffffffff :: Int``
455     preserves the bit-pattern in the resulting ``Int``.
456
457     Negative literals, such as ``-3``, are specified by (a careful
458     reading of) the Haskell Report as meaning
459     ``Prelude.negate (Prelude.fromInteger 3)``. So ``-2147483648`` means
460     ``negate (fromInteger 2147483648)``. Since ``fromInteger`` takes the
461     lower 32 bits of the representation,
462     ``fromInteger (2147483648::Integer)``, computed at type ``Int`` is
463     ``-2147483648::Int``. The ``negate`` operation then overflows, but
464     it is unchecked, so ``negate (-2147483648::Int)`` is just
465     ``-2147483648``. In short, one can write ``minBound::Int`` as a
466     literal with the expected meaning (but that is not in general
467     guaranteed).
468
469     The ``fromIntegral`` function also preserves bit-patterns when
470     converting between the sized integral types (``Int8``, ``Int16``,
471     ``Int32``, ``Int64`` and the unsigned ``Word`` variants), see the
472     modules ``Data.Int`` and ``Data.Word`` in the library documentation.
473
474 Unchecked floating-point arithmetic
475     Operations on ``Float`` and ``Double`` numbers are *unchecked* for
476     overflow, underflow, and other sad occurrences. (note, however, that
477     some architectures trap floating-point overflow and
478     loss-of-precision and report a floating-point exception, probably
479     terminating the program)
480
481     .. index::
482         single: floating-point exceptions.
483
484 .. _bugs:
485
486 Known bugs or infelicities
487 --------------------------
488
489 The bug tracker lists bugs that have been reported in GHC but not yet
490 fixed: see the `GHC issue tracker <https://gitlab.haskell.org/ghc/ghc/issues>`__. In
491 addition to those, GHC also has the following known bugs or
492 infelicities. These bugs are more permanent; it is unlikely that any of
493 them will be fixed in the short term.
494
495 .. _bugs-ghc:
496
497 Bugs in GHC
498 ~~~~~~~~~~~
499
500 -  GHC's runtime system implements cooperative multitasking, with
501    context switching potentially occurring only when a program
502    allocates. This means that programs that do not allocate may never
503    context switch. This is especially true of programs using STM, which
504    may deadlock after observing inconsistent state. See :ghc-ticket:`367`
505    for further discussion.
506
507    If you are hit by this, you may want to compile the affected module
508    with :ghc-flag:`-fno-omit-yields <-fomit-yields>` (see :ref:`options-f`).
509    This flag ensures that yield points are inserted at every function entrypoint
510    (at the expense of a bit of performance).
511
512 -  GHC does not allow you to have a data type with a context that
513    mentions type variables that are not data type parameters. For
514    example:
515
516    ::
517
518          data C a b => T a = MkT a
519
520    so that ``MkT``\'s type is
521
522    ::
523
524          MkT :: forall a b. C a b => a -> T a
525
526    In principle, with a suitable class declaration with a functional
527    dependency, it's possible that this type is not ambiguous; but GHC
528    nevertheless rejects it. The type variables mentioned in the context
529    of the data type declaration must be among the type parameters of the
530    data type.
531
532 -  GHC's inliner can be persuaded into non-termination using the
533    standard way to encode recursion via a data type:
534
535    ::
536
537          data U = MkU (U -> Bool)
538
539          russel :: U -> Bool
540          russel u@(MkU p) = not $ p u
541
542          x :: Bool
543          x = russel (MkU russel)
544
545    The non-termination is reported like this:
546
547    .. code-block:: none
548
549        ghc: panic! (the 'impossible' happened)
550          (GHC version 8.2.1 for x86_64-unknown-linux):
551            Simplifier ticks exhausted
552          When trying UnfoldingDone x_alB
553          To increase the limit, use -fsimpl-tick-factor=N (default 100)
554
555    with the panic being reported no matter how high a
556    :ghc-flag:`-fsimpl-tick-factor` you supply.
557
558    We have never found another class of programs, other than this
559    contrived one, that makes GHC diverge, and fixing the problem would
560    impose an extra overhead on every compilation. So the bug remains
561    un-fixed. There is more background in `Secrets of the GHC
562    inliner <http://research.microsoft.com/~simonpj/Papers/inlining/>`__.
563
564 -  On 32-bit x86 platforms when using the native code generator, the
565    :ghc-flag:`-fexcess-precision` option is always on.
566    This means that floating-point calculations are non-deterministic,
567    because depending on how the program is compiled (optimisation
568    settings, for example), certain calculations might be done at 80-bit
569    precision instead of the intended 32-bit or 64-bit precision.
570    Floating-point results may differ when optimisation is turned on. In
571    the worst case, referential transparency is violated, because for
572    example ``let x = E1 in E2`` can evaluate to a different value than
573    ``E2[E1/x]``.
574
575    .. index::
576       single: -msse2 option
577
578    One workaround is to use the :ghc-flag:`-msse2` option (see
579    :ref:`options-platform`), which generates code to use the SSE2
580    instruction set instead of the x87 instruction set. SSE2 code uses
581    the correct precision for all floating-point operations, and so gives
582    deterministic results. However, note that this only works with
583    processors that support SSE2 (Intel Pentium 4 or AMD Athlon 64 and
584    later), which is why the option is not enabled by default. The
585    libraries that come with GHC are probably built without this option,
586    unless you built GHC yourself.
587
588 -  The :ghc-flag:`state hack <-fstate-hack>` optimization can result in
589    non-obvious changes in evaluation ordering which may hide exceptions, even
590    with :ghc-flag:`-fpedantic-bottoms` (see, e.g., :ghc-ticket:`7411`). For
591    instance, ::
592
593      import Control.Exception
594      import Control.DeepSeq
595      main = do
596          evaluate (('a' : undefined) `deepseq` return () :: IO ())
597          putStrLn "Hello"
598
599    Compiling this program with ``-O`` results in ``Hello`` to be printed,
600    despite the fact that ``evaluate`` should have bottomed. Compiling
601    with ``-O -fno-state-hack`` results in the exception one would expect.
602
603 -  Programs compiled with :ghc-flag:`-fdefer-type-errors` may fail a bit
604    more eagerly than one might expect. For instance, ::
605
606      {-# OPTIONS_GHC -fdefer-type-errors #-}
607      main = do
608        putStrLn "Hi there."
609        putStrLn True
610
611    Will emit no output, despite the fact that the ill-typed term appears
612    after the well-typed ``putStrLn "Hi there."``. See :ghc-ticket:`11197`.
613
614 -  Despite appearances ``*`` and ``Constraint`` aren't really distinct kinds
615    in the compiler's internal representation and can be unified producing
616    unexpected results. See :ghc-ticket:`11715` for one example.
617
618 -  Because of a toolchain limitation we are unable to support full Unicode paths
619    on Windows. On Windows we support up to Latin-1. See :ghc-ticket:`12971` for more.
620
621 .. _bugs-ghci:
622
623 Bugs in GHCi (the interactive GHC)
624 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
625
626 -  GHCi does not respect the ``default`` declaration in the module whose
627    scope you are in. Instead, for expressions typed at the command line,
628    you always get the default default-type behaviour; that is,
629    ``default(Int,Double)``.
630
631    It would be better for GHCi to record what the default settings in
632    each module are, and use those of the 'current' module (whatever that
633    is).
634
635 -  On Windows, there's a GNU ld/BFD bug whereby it emits bogus PE object
636    files that have more than 0xffff relocations. When GHCi tries to load
637    a package affected by this bug, you get an error message of the form
638
639    .. code-block:: none
640
641        Loading package javavm ... linking ... WARNING: Overflown relocation field (# relocs found: 30765)
642
643    The last time we looked, this bug still wasn't fixed in the BFD
644    codebase, and there wasn't any noticeable interest in fixing it when
645    we reported the bug back in 2001 or so.
646
647    The workaround is to split up the .o files that make up your package
648    into two or more .o's, along the lines of how the ``base`` package does
649    it.