RE: problems using ghc-6.6.1 (due to fgl-5.4.1)
Aha! So the problem is a library change rather than a compiler change. That's a relief. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Christian Maeder | Sent: 08 May 2007 22:33 | To: [EMAIL PROTECTED]; GHC Users Mailing List; [EMAIL PROTECTED] | Subject: problems using ghc-6.6.1 (due to fgl-5.4.1) | | I wrote: | Dear Hets- and GHC-Developers, | | we have a problem using ghc-6.6.1. The created hets binary runs a | couple | of times slower than the one created using ghc-6.6. | | This problem is gone when I install and use fgl-5.3 (where hiding | (indices) needs to be deleted in Data.Graph.Inductive.Monad.IOArray). | | I strongly suspect the new functions context1l' and context4l' in | Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic | slow down. | | In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic | edge (an edge from and to the very same node) was only returned as | ingoing edge and not as outgoing one. (a design decision documented | elsewhere). | | I think, the change in fgl-5.4.1 now returns a cyclic edge also as | outgoing edge (and possibly twice as ingoing one). | | Our application heavily uses in- and outgoing edges that may be cyclic. | | Christian | | P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
So to summarise, the following are missing from the binary distribution that Neil used as the basis for his installer: * readline * ALUT * OpenAL * GLUT * C++ support in the bundled GCC right? I can try to roll another binary distribution, but I don't know much about these packages or C++ support so I'm guessing a bit. shelarcy wrote: You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. This is well-known problem, if build GHC your self. Because MInGW doesn't have these headers and library files in its directory. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011253.html http://www.haskell.org/pipermail/haskell/2006-December/018919.html So you must copy these files from old GHC's directory first, and then building new GHC. That sounds scary - what about incompatible versions? There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. http://hackage.haskell.org/trac/ghc/ticket/1024 http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/thread.html#12408 The reason I didn't enable C++ support in prep-bin-dist-mingw is because of that comment, and because I don't know how to test it. Basically I chickened out. Are you saying it should just be uncommented in prep-bin-dist-mingw? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
shelarcy wrote: GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. Custom/complete: yes, typical: no. What on earth does typical mean? The user has no idea whether it will install the features they need or not, so it's a meaningless option. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. Custom/complete: yes, typical: no. What on earth does typical mean? The user has no idea whether it will install the features they need or not, so it's a meaningless option. From all I can tell, GHC 6.6 has all these options, but they all do the same thing! If you select custom you can choose whether or not to install GHC, but thats as fine-grained as the control gets. The options I was thinking off were: * GHC (always required) * Profiling libraries * HTML documentation * Register .hs and .lhs extensions * Set the GHC %PATH% * Set the Cabal %PATH% With the Complete (recommended and default) install being all of them, Minimal (lacking HTML and profiling) and custom for anything else. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SMP question
Cristian Perfumo wrote: Some days ago I sent an email to the list asking about the reason why I couldn't run my programs with the -Nx RTS option even if I compiled them with -threaded. AH! by the way, the architecture is ia64 (Itanium). Today I realized that when I ./configure, a preprocessor variable called NOSMP is defined and it disallows the multiple OS threads (the -Nx option). Looking a bit deeper I figured out that there's no Itanium version for the functions xchg (exchange), cas (compare-and-swap) and write_barrier in the header file SMP.h (includes/SMP.h) so there's no way that the holy -N option is available. My question is: is it enough to implement xchg, cas and write_barrier for ia64 to make multiple OSthreads available on ia64? If not, what else should be implemented/changed? Yes, that should be enough. The main concern is that on architectures that don't have strong memory ordering, that the thunk update sequence is safe. See section 3.3: http://www.haskell.org/~simonmar/papers/multiproc.pdf At the moment the update code contains a memory barrier, which compiles to nothing on x86/x86_64 (see SMP.h:write_barrier()). You should check that this doesn't impose a significant performance penalty on ia64: try one of the benchmarks that does a lot of updates (e.g. nofib/imaginary/exp3_8) with and without -threaded. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems using ghc-6.6.1
Christian Maeder wrote: Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? Cheers, Simon Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_signCASL.Sublogic 5.33.7 compInclusion Logic.Grothendieck 3.23.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.51.6 isSubOpMap CASL.Sign 1.20.9 primCoerce Logic.Coerce 0.81.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_signCASL.Sublogic 6.84.2 compInclusion Logic.Grothendieck 3.73.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.83.1 isSubOpMap CASL.Sign 1.61.1 sublogics_join CASL.Sublogic 1.51.1 primCoerce Logic.Coerce 1.31.4 isSameTranslation Proofs.Local 1.20.9 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems using ghc-6.6.1
Simon Marlow schrieb: Christian Maeder wrote: Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? -O was turned off in both cases. (Optimization usually only accounts for a factor of 3 -- and not 8 or even more.) Sorry for my panic. The slow down is caused by the last change described in http://web.engr.oregonstate.edu/~erwig/fgl/haskell/CHANGES The additional loops in Data.Graph.Inductive.Graph (also added at the end of a possibly long list) make our algorithm slower. context1l' :: Context a b - Adj b context1l' (p,v,_,s) = p++filter ((==v).snd) s context4l' :: Context a b - Adj b context4l' (p,v,_,s) = s++filter ((==v).snd) p Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SMP question
Simon: (first of all: thank you for the information. As soon as we have it working we will try that application in nofib to see what happens) We already implemented those synchronization functions for ia64 architecture and we have a problem related with base register (find output below). The questions that arose: 1) What is the REG_Base? 2) Do we need it for ia64? 3) In case we need it, which machine register should we use? Thank you very much in advance for any information. Cristian Perfumo == make way=thr all; PWD = /.../ghc-6.6.1/rts ../compiler/ghc-inplace -H16m -O -optc-O2 -static -I. -#include HCIncludes.h-fvia-C -dcmm-lint -hisuf thr_hi -hcsuf thr_hc -osuf thr_o -optc-DTHREADED_RTS -c Apply.cmm -o Apply.thr_o In file included from /.../ghc- 6.6.1/includes/Stg.h:148, from /tmp/ghc1736_0/ghc1736_0.thr_hc:3:0: /scratch/Computacional/adrian/nehir/ghc-6.6.1/includes/Regs.h:353:2: error: #error BaseReg must be in a register for THREADED_RTS /tmp/ghc1736_0/ghc1736_0.thr_hc: In function 'stg_AP_entry': /tmp/ghc1736_0/ghc1736_0.thr_hc:196:0: error: 'MainCapability' undeclared (first use in this function) /tmp/ghc1736_0/ghc1736_0.thr_hc:196:0: error: (Each undeclared identifier is reported only once /tmp/ghc1736_0/ghc1736_0.thr_hc:196:0: error: for each function it appears in.) /tmp/ghc1736_0/ghc1736_0.thr_hc: In function 'stg_AP_STACK_entry': /tmp/ghc1736_0/ghc1736_0.thr_hc:253:0: error: 'MainCapability' undeclared (first use in this function) make[2]: *** [Apply.thr_o] Error 1 make[1]: *** [all] Error 1 make: *** [stage1] Error 1 On 5/9/07, Simon Marlow [EMAIL PROTECTED] wrote: Cristian Perfumo wrote: Some days ago I sent an email to the list asking about the reason why I couldn't run my programs with the -Nx RTS option even if I compiled them with -threaded. AH! by the way, the architecture is ia64 (Itanium). Today I realized that when I ./configure, a preprocessor variable called NOSMP is defined and it disallows the multiple OS threads (the -Nx option). Looking a bit deeper I figured out that there's no Itanium version for the functions xchg (exchange), cas (compare-and-swap) and write_barrier in the header file SMP.h (includes/SMP.h) so there's no way that the holy -N option is available. My question is: is it enough to implement xchg, cas and write_barrier for ia64 to make multiple OSthreads available on ia64? If not, what else should be implemented/changed? Yes, that should be enough. The main concern is that on architectures that don't have strong memory ordering, that the thunk update sequence is safe. See section 3.3: http://www.haskell.org/~simonmar/papers/multiproc.pdfhttp://www.haskell.org/%7Esimonmar/papers/multiproc.pdf At the moment the update code contains a memory barrier, which compiles to nothing on x86/x86_64 (see SMP.h:write_barrier()). You should check that this doesn't impose a significant performance penalty on ia64: try one of the benchmarks that does a lot of updates (e.g. nofib/imaginary/exp3_8) with and without -threaded. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Sparc/Intel Solaris support
How well is ghc supported on newer versions of Sparc/Intel Solaris? Thanks, Joel -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC as a library - getting output from GHCI
On Fri, May 04, 2007 at 08:12:55PM +0200, Pepe Iborra wrote: Mads On 04/05/2007, at 19:19, Mads Lindstr?m wrote: Hi Pepe I would have liked something cross-platform. Take a look at the unix-compat[1] package by Bjorn Bringert, although it looks like it won't help you. Maybe it can be extended. I'm attempting to do the same thing. But I don't see how wrapStmt can be implemented with System.Posix.Process. Documentation doesn't seem to indicate any function that deals with Handles, or returns Strings. I am unfamiliar with that module however. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC as a library - getting output from GHCI
Hi Look at System.Posix.IO I do not know if that module can do what you want. But it does deal with FileDescriptors and handles. Maybe the dup function can help you. According to http://www2.lib.uchicago.edu/~keith//tcl-course/topics/processes.html it does: The dup implements the dup system call, which duplicates one desired open file descriptor into another. This can be used connect standard input or standard output to a pipe. This sample code shows how a parent process can fork the standard Unix sort command and then feed it data to be sorted. A simple extension would allow the child to write the results back to the parent. But I have not tested it yet, and I am not really familiar with Unix inter-process communication. Greetings, Mads Matthew Danish wrote: On Fri, May 04, 2007 at 08:12:55PM +0200, Pepe Iborra wrote: Mads On 04/05/2007, at 19:19, Mads Lindstr?m wrote: Hi Pepe I would have liked something cross-platform. Take a look at the unix-compat[1] package by Bjorn Bringert, although it looks like it won't help you. Maybe it can be extended. I'm attempting to do the same thing. But I don't see how wrapStmt can be implemented with System.Posix.Process. Documentation doesn't seem to indicate any function that deals with Handles, or returns Strings. I am unfamiliar with that module however. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC as a library - getting output from GHCI
Hi Simon The Interactive.hs program do not really redirect stdout. It intercepts calls to putStrLn and getLine via let definitions: mustWork let putStrLn = MyPrelude.myPutStrLn mustWork let getLine = MyPrelude.myGetLine -- mustWork either runs the given statement successfully or triggers an error where mustWork stmt = do result - GHC.runStmt session stmt if isOk result then return () else error replaceFunctions failed. Thus, if GHCi's print loop is not within the context of the let definitions, it will not use myPutStrLn and myGetLine. If I run the Interactive.hs program on my Debian/Linux box, and write 3+4 then its printed directly to standard output. It does not use myPutStrLn function. Also if stmt = SomeModule.prettyPrinter foobar and SomeModule contains prettyPrinter x = putStrLn $ Pretty: ++ x then the let binding will not catch it. Thus we have two problems. One is output from evaluating expressions (like 3+2), and another is output from a user module not affected by the let-binding above. Therefore a better solution is to run GHC as a library in a separate process, from which we read/write stdin, stdout, and stderr. I am exploring several different options for running processes in Haskell, but the only useful (for this particular purpose) seems to be the Unix-only System.Posix.Process. I could also use System.Process.runInteractiveCommand, which gives me handles for stdin, stdout, stderr. But it does not seem possible to add additional channels. Therefore control information (like getModuleGraph, runStmt, or getBindings) must also go though stdin/stdout. It seems very problematic to have control information, send though the same channel as the input/output from running runStmt. For one thing the output from runStmt can contain arbitrary data, and could therefore resemble control information. Secondly, I could use Control.Concurrent. But this do not allow me to redirect stdout, stderr or stdin. Greetings, Mads Simon Peyton-Jones wrote: | I am trying to use GHC as a library (see | http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the | output from an interactive session and put in a GUI. This | http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a | nice starting point. If you want to collect *all* the output, that presumably includes the output of printing to 'stdout'? That is, if I type putStr Hello I see the result. If you manage to redirect stdout in this way, I think you will also see the value of your 'stmt', because what GHC does is to compile a little (print it) stmt and run it. It's a while since I looked at the Interactive loop, but I think that's right. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC as a library - getting output from GHCI
On Wed, May 09, 2007 at 10:48:15PM +0200, Mads Lindstr?m wrote: Hi Look at System.Posix.IO I do not know if that module can do what you want. But it does deal with FileDescriptors and handles. Maybe the dup function can help you. According to http://www2.lib.uchicago.edu/~keith//tcl-course/topics/processes.html it does: The dup implements the dup system call, which duplicates one desired open file descriptor into another. This can be used connect standard input or standard output to a pipe. This sample code shows how a parent process can fork the standard Unix sort command and then feed it data to be sorted. A simple extension would allow the child to write the results back to the parent. But I have not tested it yet, and I am not really familiar with Unix inter-process communication. Right, good thinking. This is what I've come up with for Unix-only: module WrapIO where import System.IO import System.Posix.IO import Control.Exception wrapIO :: IO a - IO (a, String) wrapIO action = do oldStdOutput - dup stdOutput (rd, wr) - createPipe dupTo wr stdOutput v - action h - fdToHandle rd closeFd wr s - hGetContents h return (v, s) `finally` do dupTo oldStdOutput stdOutput closeFd oldStdOutput Unfortunately, dupTo will not work on Win32 afaik. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC as a library - getting output from GHCI
Hi While wrapIO works in most cases, try running this: :m +Control.Concurrent forkIO (let foo = do threadDelay 100; print A; foo in foo) I am not saying that this makes wrapIO unusable - just that it is not bulletproof. If not using forkIO is ok, then this is a much easier solution, than creating a separate process for running GHC as a library - that is having the GUI in one process and having GHC as a library in a child process. Greetings, Mads Matthew Danish wrote: On Wed, May 09, 2007 at 10:48:15PM +0200, Mads Lindstr?m wrote: Hi Look at System.Posix.IO I do not know if that module can do what you want. But it does deal with FileDescriptors and handles. Maybe the dup function can help you. According to http://www2.lib.uchicago.edu/~keith//tcl-course/topics/processes.html it does: The dup implements the dup system call, which duplicates one desired open file descriptor into another. This can be used connect standard input or standard output to a pipe. This sample code shows how a parent process can fork the standard Unix sort command and then feed it data to be sorted. A simple extension would allow the child to write the results back to the parent. But I have not tested it yet, and I am not really familiar with Unix inter-process communication. Right, good thinking. This is what I've come up with for Unix-only: module WrapIO where import System.IO import System.Posix.IO import Control.Exception wrapIO :: IO a - IO (a, String) wrapIO action = do oldStdOutput - dup stdOutput (rd, wr) - createPipe dupTo wr stdOutput v - action h - fdToHandle rd closeFd wr s - hGetContents h return (v, s) `finally` do dupTo oldStdOutput stdOutput closeFd oldStdOutput Unfortunately, dupTo will not work on Win32 afaik. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 win32 msi available
[My apologies for the long'ish e-mail, for Win9x users mostly..] Someone sent an e-mail querying about Win9x compatibility, which is something I forgot to take into account when building the 6.6.1 installer. To remedy, I've refreshed the installer to include a new version that ought to work across a wider spectrum of MS OS versions releases -- http://galois.com/~sof/msi/ghc-6-6-1.msi Notice that since the GHC binary is now being linked with a 'threaded' RTS, some non-Win9x compatible portions of the Win32 API is being used depended upon, causing DLL resolution at startup to miserably fail. To counter and workaround this, I've included bin/ghc-u.exe with the refreshed installer, which is an unthreaded (and faster..) version of the compiler (= GHCi.) So, to get a working system under Win9x, you'll need to either use ghc-u directly, or rename it as ghc.exe (and, as a result, enable 'ghci.exe' usage.) Also, as with ghc-6.6, if you intend to distribute your 6.6.1-compiled code that uses the Win32 package, and have it work on Win9x platforms, you'll need to include the Unicode API layer DLL, which you'll find in bin/ as unicows.dll hth --sigbjorn On 5/8/2007 15:25, Sigbjorn Finne wrote: In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
dynamic linking with stdc++ (was: Re: ghci dynamic linking)
On Fri, Apr 27, 2007 at 11:01:49AM +0100, Simon Marlow wrote:
Frederik Eaton wrote:
Hello,
I am wondering how to link a package with some dynamic libraries in a
way that works with ghci. If I run the command
LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage
then it is successful; I am able to use package mypackage in ghci. But
if I omit the LD_PRELOAD=... part then ghci complains about missing
symbols. How do I configure my package so that the LD_PRELOAD=... part
of the command is not necessary?
I believe you should be able to use extra-libraries in the .cabal file to get
these libraries loaded.
Cheers,
Simon
Hello,
I have been doing that,
$ ghc-pkg describe vectro
...
extra-libraries: gsl cblas atlas lapack stdc++
...
I think the problem is that there is a /usr/lib/libstdc++.so.5 and a
/usr/lib/libstdc++.so.6 but no /usr/lib/libstdc++.so; when I created
the latter, linking to the libstdc++.so.6 link, I was able to use ghci
with my package. I wish I knew why /usr/lib/libstdc++.so is missing,
but it is missing on 4 out of 4 of the computers I just now checked so
I think it is normal for it to be missing, and the problem probably
lies with ghci?
(by the way, in contrast to stdc++, the links
/usr/lib/lib{gsl,cblas,atlas,lapack}.so all exist)
Thanks,
Frederik
--
http://ofb.net/~frederik/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: dynamic linking with stdc++ (was: Re: ghci dynamic linking)
On Wed, 2007-05-09 at 23:44 +0100, Frederik Eaton wrote: I think the problem is that there is a /usr/lib/libstdc++.so.5 and a /usr/lib/libstdc++.so.6 but no /usr/lib/libstdc++.so; when I created the latter, linking to the libstdc++.so.6 link, I was able to use ghci with my package. I wish I knew why /usr/lib/libstdc++.so is missing, but it is missing on 4 out of 4 of the computers I just now checked so I think it is normal for it to be missing, and the problem probably lies with ghci? Libraries are utterly incompatible: they use a different Application Binary Interface (ABI). The ABI changed around starting gcc 3.4 I think. Examining a binary on my amd64 Ubuntu/Linux box: [EMAIL PROTECTED]:/work/felix/svn/felix/felix/trunk$ ldd bin/flx_run libflx_pthread_dynamic.so = not found libflx_dynamic.so = not found libflx_gc_dynamic.so = not found libdl.so.2 = /lib/libdl.so.2 (0x2b7ba1854000) libpthread.so.0 = /lib/libpthread.so.0 (0x2b7ba1a59000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2b7ba1c74000) libm.so.6 = /lib/libm.so.6 (0x2b7ba1f78000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b7ba21fb000) libc.so.6 = /lib/libc.so.6 (0x2b7ba2409000) /lib64/ld-linux-x86-64.so.2 (0x2b7ba1637000) you can see: * my application libs are not found (LD_LIBRARY_PATH not set) * compiler libraries use *.so.integer links * core libs use *.so.integer links * the dynamic loader is hard coded [EMAIL PROTECTED]:/work/felix/svn/felix/felix/trunk$ ls /usr/lib/libstd* /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.5.0.7 /usr/lib/libstdc++.so.6.0.8 [EMAIL PROTECTED]:/work/felix/svn/felix/felix/trunk$ ls -l /usr/lib/libdl* -rw-r--r-- 1 root root 13162 2007-04-04 21:06 /usr/lib/libdl.a lrwxrwxrwx 1 root root15 2007-04-20 03:20 /usr/lib/libdl.so - /lib/libdl.so.2 Note here the '/usr/lib/libdl.so' links to '/lib/libdl.so.2': it's a core lib, not a compiler lib. Finally see: [EMAIL PROTECTED]:/work/felix/svn/felix/felix/trunk$ ls -l /usr/lib/gcc/x86_64-linux-gnu/4.1.2/libstdc++* /lib/gcc/x86_64-linux-gnu/4.1.2/libstdc++.so - ../../../libstdc++.so.6 so the link 'libstdc++.so' does exist .. but it is in a compiler specific location. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
