[GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2007-04-21 Thread GHC
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
---+
Reporter:  [EMAIL PROTECTED]  |   Owner:
 
Type:  bug |  Status:  new  
  
Priority:  high|   Milestone:   
  
   Component:  GHCi| Version:  6.6  
  
Severity:  critical|Keywords:  ghci foreign ffi dll import 
stdcall
  Difficulty:  Moderate (1 day)|Testcase:   
  
Architecture:  x86 |  Os:  Windows  
  
---+
'''ghci 6.6 foreign import stdcall broken, panic, panic'''

 I would like to report what I think is a problem with GHCI foreign
 function imports
 of c functions declared with stdcall calling convention (1) and also with
 loading objects containing dll imports (2).

 = WHAT IS THE PROBLEM ? =

 == 1. ghci handling of mangling of stdcall function names broken ==
 {{{
 Prelude :load htest3
 [1 of 1] Compiling Main ( htest3.hs, interpreted )

 During interactive linking, GHCi couldn't find the following symbol:
   test
 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
 }}}

 == 2. ghci loading of c object files dll imports name resolution broken ==
 {{{
 ghci -fglasgow-exts test_proxy5a.o -ltest3b

 test_proxy5a.o: unknown symbol `__imp__test'
 final link ... : linking extra libraries/objects failed

 }}}

 detail follows ...

 = CONCLUSSION REACHED =

 == 1. Importing Stdcall Symbols ==

 ghci dose not correctly look for symbols decorated in the stdcall manner
 in the
 object files ie. it looks for '''_test''' when it should (according to
 stdcall convention) look for '''[EMAIL PROTECTED]'''.

 stdcall symbols in object files are decorated with the number of bytes
 that should
 be popped from the stack before the function returns.

 == 2. linking objects with dllimports ==

 ghci cannot properly resolve dllimports in c object files i.e. if an
 object loaded by ghci
 (eg test_proxy, with c function test_proxy) calls functions from a dll (eg
 '''test''') then
 that function in the object file will be decorated as '''`__imp__test`'''
 this in normal course linked agains a .lib or a .a file will be resolved
 to '''_test'''
 function in the dll but ghci does not do this.

 Offcourse these problems go away when using ghc ... but well what's the
 point of ghci then?

 = SUMMARY OF TESTS and METHODOLOGY =

 == 1. Reference Case ==

 verify that ccall works ..
   [[BR]]Create c file test1a.c and function test(int) in the file
   [[BR]]create haskell file htest1.hs with function ctest calling test
   [[BR]]check this works ok with

   a. c object loaded (test1a.c, htest1.hs )-- OK, RIGHT [[BR]]
   b. windows dll, c is function a dll export  (test1b.c, htest1.hs ) --
 OK, RIGHT

 == 3. change calling convention to stdcall ==

   a. check loading of function from object (test3a.c, htest3.hs) -- FAIL,
 WRONG[[BR]]
   b. check loading of stdcall function from dll -- FAIL, WRONG

 == 4. try what shouldn't work ==

   a. htest3 against object test1a
  i.e. what hapens when you try loading a haskell module with foreign
 import stdcall against c function declared with ccall convention.

  ghci loaded -- OK!!, WRONG,

  it should not have resolved the symbol and not loaded.[[BR]]
  ghci called the function and crashed -- given that it resolved the
 symbol and called the function, this is expected.

   b. htest3 against dll htest1b.dll
  same result as 4a -- expected,

 behaviour consistent in both cases with resolving stdcall callouts
 (symbol '''test''') in a manner consistent with ccalls.
 i.e. resolving the call to c function '''test''' as a call to symbol
 '''_test'''
 rather than '''[EMAIL PROTECTED]''' as it should be according to the stdcall
 convention.

 yet the function is called as a stdcall c function, consequently ghci
 crashes when
 the ccall function returns and the stack has not been cleared of the
 function arguments, as is required by the stdcall convention.

 == 5. Lets try a proxy function/object ==

 Hmm, lets see what happens when we have a ccall c proxy function calling
 stdcall c
 function in dll etc?

   a. test_proxy5a.o with test3b.dll
  ccall function calling stdcall function in dll
  {{{
unknown symbol __imp__test
  }}}

  FAILED, 

Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2007-04-21 Thread GHC
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
 Reporter:  [EMAIL PROTECTED]   |  Owner:   
   
 Type:  bug  | Status:  new 

 Priority:  high |  Milestone:  

Component:  GHCi |Version:  6.6 

 Severity:  critical | Resolution:  

 Keywords:  ghci foreign ffi dll import stdcall  | Difficulty:  Moderate (1 
day)
 Testcase:   |   Architecture:  x86 

   Os:  Windows  |  
-+--
Comment (by [EMAIL PROTECTED]):

 error in transcription, the above should read...

 === test_proxy5b.c ===

 {{{
 #include stdio.h

 extern void _stdcall test(int arg);

 void test_proxy(int arg)
 {
test(arg);
 }
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2007-04-21 Thread GHC
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
 Reporter:  [EMAIL PROTECTED]   |  Owner:   
   
 Type:  bug  | Status:  new 

 Priority:  high |  Milestone:  

Component:  GHCi |Version:  6.6 

 Severity:  critical | Resolution:  

 Keywords:  ghci foreign ffi dll import stdcall  | Difficulty:  Moderate (1 
day)
 Testcase:   |   Architecture:  x86 

   Os:  Windows  |  
-+--
Comment (by guest):

 appon reflection 5c of above ...

   hey this has me stumped test_proxy5b.o imports symbol [EMAIL PROTECTED]
 test1b.dll exports symbol _test hmmm how is the symbol [EMAIL PROTECTED] 
resolved
 ??? why isn't the stack corrupted when test is called ??? MYSTERY ???


 if ghci is doing the linking and uses the same name resolution to resolve
 these names i.e. '''[EMAIL PROTECTED]''' is dropping the '''@4''' to get 
'''_test'''
 then it would make sense that linking is successful. But why dosn't it
 crash when called?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2007-04-21 Thread GHC
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
 Reporter:  [EMAIL PROTECTED]   |  Owner:   
   
 Type:  bug  | Status:  new 

 Priority:  high |  Milestone:  

Component:  GHCi |Version:  6.6 

 Severity:  critical | Resolution:  

 Keywords:  ghci foreign ffi dll import stdcall  | Difficulty:  Moderate (1 
day)
 Testcase:   |   Architecture:  x86 

   Os:  Windows  |  
-+--
Comment (by [EMAIL PROTECTED]):

 in preceeding comment ... but if this is the case '''[EMAIL PROTECTED]''' 
should not
 successfully link against '''[EMAIL PROTECTED]''' in test5b. Hmmm, Mystery ???

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


ghci problems linking to stdc++

2007-04-21 Thread Frederik Eaton
Hello,

I have a package which links to several libraries, which I have built
with Cabal. I can use it to compile executables:

$ ghc -package vectro --make Vector/Sparse/subvec-example.hs -o sve
Linking sve ...

And the library references in those executables are correct:

$ /lib/ld-2.5.so --list ./sve
linux-gate.so.1 =  (0xe000)
libgsl.so.0 = /usr/lib/libgsl.so.0 (0xa7dc2000)
libcblas.so.3 = /usr/lib/libcblas.so.3 (0xa7ae3000)
libatlas.so.3 = /usr/lib/libatlas.so.3 (0xa77b6000)
liblapack.so.3 = /usr/lib/atlas/liblapack.so.3 (0xa7166000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xa7081000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xa707d000)
libX11.so.6 = /usr/lib/libX11.so.6 (0xa6f91000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xa6f6b000)
librt.so.1 = /lib/i686/cmov/librt.so.1 (0xa6f61000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xa6f56000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xa6e15000)
libblas.so.3 = /usr/lib/atlas/libblas.so.3 (0xa6ab6000)
libg2c.so.0 = /usr/lib/libg2c.so.0 (0xa6a8e000)
/lib/ld-linux.so.2 = /lib/ld-2.5.so (0x7000)
libXau.so.6 = /usr/lib/libXau.so.6 (0xa6a8a000)
libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xa6a85000)
libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xa6a6e000)

However, when I load the package in ghci, I have some problems:

$ ghci -package vectro
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.6.20070420, for Haskell 
98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.
Loading package base ... linking ... done.
Loading package mtl-1.0 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package X11-1.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package stm-2.0 ... linking ... done.
Loading package parsec-2.0 ... linking ... done.
Loading package network-2.0 ... linking ... done.
Loading package futility-base-0.1.9 ... linking ... done.
Loading package unix-1.0 ... linking ... done.
Loading package futility-unix-0.1.9 ... linking ... done.
Loading package vectro-0.2 ... ghc-6.6.20070420: can't load .so/.DLL for: 
stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)

How do I tell ghci to find stdc++ (etc.) in the same place that ld.so
finds it?

Thanks,

Frederik

-- 
http://ofb.net/~frederik/
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs