- ghc-devs - Haskell.org

Re: ghc-devs Digest, Vol 117, Issue 43
by Kyle Van Berendonck 23 May '13

23 May '13

Not sure if this applies here, but withSocketsDo is a huge gotcha. It doesn't affect Linux, but all networking code on BSD(?)/Windows that doesn't use it fails to boot with an unfriendly runtime error (and many people leave it out). A warning for this would be good. Regards. On Thu, May 23, 2013 at 8:00 PM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Language level heads-up warnings (David Luposchainsky) > 2. RE: Language level heads-up warnings (Simon Peyton-Jones) > 3. Re: Language level heads-up warnings (David Luposchainsky) > 4. RE: Language level heads-up warnings (Simon Peyton-Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2013 13:36:18 +0200 > From: David Luposchainsky <dluposchainsky(a)googlemail.com> > Subject: Language level heads-up warnings > To: ghc-devs(a)haskell.org > Message-ID: <519CADB2.5080904(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee > the consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious > common ground: we can already write code right now that will be > unaffected by moving Foldable/Traversable/Applicative+Monad to the > Prelude. Suppose all code is written with this in mind, the change is > trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would > you think of adding warnings about language usage? I'm sure over the > course of a couple of GHC releases, the great majority of libraries > would be modified to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind > that this is only for very few, relatively high impact changes, and can > be removed once everything is done. In my opinion, this may be a far > better transitional feature than the alternative (adding compatibility > modules, convincing thousands of developers to listen to the people in > favour of the change, ...). > > Greetings, > David > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 May 2013 13:42:10 +0000 > From: Simon Peyton-Jones <simonpj(a)microsoft.com> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <dluposchainsky(a)googlemail.com>, > "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: > < > 59543203684B2244980D7E4057D5FBC1481A7305(a)DB3EX14MBXC306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > Yes, I think that if the libraries community thought it was important, I > (or indeed someone else) could add a couple of ad-hoc warnings to GHC > without much work. But you'd all need to be clear and specific about what > warnings were wanted, and they'd need to be easy to check (ie no global > program analysis). > > Simon > > -----Original Message----- > From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs-bounces@haskell.org] > On Behalf Of David Luposchainsky > Sent: 22 May 2013 12:36 > To: ghc-devs(a)haskell.org > Subject: Language level heads-up warnings > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee the > consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious common > ground: we can already write code right now that will be unaffected by > moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all > code is written with this in mind, the change is trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would you > think of adding warnings about language usage? I'm sure over the course of > a couple of GHC releases, the great majority of libraries would be modified > to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind that > this is only for very few, relatively high impact changes, and can be > removed once everything is done. In my opinion, this may be a far better > transitional feature than the alternative (adding compatibility modules, > convincing thousands of developers to listen to the people in favour of the > change, ...). > > Greetings, > David > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 May 2013 15:54:02 +0200 > From: David Luposchainsky <dluposchainsky(a)googlemail.com> > Subject: Re: Language level heads-up warnings > To: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: <519CCDFA.40009(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2013-05-22 15:42, Simon Peyton-Jones wrote: > > Yes, I think that if the libraries community thought it was > > important, I (or indeed someone else) could add a couple of ad-hoc > > warnings to GHC without much work. But you'd all need to be clear and > > specific about what warnings were wanted, and they'd need to be easy > > to check (ie no global program analysis). > > Simon, > > good to hear that it's worth thinking about. > > I'm not sure what exactly "no global program analysis" means here. Where > would the boundaries of such warnings be? I could imagine problems if > Applicative/Monad are defined in separate packages/modules (although > that may be rare in practice). > > Greetings, > David > > > > ------------------------------ > > Message: 4 > Date: Wed, 22 May 2013 13:59:03 +0000 > From: Simon Peyton-Jones <simonpj(a)microsoft.com> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <dluposchainsky(a)googlemail.com>, > "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> > Message-ID: > < > 59543203684B2244980D7E4057D5FBC1481A745D(a)DB3EX14MBXC306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > I'm just saying that GHC has to be able to check while compiling one > module, ie as now. (It can see details of the things it imports, > obviously, since it needs to know that to compile the module) > > | -----Original Message----- > | From: David Luposchainsky [mailto:dluposchainsky@googlemail.com] > | Sent: 22 May 2013 14:54 > | To: ghc-devs(a)haskell.org > | Cc: Simon Peyton-Jones > | Subject: Re: Language level heads-up warnings > | > | On 2013-05-22 15:42, Simon Peyton-Jones wrote: > | > Yes, I think that if the libraries community thought it was > | > important, I (or indeed someone else) could add a couple of ad-hoc > | > warnings to GHC without much work. But you'd all need to be clear and > | > specific about what warnings were wanted, and they'd need to be easy > | > to check (ie no global program analysis). > | > | Simon, > | > | good to hear that it's worth thinking about. > | > | I'm not sure what exactly "no global program analysis" means here. Where > | would the boundaries of such warnings be? I could imagine problems if > | Applicative/Monad are defined in separate packages/modules (although > | that may be rare in practice). > | > | Greetings, > | David > > > > ------------------------------ > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > End of ghc-devs Digest, Vol 117, Issue 43 > ***************************************** >

1 0

Language level heads-up warnings
by David Luposchainsky 22 May '13

22 May '13

Hello GHC-Devs, The discussion on the libraries mailing list brought up the issue of breaking compatbility in favour of language evolution/sanitation again; topics mentioned specifically were Prelude's monomorphic Foldable/Traversable functions, and the Applicative/Monad issue. The main arguments of both sides are these: (+) We've been aware of certain unfortunate features of Base for a long time, and we understand very well how to fix this, and what the consequences are. (-) Changing core language features is something you can never forsee the consequences of. Breaking compatibility should be avoided at all costs. (There's also the argument about beginner friendliness, which is not backed by evidence, so I'll leave it out here.) These two seem contradictory, however they have one almost obvious common ground: we can already write code right now that will be unaffected by moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all code is written with this in mind, the change is trivial. Which brings us to the actual problem, namely that code is not written with this in mind. It is easy to forget about the issue in a practical setting, regardless of how small the required effort is. Therefore, I'd like to bring forward the idea of "language level heads-up warnings" (suggestions for better names appreciated). Right now, we can only deprecate functions. When used, GHC informs us "hey, this will work for now, but better use that in the future". However, this mechanism is too specialized to tackle the problem above: for example, there is no way to warn a user about a Monad that is not an Applicative. If the community agrees on making one of the "big" changes, what would you think of adding warnings about language usage? I'm sure over the course of a couple of GHC releases, the great majority of libraries would be modified to rectify these warnings again. If you want an example: "Warning: Monad without Applicative. This will be enforced in a future language standard." These warnings would have to be hardcoded into GHC, but keep in mind that this is only for very few, relatively high impact changes, and can be removed once everything is done. In my opinion, this may be a far better transitional feature than the alternative (adding compatibility modules, convincing thousands of developers to listen to the people in favour of the change, ...). Greetings, David

2 3

Windows validate fails
by Simon Peyton-Jones 22 May '13

22 May '13

Windows validation is failing (again). Error is below. This is a clean build. Ian? This is the same problem I had before on Linux, but this time my libraries are up to date. Did you validate on windows? Iconv may be different on windows. Urk Simon "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/IO/Encoding/Iconv.hs -o libraries/base/dist-install/build/GHC/IO/Encoding/Iconv.o Top level: Failed to load interface for `GHC.Integer.Type' There are files missing in the `integer-gmp' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/GHC/IO/Encoding/Iconv.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

2 1

dyn is not in $(GhcLibWays), but $(DYNAMIC_GHC_PROGRAMS) is YES.
by Jacques Carette 21 May '13

21 May '13

I am trying to build branch th-new, and very early on, I get the error dyn is not in $(GhcLibWays), but $(DYNAMIC_GHC_PROGRAMS) is YES. The relevant parts of my build.mk are: # Fast build with optimised libraries, no profiling (RECOMMENDED): BuildFlavour = quick GhcLibWays = v ifeq "$(BuildFlavour)" "quick" SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -fasm GhcLibHcOpts = -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif ============ I did ./sync-all pull ./sync-all get ./sync-all get th-new perl boot ./configure make and got stymied by that error. Jacques

2 2

Question about wired-in class TyCons
by Iavor Diatchki 21 May '13

21 May '13

Hello, I was trying to add a new compulsory-unfoldable primitive (i.e., one like ` unsafeCoerce` in `basicTypes/MkId.hs`), but I got stuck while trying to construct its type. The primitive needs to have this type: natSingI :: Sing a -> (SingI a => b) -> b `Sing` is a kind polymorphic data family. `SingI` is a kind polymorphic class. I am using these at kind `Nat` so, I believe, the fully-explicit type that I need to construct is actually this: natSingI :: forall (a :: Nat) (b :: *). Sing Nat a -> (SingI Nat a -> b) -> b I can almost create this type, but I got stuck on making the `SingI` type constructor. While there are many examples of making `Name`s for classes, I couldn't find one where we make a `TyCon` for a class. In particular, it looks like to make a class `TyCon`, I need to provide a `Class` value, which contains a whole lot of information that would normally be constructed by the compiler itself (class `SingI` is an ordinary class defined in source code). So I was wondering if there might be a way to obtain this information in some way or if, indeed, I need to define explicitly the entire class as a wired-in thing. Any advice would be most appreciated! -Iavor

2 1

RE: [commit: ghc] master: Allow deriving Typeable for more tycons (92191a3)
by Simon Peyton-Jones 21 May '13

21 May '13

Pedro Surely should be some user-manual change to go with this? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of José Pedro Magalhães | Sent: 07 May 2013 13:27 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Allow deriving Typeable for more tycons | (92191a3) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | https://github.com/ghc/ghc/commit/92191a39a59a036fde4de926e2e322a2c50c84 | cf | | >--------------------------------------------------------------- | | commit 92191a39a59a036fde4de926e2e322a2c50c84cf | Author: Jose Pedro Magalhaes <jpm(a)cs.ox.ac.uk> | Date: Tue May 7 09:16:29 2013 +0100 | | Allow deriving Typeable for more tycons | | >--------------------------------------------------------------- | | compiler/typecheck/TcDeriv.lhs | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/compiler/typecheck/TcDeriv.lhs | b/compiler/typecheck/TcDeriv.lhs index 7da30d19b..9b82ed6 100644 | --- a/compiler/typecheck/TcDeriv.lhs | +++ b/compiler/typecheck/TcDeriv.lhs | @@ -683,7 +683,8 @@ mkEqnHelp :: CtOrigin -> [TyVar] -> Class -> [Type] | -> Type | | mkEqnHelp orig tvs cls cls_tys tc_app mtheta | | Just (tycon, tc_args) <- tcSplitTyConApp_maybe tc_app | - , isAlgTyCon tycon -- Check for functions, primitive types etc | + , className cls == typeableClassName || isAlgTyCon tycon | + -- Avoid functions, primitive types, etc, unless it's Typeable | = mk_alg_eqn tycon tc_args | | otherwise | = failWithTc (derivingThingErr False cls cls_tys tc_app | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

STM Commentary
by Ryan Yates 20 May '13

20 May '13

Hi all, For a while now I've been working on understanding GHC's STM implementation and I finally have something to share. I've written a commentary on the implementation which can be found here: http://fryguybob.github.io/STM-Commentary/ The source is here: https://github.com/fryguybob/STM-Commentary/ It still could use a bit of polish and I would love to hear about any missing details, confusion, or misunderstandings. My goal in writing this was to fill in the gap found here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/STM. I happy to have it live where it is most appropriate. If anyone has opinions on that, let me know. Any comments are welcome, it may be easiest to just comment on the source directly on Github, but I will, of course, take feedback in any form. Thanks, Ryan Yates

7 9

adding direct *.c -> *.o/so/dylib support to ghc compilation driver
by Carter Schonwald 20 May '13

20 May '13

hey all, I think it'd be valuable to add direct C -> object file compilation support to the ghc compilation driver for a number of reasons, which i have filed / documented in a trac feature request ticket. http://hackage.haskell.org/trac/ghc/ticket/7922 based upon my still cursory understanding of the relevant bits of the GHC architecture, it seems like it'd be relatively straight forward to add such support and associated flags. any feedback/thoughts on this proposal would be appreciated. note: yes there is the work around of directly scripting the compilation for the C-> object files, but that does raise the bar on ease of use, and doesn't address some of the reasons for this ticket. i'm open to spending some time in the next month writing a patch for this if thats the best way to make it happen, though I'd probably need some guidance / help at points. But either way, this is a nice little feature that would be nice for a number of folks, not just myself thanks -Carter

1 0

Re: How to build the type-nats branch
by Iavor Diatchki 20 May '13

20 May '13

Hello, aha, I'll try to fix this some time this week, I hadn't noticed that it was broken. It is probably because the `type-nats` branch has not been merged with `master` in a while, so there are discrepancies between the versions of the compiler and the libraries. -Iavor On Sun, May 19, 2013 at 2:30 AM, Takayuki Muranushi <muranushi(a)gmail.com>wrote: > Dear ghc developers, > > I'd like to express my most greatfulness to your work. Haskell, more > specifically GHC is the tool of my living. > > Now I'm wondering how to compile the type-nats branch, as Simon PJ > sais it should. The standard routine > > [nushio@myhost ~]$ git clone http://darcs.haskell.org/ghc.git/ > Cloning into 'ghc'... > [nushio@myhost ghc]$ cd ghc/ > Branch type-nats set up to track remote branch type-nats from origin. > Switched to a new branch 'type-nats' > [nushio@myhost ghc]$ emacs mk/build.mk > [nushio@myhost ghc]$ ./sync-all --testsuite get > [nushio@myhost ghc]$ git checkout type-nats > [nushio@myhost ghc]$ git branch > master > * type-nats > [nushio@myhost ghc]$ ./configure > [nushio@myhost ghc]$ make > > aborts with the following message: > > > libraries/base/Data/Typeable/Internal.hs:295:1: > Can't make a derived instance of 'Typeable (* -> * -> *) (->)': > The last argument of the instance must be a data or newtype > application > In the stand-alone deriving instance for 'Typeable (->)' > > libraries/base/Data/Typeable/Internal.hs:363:1: > Can't make a derived instance of 'Typeable * RealWorld': > The last argument of the instance must be a data or newtype > application > In the stand-alone deriving instance for 'Typeable RealWorld' > make[1]: *** [libraries/base/dist-install/build/Data/Typeable/Internal.o] > Error 1 > make: *** [all] Error 2 > > > It seems like is related to kind-polymorphic Typeable that will > introduced in GHC>7.6.*. Using newer GHC via hsenv also doesn't > work. > > (7.7.20130409)[nushio@myhost ghc]$ ./configure > --enable-bootstrap-with-devel-snapshot > (7.7.20130409)[nushio@myhost ghc]$ ./sync-all --testsuite get > ... > fatal: reference is not a tree: 14c5a3f78c00772cf54c2fd5c920a64d53e6f594 > Unable to checkout '14c5a3f78c00772cf54c2fd5c920a64d53e6f594' in > submodule path 'libraries/Cabal' > git failed: 256 at ./sync-all line 193. > > > I'd appreciate if you teach me how to build type-nats branch of GHC. > > Best, > > Takayuki > > > > > > > > > 2013/5/18 Takayuki Muranushi <muranushi(a)gmail.com>: > > Hey thanks Simon and Levor, I've reported the problem month ago, and I > > see today the commit-id for type-nats is still not changed. So I > > thought the problem remains. Let me first try the compile process > > again tonight, and report the compile process in more detail. > > > > 2013/5/17 Simon Peyton-Jones <simonpj(a)microsoft.com>: > >> I wonder why you can't compile type-nats? It should just work. You > could email ghc-devs and Iavor (type-nats author, cc'd) explaining exactly > what goes wrong. You may need the type-nats branch of some libraries, I'm > not sure > >> > >> Simon > >> > >> Microsoft Research Limited (company number 03369488) is registered in > England and Wales > >> Registered office 21 Station Road, Cambridge, CB1 2FB > >> > >> > >> | -----Original Message----- > >> | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > >> | bounces(a)haskell.org] On Behalf Of Takayuki Muranushi > >> | Sent: 17 May 2013 07:18 > >> | To: haskell > >> | Subject: [Haskell-cafe] type-level integers for GHC > >> | > >> | What is your recommendation for type-level integers? > >> | > >> | I'd like to use it to improve the unittyped, > >> | https://bitbucket.org/xnyhps/haskell-unittyped/ the library for > physical > >> | dimension. Therefore, I need negative numbers, additions, but > >> | multiplications are not necessary. > >> | > >> | I've been looking forward for the type-nats extension of GHC, but I > >> | haven't been able to compile the type-nats branch. Just learned that > it > >> | still takes a few month to merge the branch into the main. > >> | http://hackage.haskell.org/trac/ghc/wiki/Status/May13 > >> | > >> | Thijs, the original author of unittyped, has commited a branch that > uses > >> | type-nats, but I can't try that out for the same reason. > >> | > >> | > >> | Best, > >> | -- > >> | Takayuki MURANUSHI > >> | The Hakubi Center for Advanced Research, Kyoto University > >> | http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html > >> | > >> | _______________________________________________ > >> | Haskell-Cafe mailing list > >> | Haskell-Cafe(a)haskell.org > >> | http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > -- > > Takayuki MURANUSHI > > The Hakubi Center for Advanced Research, Kyoto University > > http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html >

1 1

DSO linking bug (unix package / pthread)
by Simon Hengel 20 May '13

20 May '13

Hi, when I try to use System.Posix.Semaphore.semUnlink on Ubuntu 13.04 I get the following liker error: /usr/bin/ld: /home/sol/.install/haskell/ghc-7.0.4/lib/ghc-7.0.4/unix-2.4.2.0/libHSunix-2.4.2.0.a(Semaphore__3.o): undefined reference to symbol 'sem_unlink@@GLIBC_2.2.5' /usr/bin/ld: note: 'sem_unlink@@GLIBC_2.2.5' is defined in DSO /lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the linker command line /lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status The issue can be reproduced by compiling -- Main.hs import System.Posix.Semaphore main :: IO () main = do semUnlink "pwsafe" with `ghc --make Main.hs`. Probably related to those changes to DSO liking: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange Any chances that we fix this for previous releases, too (I'm interested in ghc-6.12.1 to ghc-7.6.3)? Cheers, Simon

1 0