RE: ghc-pkg -g fails on Solaris
On 18 January 2005 15:13, Duncan Coutts wrote: On all Unix platforms except Darwin, ghc-pkg calls: ld -r -x -o HSfoo.o --whole-archive libHSfoo.a See: ghc/utils/ghc-pkg/Main.hs, function autoBuildGHCiLib This works for the GNU linker. For the Solaris linker (which takes the name ld, GNU ld gets gld if it's installed) this does not work. The Solaris linker does not understand the -x or --whole-archive flags. Actually I don't understand how GHC manages to install it's own libraries with GHCi support on Solaris if this doesn't work. Presumably the GHC build system builds the HSfoo.o files itself. Does anyone know how it is done? This was always a hack. I guess we should make it a bit more portable. Yes, the GHC build system builds the GHCi libs itself. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1105067 ] -ffi poorly documented
Bugs item #1105067, was opened at 2005-01-19 07:25 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1105067group_id=8032 Category: Documentation Group: 6.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Aaron Denney (wightnoise) Assigned to: Nobody/Anonymous (nobody) Summary: -ffi poorly documented Initial Comment: The flag is not mentioned in the using FFI in GHC section, and only once elsewhere, in the overall flags section. It was rather confusing as to why ghc was choking on the import bit of foreign import Yes, it's only a one-time road-block for new users of FFI, but it's a bit annoying that it wasn't obvious that FFI features were only enabled when the -ffi flag is passed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1105067group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Again: Runtime system doesn't notice changed file descriptor status
Hi Volker, On 02 January 2005 16:35, Volker Wysk wrote: I made an error when simplifying the program for the bug report. Here's the message again. I'm building a program which converts file names from ISO8859-1 to UTF-8. It calls the recode program to do the actual conversion. This part does the work: pfade - fmap lines (contents -) pipe_to (unlines pfade) (execp recode [-f, latin1..utf8] -|= (do pfade_utf8 - fmap lines (contents -) --XX error here mapM_ (\(pfad, pfad_utf8) - do ... ) (zip pfade pfade_utf8) ) ) ... lazy_contents :: String - IO (String, Handle) lazy_contents pfad = do h - if pfad == - then return stdin else openFile pfad ReadMode txt - hGetContents h return (txt, h) contents :: String - IO String contents pfad = do (txt, h) - lazy_contents pfad seq (length txt) (return ()) hClose h return txt pipe_to and (-|=) fork two processes, connected through a pipe. I get this error at the marked point: In child process, part of a pipe: IO-Error Error type: illegal operation Location: hGetContents Description: handle is closed File name:stdin The problem is, the call of contents - at the beginning closes the main process' standard input (mere getContents would semi-close it, same problem). It is replaced in the child with the pipe from recode, but the runtime system doesn't notice that stdin is open again. The openness state seems to be duplicated in the file handle. So, in the child process you actually want to reset the stdin Handle, right? There is hDuplicateTo, which might be enough for your needs. Use it like this: h - fdToHandle pipe_read_fd hDuplicateTo h stdin hDuplicateTo is only available from GHC.Handle at the moment. It works when replacing the marked line with the following. h - fdToHandle 0 pfade_utf8 - fmap lines (hGetContents h) I'm using only functions from the System.Posix library (e.g. dupTo), so I think the runtime system should notice. I'm not sure if what you're asking could/should be done automatically by the RTS. If I understand correctly, you'd like System.Posix.dupTo to automatically update Handles that refer to the destination file descriptor, right? We don't keep around a table mapping file descriptors to Handles, so that would be quite hard. Apart from that, is there any way to notify the runtime system that the file descriptor 0 has changed? But in the first place, it should be avoided to duplicate the file descriptor's state in the handle, if possible. Which state are you referring to here? The closed state? If so, that's only Haskell-side state, we don't actually close the real file descriptor. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-pkg -g fails on Solaris
On 18 Jan 2005, at 15:12, Duncan Coutts wrote: Hi, On all Unix platforms except Darwin, ghc-pkg calls: ld -r -x -o HSfoo.o --whole-archive libHSfoo.a See: ghc/utils/ghc-pkg/Main.hs, function autoBuildGHCiLib This works for the GNU linker. For the Solaris linker (which takes the name ld, GNU ld gets gld if it's installed) this does not work. The Solaris linker does not understand the -x or --whole-archive flags. I built GHC by setting some funny autoconf variables to the GNU versions of the linker and the archiver. However, the real bug, IMHO, is that ghc-pkg uses ld in the current search path instead of the one ghc was configured with. GNU ld has the nice side effect that it is much faster than Sun's ld. The only way seems to build the ghci library by hand. Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Again: Runtime system doesn't notice changed file descriptor status
Hello. I've had the misconception that a file descriptor can be in a closed state. So the bug report was rather misguided - sorry for that. Yes, what I actually want is to reset the stdin handle. Thanks for the hint to hDuplicateTo. This should be exactly what I need. I see that the thing which the file descriptor is connected to can be in an EOF state (end of file, other side of pipe closed...), whereas the file descriptor is still valid. This means that the Haskell Library Report actually demands for a closedness state to be maintained in the file handle, since EOF and closed handle are two different things (result in different exceptions etc). However, I'd still expect hClose stdin to actually close the file descriptor. I've taken a look at the hClose implementation. It's problematic not to actually close any standard file descriptors. For instance, some process might be reading the standard output of a Haskell program. When that program calls hClose stdout, the process' read will block, rather than succeed with zero bytes read (EOF). The process won't notice that the program has finished outputting, until the program terminates. Imagine a case where a program outputs some status messages and then forks into demon mode, closing its standard file descriptors in order to detach itself from the terminal. I'm wondering if there's any particular reason for not actually closing the standard file descriptors. Greetings, Volker -- http://www.volker-wysk.de ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
