Custom Query (7504 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 7504)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#22 Invalid import leakage nobody cwitty
Description
When I compile with ghc --make, sometimes imports from
one module "leak" into the imports list (in the .hi
file) of another, unrelated module that was compiled later.

For example:
Point.lhs is the following file:
\begin{code}
module Point (
         module PointClass, module Point1, module Point2, 
         module Point3, module Point4, module PointN,
module Point
       ) where

import PointClass
import Point1
import Point2
import Point3
import Point4
import PointN
\end{code}

In one particular ghc run, files were compiled like this:
Skipping  PointClass       (
/sc/downloads/GeomAlgLib/haskell/PointClass.lhs,
/sc/downloads/GeomAlgLib/haskell/PointClass.o )
Skipping  Point1           (
/sc/downloads/GeomAlgLib/haskell/Point1.lhs,
/sc/downloads/GeomAlgLib/haskell/Point1.o )
Skipping  Point2           (
/sc/downloads/GeomAlgLib/haskell/Point2.lhs,
/sc/downloads/GeomAlgLib/haskell/Point2.o )
Skipping  Point3           (
/sc/downloads/GeomAlgLib/haskell/Point3.lhs,
/sc/downloads/GeomAlgLib/haskell/Point3.o )
Skipping  PointN           (
/sc/downloads/GeomAlgLib/haskell/PointN.lhs,
/sc/downloads/GeomAlgLib/haskell/PointN.o )
Skipping  Point4           (
/sc/downloads/GeomAlgLib/haskell/Point4.lhs,
/sc/downloads/GeomAlgLib/haskell/Point4.o )
Skipping  GLExtra          ( GLExtra.hs, GLExtra.o )
Skipping  GtkExtra         ( GtkExtra.hs, GtkExtra.o )
Compiling Point            (
/sc/downloads/GeomAlgLib/haskell/Point.lhs,
/sc/downloads/GeomAlgLib/haskell/Point.o )

None of the Point* modules depend on GdkPixmap (as
verified by looking in their .hi files), but GtkExtra
does.  After this run, Point.hi contains the line
import GdkPixmap !;
(This means that subsequent compiles of different
programs using Point will fail, since they don't have
the right compiler flags to find GdkPixmap.hi.)
System information:
Linux nebula 2.4.9-686 #1 Sun Aug 19 10:46:52 EST 2001
i686 unknown
gcc version 2.95.4 20011006 (Debian prerelease)

I am attaching a transcript of a compile run using -v.
#23 None fundep bug across module boundary nobody nobody
Description
Consider these two files:

BugImport.hs

module BugImport where
import IOExts

class Monad m => RefMonad m r | m -> r where
  newRef :: a -> m (r a)
  readRef :: r a -> m a
  writeRef :: r a -> a -> m ()

instance RefMonad IO IORef where
  newRef = newIORef
  readRef = readIORef
  writeRef = writeIORef

Bug.hs

import IOExts
import BugImport

foo () = do r <- newRef 1
               readRef r

main = do i <- foo ()
              print i

The type of foo is 

(RefMonad m r, Num a) => () -> m a

so the fundep is needed to resolve the overloading. Bug
ghc complains:

Ambiguous type variable(s) 'r' in the constraint
`RefMonad IO r'
arising from use of `foo' at Bug.hs:7
In a do statement: i <- foo ()

i.e. the fundep is lost. This is compiled with
ghc5.02.1, -package 
lang, -fglasgow-exts.

If all the definitions are placed in one module, on the
other hand,
then compilation succeeds. Alternatively, if these two
modules are
loaded into ghci, then they are accepted.
#24 Fixed dlopen() errors reported badly nobody cwitty
Description
(BTW, shouldn't there be a category in the sourceforge
bug-reporting page for "ghci"?)

ghci reports all dlopen() errors as "Can't find
(dynamic) ...".  This misleading error message wasted
quite a bit of my time trying to figure out why it
couldn't find the library that was "right there".

For example:
galaxy% ghci -lXpm
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version
5.02, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package std ... linking ... done.
Loading object (dynamic) Xpm ... failed.
Can't find (dynamic) Xpm in directories:
ghc-5.02: user specified .o/.so/.DLL could not be
loaded.
galaxy%

ghci reported that it couldn't find a dynamic libXpm. 
However, a little peeking with ltrace reveals the real
problem:

galaxy% ltrace -e 'dlerror,dlopen' -s 300 
/usr/lib/ghc-5.02/ghc-5.02 -B/usr/lib/ghc-5.02
--interactive -lXpm
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version
5.02, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

dlopen(NULL, 1)                                   =
0x400153d8
Loading package std ... --- SIGVTALRM (Virtual timer
expired) ---
--- SIGVTALRM (Virtual timer expired) ---
linking ... --- SIGVTALRM (Virtual timer expired) ---
--- SIGVTALRM (Virtual timer expired) ---
--- SIGVTALRM (Virtual timer expired) ---
--- SIGVTALRM (Virtual timer expired) ---
done.
Loading object (dynamic) Xpm ... dlopen("libXpm.so",
258)                          = NULL
dlerror()                                         =
"/usr/X11R6/lib/libXpm.so: undefined symbol:
XDefaultScreen"
failed.
Can't find (dynamic) Xpm in directories:
ghc-5.02: user specified .o/.so/.DLL could not be
loaded.

Armed with the real error message from dlerror()
("undefined symbol: XDefaultScreen"), I can deduce that
I really need to use -lX11 as well.

galaxy% ghci -lXpm -lX11
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version
5.02, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package std ... linking ... done.
Loading object (dynamic) X11 ... done
Loading object (dynamic) Xpm ... done
final link ... done.
Prelude> 

As expected, this works fine.

galaxy% uname -a
Linux galaxy 2.4.14-pre6 #1 Thu Nov 1 02:23:35 PST 2001
i686 unknown
galaxy% gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011006 (Debian prerelease)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.