From harendra.kumar at gmail.com Mon Oct 7 02:55:21 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 7 Oct 2024 08:25:21 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file Message-ID: Hi everyone, We have a long standing, elusive and intermittent test failure in streamly's file system event test suite. The code where the error emanates from looks like this: createFileWithParent :: FilePath -> FilePath -> IO () createFileWithParent file parent = do let filepath = parent file let dir = takeDirectory filepath putStrLn $ "createFileWithParent: file [" ++ file ++ "] dir [" ++ dir ++ "]" putStrLn $ "Ensuring dir: " ++ dir createDirectoryIfMissing True dir r <- doesDirectoryExist dir if r then do putStrLn $ "Ensured dir: " ++ dir when (not (null file)) $ do exists <- doesFileExist filepath if not exists then do putStrLn $ "Creating file: " ++ (parent file) openFile (parent file) WriteMode >>= hClose putStrLn $ "Created file: " ++ (parent file) else error $ "File exists: " ++ filepath else error $ "Could not create dir: " ++ dir The important thing in the code above is that we check that the file does not exist already, and we are creating it. Creating this new file intermittently fails with the following error messages, all of these are coming from prints in the above: createFileWithParent: file [file1] dir [/tmp/fsevent_dir-e1098325dc2b0880/watch-root] Ensuring dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Ensured dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Creating file: /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1 uncaught exception: IOException of type ResourceBusy /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1: openFile: resource busy (file is locked) How can a file that does not exist and being created be locked during creation? We see this only on Linux, the same tests always succeed on Windows and macOS. We are facing this in GHC 9.2.8, I am not sure if it is version specific because in the past I selectively disabled the tests for specific GHC versions and the error still surfaced in other GHC versions. Anything obvious that we may be missing here? Any pointers or more debug info to generate to debug this? I have not started looking into the openFile code yet, hoping someone else knowing it well might help here. Is this some other "resource busy" error which is being wrongly bucketed into "file is locked" error? Thanks, Harendra From ky3 at atamo.com Mon Oct 7 03:11:33 2024 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 7 Oct 2024 11:11:33 +0800 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: What do you see when you run an strace? On Mon, Oct 7, 2024 at 10:55 AM Harendra Kumar wrote: > Hi everyone, > > We have a long standing, elusive and intermittent test failure in > streamly's file system event test suite. The code where the error > emanates from looks like this: > > createFileWithParent :: FilePath -> FilePath -> IO () > createFileWithParent file parent = do > let filepath = parent file > let dir = takeDirectory filepath > putStrLn $ "createFileWithParent: file [" > ++ file ++ "] dir [" ++ dir ++ "]" > putStrLn $ "Ensuring dir: " ++ dir > createDirectoryIfMissing True dir > r <- doesDirectoryExist dir > if r > then do > putStrLn $ "Ensured dir: " ++ dir > when (not (null file)) $ do > exists <- doesFileExist filepath > if not exists > then do > putStrLn $ "Creating file: " ++ (parent file) > openFile (parent file) WriteMode >>= hClose > putStrLn $ "Created file: " ++ (parent file) > else error $ "File exists: " ++ filepath > else error $ "Could not create dir: " ++ dir > > > The important thing in the code above is that we check that the file > does not exist already, and we are creating it. Creating this new file > intermittently fails with the following error messages, all of these > are coming from prints in the above: > > createFileWithParent: file [file1] dir > [/tmp/fsevent_dir-e1098325dc2b0880/watch-root] > Ensuring dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root > Ensured dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root > Creating file: /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1 > > uncaught exception: IOException of type ResourceBusy > /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1: openFile: resource > busy (file is locked) > > How can a file that does not exist and being created be locked during > creation? We see this only on Linux, the same tests always succeed on > Windows and macOS. We are facing this in GHC 9.2.8, I am not sure if > it is version specific because in the past I selectively disabled the > tests for specific GHC versions and the error still surfaced in other > GHC versions. > > Anything obvious that we may be missing here? Any pointers or more > debug info to generate to debug this? I have not started looking into > the openFile code yet, hoping someone else knowing it well might help > here. > > Is this some other "resource busy" error which is being wrongly > bucketed into "file is locked" error? > > Thanks, > Harendra > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Oct 7 10:52:06 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 7 Oct 2024 21:52:06 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Mon, Oct 07, 2024 at 08:25:21AM +0530, Harendra Kumar wrote: > exists <- doesFileExist filepath > if not exists > then do > putStrLn $ "Creating file: " ++ (parent file) > openFile (parent file) WriteMode >>= hClose > putStrLn $ "Created file: " ++ (parent file) > else error $ "File exists: " ++ filepath This is a classic TOCTOU bug. The file can come into existence between the "doesFileExist" test and the attempt to create it. To create a file only if it does not exist, you need to use an "open" variant that creates the file if necessary, and leaves it unmodified if it already exists. "AppendMode" works for this, because you're closing the file immediately, so the fact that any writes would "append" is not material. So replace the above with: openFile filepath AppendMode >>= hClose If you need to know whether the file got created by this call, or was found to exist already, you need a lower-level API, such as (Unix C): /* In some cases 0600 is more appropriate */ int fd = open(path, O_WRONLY|O_CREAT|O_EXCL, 0666); if (fd >= 0) { /* Just created */ (void) close(fd); ... } else if (errno == EEXIST) { /* Already present */ ... } else { /* Permission or other problem */ ... } -- Viktor. From ietf-dane at dukhovni.org Mon Oct 7 11:04:45 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 7 Oct 2024 22:04:45 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Mon, Oct 07, 2024 at 09:52:06PM +1100, Viktor Dukhovni wrote: > If you need to know whether the file got created by this call, or was > found to exist already, you need a lower-level API, such as (Unix C): > > /* In some cases 0600 is more appropriate */ > int fd = open(path, O_WRONLY|O_CREAT|O_EXCL, 0666); > > if (fd >= 0) { > /* Just created */ > (void) close(fd); > ... > } else if (errno == EEXIST) { > /* Already present */ > ... > } else { > /* Permission or other problem */ > ... > } I should mention that The above assumes a "local" filesystem, with NFS a race may still be possible, and the open(2) manpage may describe work-arounds, e.g. Linux: On NFS, O_EXCL is supported only when using NFSv3 or later on kernel 2.6 or later. In NFS environments where O_EXCL support is not provided, programs that rely on it for performing locking tasks will contain a race condition. Portable programs that want to perform atomic file locking using a lockfile, and need to avoid reliance on NFS support for O_EXCL, can create a unique file on the same filesystem (e.g., incorporating hostname and PID), and use link(2) to make a link to the lockfile. If link(2) returns 0, the lock is successful. Otherwise, use stat(2) on the unique file to check if its link count has increased to 2, in which case the lock is also successful. -- Viktor. From harendra.kumar at gmail.com Tue Oct 8 05:53:14 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 8 Oct 2024 11:23:14 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: Hi Viktor, Thanks for looking into this. This cannot be a TOCTOU bug as the code to check the existence of the file is only introduced for debugging this issue, to report in case the file exists for some reason. Our understanding is that this file cannot exist in the first place. We have never seen the "File exists" message being printed, I will make that an error to make sure. The tests create a temporary file using a random directory name in the system temp directory, the directory is destroyed at the end of the test. Also, tests do not run in parallel, we are using hspec to run tests and it does not run tests in parallel unless we explicitly say so, so there is no possibility that two tests could be trying to use the same file. We will double check that. Also, this happens only on Linux. We will also try the append mode as you suggested. -harendra On Mon, 7 Oct 2024 at 16:22, Viktor Dukhovni wrote: > > On Mon, Oct 07, 2024 at 08:25:21AM +0530, Harendra Kumar wrote: > > > exists <- doesFileExist filepath > > if not exists > > then do > > putStrLn $ "Creating file: " ++ (parent file) > > openFile (parent file) WriteMode >>= hClose > > putStrLn $ "Created file: " ++ (parent file) > > else error $ "File exists: " ++ filepath > > This is a classic TOCTOU bug. The file can come into existence between > the "doesFileExist" test and the attempt to create it. To create a file > only if it does not exist, you need to use an "open" variant that > creates the file if necessary, and leaves it unmodified if it already > exists. "AppendMode" works for this, because you're closing the file > immediately, so the fact that any writes would "append" is not material. > > So replace the above with: > > openFile filepath AppendMode >>= hClose > > If you need to know whether the file got created by this call, or was > found to exist already, you need a lower-level API, such as (Unix C): > > /* In some cases 0600 is more appropriate */ > int fd = open(path, O_WRONLY|O_CREAT|O_EXCL, 0666); > > if (fd >= 0) { > /* Just created */ > (void) close(fd); > ... > } else if (errno == EEXIST) { > /* Already present */ > ... > } else { > /* Permission or other problem */ > ... > } > > -- > Viktor. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gergo at erdi.hu Tue Oct 8 06:17:24 2024 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Tue, 8 Oct 2024 14:17:24 +0800 (+08) Subject: Tunnelling information between plugin hooks Message-ID: Hi, Is there a way to compute some value inside a plugin hook, and then make that available to a later hook (other than horrible hacks like writing it to a global `IORef` / `MVar`)? For example, suppose my `parsedResultAction` looks at the parsed AST and computes a `MySourceStats` from it. How can I then access that `MySourceStats` value from my `typeCheckResultAction`? Thanks, Gergo From ietf-dane at dukhovni.org Tue Oct 8 06:20:04 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Oct 2024 17:20:04 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Tue, Oct 08, 2024 at 11:23:14AM +0530, Harendra Kumar wrote: > This cannot be a TOCTOU bug as the code to check the existence of the > file is only introduced for debugging this issue, to report in case > the file exists for some reason. Our understanding is that this file > cannot exist in the first place. We have never seen the "File exists" > message being printed, I will make that an error to make sure. The > tests create a temporary file using a random directory name in the > system temp directory, the directory is destroyed at the end of the > test. Also, tests do not run in parallel, we are using hspec to run > tests and it does not run tests in parallel unless we explicitly say > so, so there is no possibility that two tests could be trying to use > the same file. We will double check that. Also, this happens only on > Linux. We will also try the append mode as you suggested. What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in? Creating and closing a file in write mode from GHC: import System.IO main :: IO () main = do putStrLn "Show time" >> hFlush stdout openFile "/tmp/foo.out" WriteMode >>= hClose translates on Linux to (strace): write(1, "Show time\n", 10) = 10 openat(AT_FDCWD, "/tmp/foo.out", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 6 newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0 ftruncate(6, 0) = 0 ioctl(6, TCGETS, 0x7ffd358412a0) = -1 ENOTTY (Inappropriate ioctl for device) close(6) = 0 Nothing at all unusual happening here, so if the OS returns EBUSY, perhaps there's something interesting you can report about the state of that directory before file creation? Perhaps there's some filesystem or other kernel resource you're maxing out during the tests? -- Viktor. From x at tomsmeding.com Tue Oct 8 07:06:48 2024 From: x at tomsmeding.com (Tom Smeding) Date: Tue, 8 Oct 2024 09:06:48 +0200 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: <29c2c2d0-21f7-4616-b5f9-1616b2eab848@tomsmeding.com> Inspired by Viktor's latest email in the thread: > Any pointers or more debug info to generate to debug this? Given that this happens on Linux, it would be nice to have `strace` output on the program. If you know precisely which executable does this, `strace -o log.txt ` suffices; additionally passing `-f` to strace instructs it to also trace child processes, at the cost of (usually) significantly blowing up the size of the trace. Then we can see exactly which system call fails, and what happened right before. - Tom On 07/10/2024 04:55, Harendra Kumar wrote: > Hi everyone, > > We have a long standing, elusive and intermittent test failure in > streamly's file system event test suite. The code where the error > emanates from looks like this: > > createFileWithParent :: FilePath -> FilePath -> IO () > createFileWithParent file parent = do > let filepath = parent file > let dir = takeDirectory filepath > putStrLn $ "createFileWithParent: file [" > ++ file ++ "] dir [" ++ dir ++ "]" > putStrLn $ "Ensuring dir: " ++ dir > createDirectoryIfMissing True dir > r <- doesDirectoryExist dir > if r > then do > putStrLn $ "Ensured dir: " ++ dir > when (not (null file)) $ do > exists <- doesFileExist filepath > if not exists > then do > putStrLn $ "Creating file: " ++ (parent file) > openFile (parent file) WriteMode >>= hClose > putStrLn $ "Created file: " ++ (parent file) > else error $ "File exists: " ++ filepath > else error $ "Could not create dir: " ++ dir > > > The important thing in the code above is that we check that the file > does not exist already, and we are creating it. Creating this new file > intermittently fails with the following error messages, all of these > are coming from prints in the above: > > createFileWithParent: file [file1] dir > [/tmp/fsevent_dir-e1098325dc2b0880/watch-root] > Ensuring dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root > Ensured dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root > Creating file: /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1 > > uncaught exception: IOException of type ResourceBusy > /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1: openFile: resource > busy (file is locked) > > How can a file that does not exist and being created be locked during > creation? We see this only on Linux, the same tests always succeed on > Windows and macOS. We are facing this in GHC 9.2.8, I am not sure if > it is version specific because in the past I selectively disabled the > tests for specific GHC versions and the error still surfaced in other > GHC versions. > > Anything obvious that we may be missing here? Any pointers or more > debug info to generate to debug this? I have not started looking into > the openFile code yet, hoping someone else knowing it well might help > here. > > Is this some other "resource busy" error which is being wrongly > bucketed into "file is locked" error? > > Thanks, > Harendra > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From harendra.kumar at gmail.com Tue Oct 8 07:45:40 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 8 Oct 2024 13:15:40 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Tue, 8 Oct 2024 at 11:50, Viktor Dukhovni wrote: > What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in? This happens on github Linux CI. Not sure which filesystem they are using. Earlier I was wondering if something funny is happening in case they are using NFS. But NFS usually causes issues due to caching of directory entries if we are doing cross-node operations, here we are on a single node and operations are not running in parallel (or that's what I believe). I will remove the hspec layer from the tests to make sure that the code is simpler and our understanding is correct. I will also run the tests on circle-ci to check if the problem occurs there. I have never seen this problem in testing this on a Linux machine on AWS even if I ran the tests for days in a loop. > Creating and closing a file in write mode from GHC: > > import System.IO > > main :: IO () > main = do > putStrLn "Show time" >> hFlush stdout > openFile "/tmp/foo.out" WriteMode >>= hClose > > translates on Linux to (strace): > > write(1, "Show time\n", 10) = 10 > openat(AT_FDCWD, "/tmp/foo.out", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 6 > newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0 > ftruncate(6, 0) = 0 > ioctl(6, TCGETS, 0x7ffd358412a0) = -1 ENOTTY (Inappropriate ioctl for device) > close(6) = 0 > > Nothing at all unusual happening here, so if the OS returns EBUSY, > perhaps there's something interesting you can report about the state of > that directory before file creation? Perhaps there's some filesystem or > other kernel resource you're maxing out during the tests? Is EBUSY errno getting translated to "file is locked" error here? In that case there can be other possibilities, depending on the machine or the file system. The error message should perhaps indicate other possibilities here, something like "file may be locked, or the file system is temporarily busy/unavailable". Let me check the openFile code, how it is translating system errors to user errors. -harendra From ietf-dane at dukhovni.org Tue Oct 8 10:27:04 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Oct 2024 21:27:04 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Tue, Oct 08, 2024 at 01:15:40PM +0530, Harendra Kumar wrote: > On Tue, 8 Oct 2024 at 11:50, Viktor Dukhovni wrote: > > > What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in? > > This happens on github Linux CI. Not sure which filesystem they are > using. Earlier I was wondering if something funny is happening in case > they are using NFS. But NFS usually causes issues due to caching of > directory entries if we are doing cross-node operations, here we are > on a single node and operations are not running in parallel (or that's > what I believe). I will remove the hspec layer from the tests to make > sure that the code is simpler and our understanding is correct. > > I will also run the tests on circle-ci to check if the problem occurs > there. I have never seen this problem in testing this on a Linux > machine on AWS even if I ran the tests for days in a loop. Looking more closely at the GHC code, we see that there's an internal (RTS not OS level) exclusive lock on the (device, inode) pair as part of opening a Unix file for writes, or shared lock for reads. rts/FileLock.c: int lockFile(StgWord64 id, StgWord64 dev, StgWord64 ino, int for_writing) { Lock key, *lock; ACQUIRE_LOCK(&file_lock_mutex); key.device = dev; key.inode = ino; lock = lookupHashTable_(obj_hash, (StgWord)&key, hashLock, cmpLocks); if (lock == NULL) { lock = stgMallocBytes(sizeof(Lock), "lockFile"); lock->device = dev; lock->inode = ino; lock->readers = for_writing ? -1 : 1; insertHashTable_(obj_hash, (StgWord)lock, (void *)lock, hashLock); insertHashTable(key_hash, id, lock); RELEASE_LOCK(&file_lock_mutex); return 0; } else { // single-writer/multi-reader locking: if (for_writing || lock->readers < 0) { RELEASE_LOCK(&file_lock_mutex); return -1; } insertHashTable(key_hash, id, lock); lock->readers++; RELEASE_LOCK(&file_lock_mutex); return 0; } } This is obtained in "libraries/base/GHC/IO/FD.hs", via: mkFD fd iomode mb_stat is_socket is_nonblock = do ... case fd_type of Directory -> ioException (IOError Nothing InappropriateType "openFile" "is a directory" Nothing Nothing) -- regular files need to be locked RegularFile -> do -- On Windows we need an additional call to get a unique device id -- and inode, since fstat just returns 0 for both. -- See also Note [RTS File locking] (unique_dev, unique_ino) <- getUniqueFileInfo fd dev ino r <- lockFile (fromIntegral fd) unique_dev unique_ino (fromBool write) when (r == -1) $ ioException (IOError Nothing ResourceBusy "openFile" "file is locked" Nothing Nothing) ... This suggests that when the file in question is opened there's already a read lock in for the same dev/ino. Perhaps the Github filesystem fails to ensure uniqueness of dev+ino of open files (perhaps when open files are already unlinked)? -- Viktor. From harendra.kumar at gmail.com Tue Oct 8 12:38:52 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 8 Oct 2024 18:08:52 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: What if we closed a file and created another one and the inode of the previous file got reused for the new one? Is it possible that there is a small window after the deletion of the old one in which GHC keeps the lock in its hash table? If that happens then the newly created file will see that there is already a lock on the file. Could it be that the lock gets released when the handle is cleaned by GC or something like that? I can try adding a delay and/or performMajorGC before creating the new file. -harendra On Tue, 8 Oct 2024 at 15:57, Viktor Dukhovni wrote: > > On Tue, Oct 08, 2024 at 01:15:40PM +0530, Harendra Kumar wrote: > > On Tue, 8 Oct 2024 at 11:50, Viktor Dukhovni wrote: > > > > > What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in? > > > > This happens on github Linux CI. Not sure which filesystem they are > > using. Earlier I was wondering if something funny is happening in case > > they are using NFS. But NFS usually causes issues due to caching of > > directory entries if we are doing cross-node operations, here we are > > on a single node and operations are not running in parallel (or that's > > what I believe). I will remove the hspec layer from the tests to make > > sure that the code is simpler and our understanding is correct. > > > > I will also run the tests on circle-ci to check if the problem occurs > > there. I have never seen this problem in testing this on a Linux > > machine on AWS even if I ran the tests for days in a loop. > > Looking more closely at the GHC code, we see that there's an internal > (RTS not OS level) exclusive lock on the (device, inode) pair as part of > opening a Unix file for writes, or shared lock for reads. > > rts/FileLock.c: > int > lockFile(StgWord64 id, StgWord64 dev, StgWord64 ino, int for_writing) > { > Lock key, *lock; > > ACQUIRE_LOCK(&file_lock_mutex); > > key.device = dev; > key.inode = ino; > > lock = lookupHashTable_(obj_hash, (StgWord)&key, hashLock, cmpLocks); > > if (lock == NULL) > { > lock = stgMallocBytes(sizeof(Lock), "lockFile"); > lock->device = dev; > lock->inode = ino; > lock->readers = for_writing ? -1 : 1; > insertHashTable_(obj_hash, (StgWord)lock, (void *)lock, hashLock); > insertHashTable(key_hash, id, lock); > RELEASE_LOCK(&file_lock_mutex); > return 0; > } > else > { > // single-writer/multi-reader locking: > if (for_writing || lock->readers < 0) { > RELEASE_LOCK(&file_lock_mutex); > return -1; > } > insertHashTable(key_hash, id, lock); > lock->readers++; > RELEASE_LOCK(&file_lock_mutex); > return 0; > } > } > > This is obtained in "libraries/base/GHC/IO/FD.hs", via: > > mkFD fd iomode mb_stat is_socket is_nonblock = do > ... > case fd_type of > Directory -> > ioException (IOError Nothing InappropriateType "openFile" > "is a directory" Nothing Nothing) > > -- regular files need to be locked > RegularFile -> do > -- On Windows we need an additional call to get a unique device id > -- and inode, since fstat just returns 0 for both. > -- See also Note [RTS File locking] > (unique_dev, unique_ino) <- getUniqueFileInfo fd dev ino > r <- lockFile (fromIntegral fd) unique_dev unique_ino > (fromBool write) > when (r == -1) $ > ioException (IOError Nothing ResourceBusy "openFile" > "file is locked" Nothing Nothing) > ... > > This suggests that when the file in question is opened there's already a > read lock in for the same dev/ino. Perhaps the Github filesystem fails > to ensure uniqueness of dev+ino of open files (perhaps when open files > are already unlinked)? > > -- > Viktor. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From harendra.kumar at gmail.com Tue Oct 8 13:17:57 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 8 Oct 2024 18:47:57 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: Some more information: The root file system which contains the /tmp directory, where the file is being created, is of type ext4: df -T output: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/root ext4 76026616 53915404 22094828 71% / cat /proc/mounts output: /dev/root / ext4 rw,relatime,discard,errors=remount-ro 0 0 Also, I added the directory and file existence checks before the creation of the file at all places, and now the problem stopped happening. Maybe it became less likely and might surface some time later. -harendra On Tue, 8 Oct 2024 at 18:08, Harendra Kumar wrote: > > What if we closed a file and created another one and the inode of the > previous file got reused for the new one? Is it possible that there is > a small window after the deletion of the old one in which GHC keeps > the lock in its hash table? If that happens then the newly created > file will see that there is already a lock on the file. Could it be > that the lock gets released when the handle is cleaned by GC or > something like that? > > I can try adding a delay and/or performMajorGC before creating the new file. > > -harendra > > On Tue, 8 Oct 2024 at 15:57, Viktor Dukhovni wrote: > > > > On Tue, Oct 08, 2024 at 01:15:40PM +0530, Harendra Kumar wrote: > > > On Tue, 8 Oct 2024 at 11:50, Viktor Dukhovni wrote: > > > > > > > What sort of filesystem is "/tmp/fsevent_dir-.../watch-root" located in? > > > > > > This happens on github Linux CI. Not sure which filesystem they are > > > using. Earlier I was wondering if something funny is happening in case > > > they are using NFS. But NFS usually causes issues due to caching of > > > directory entries if we are doing cross-node operations, here we are > > > on a single node and operations are not running in parallel (or that's > > > what I believe). I will remove the hspec layer from the tests to make > > > sure that the code is simpler and our understanding is correct. > > > > > > I will also run the tests on circle-ci to check if the problem occurs > > > there. I have never seen this problem in testing this on a Linux > > > machine on AWS even if I ran the tests for days in a loop. > > > > Looking more closely at the GHC code, we see that there's an internal > > (RTS not OS level) exclusive lock on the (device, inode) pair as part of > > opening a Unix file for writes, or shared lock for reads. > > > > rts/FileLock.c: > > int > > lockFile(StgWord64 id, StgWord64 dev, StgWord64 ino, int for_writing) > > { > > Lock key, *lock; > > > > ACQUIRE_LOCK(&file_lock_mutex); > > > > key.device = dev; > > key.inode = ino; > > > > lock = lookupHashTable_(obj_hash, (StgWord)&key, hashLock, cmpLocks); > > > > if (lock == NULL) > > { > > lock = stgMallocBytes(sizeof(Lock), "lockFile"); > > lock->device = dev; > > lock->inode = ino; > > lock->readers = for_writing ? -1 : 1; > > insertHashTable_(obj_hash, (StgWord)lock, (void *)lock, hashLock); > > insertHashTable(key_hash, id, lock); > > RELEASE_LOCK(&file_lock_mutex); > > return 0; > > } > > else > > { > > // single-writer/multi-reader locking: > > if (for_writing || lock->readers < 0) { > > RELEASE_LOCK(&file_lock_mutex); > > return -1; > > } > > insertHashTable(key_hash, id, lock); > > lock->readers++; > > RELEASE_LOCK(&file_lock_mutex); > > return 0; > > } > > } > > > > This is obtained in "libraries/base/GHC/IO/FD.hs", via: > > > > mkFD fd iomode mb_stat is_socket is_nonblock = do > > ... > > case fd_type of > > Directory -> > > ioException (IOError Nothing InappropriateType "openFile" > > "is a directory" Nothing Nothing) > > > > -- regular files need to be locked > > RegularFile -> do > > -- On Windows we need an additional call to get a unique device id > > -- and inode, since fstat just returns 0 for both. > > -- See also Note [RTS File locking] > > (unique_dev, unique_ino) <- getUniqueFileInfo fd dev ino > > r <- lockFile (fromIntegral fd) unique_dev unique_ino > > (fromBool write) > > when (r == -1) $ > > ioException (IOError Nothing ResourceBusy "openFile" > > "file is locked" Nothing Nothing) > > ... > > > > This suggests that when the file in question is opened there's already a > > read lock in for the same dev/ino. Perhaps the Github filesystem fails > > to ensure uniqueness of dev+ino of open files (perhaps when open files > > are already unlinked)? > > > > -- > > Viktor. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ietf-dane at dukhovni.org Wed Oct 9 03:04:07 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Oct 2024 14:04:07 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Tue, Oct 08, 2024 at 06:08:52PM +0530, Harendra Kumar wrote: > What if we closed a file and created another one and the inode of the > previous file got reused for the new one? Is it possible that there is > a small window after the deletion of the old one in which GHC keeps > the lock in its hash table? That SHOULD NOT happen, GHC releases the (internal hash table entry) lock before closing the file descriptor: close :: FD -> IO () close fd = do let closer realFd = throwErrnoIfMinus1Retry_ "GHC.IO.FD.close" $ #if defined(mingw32_HOST_OS) if fdIsSocket fd then c_closesocket (fromIntegral realFd) else #endif c_close (fromIntegral realFd) -- release the lock *first*, because otherwise if we're preempted -- after closing but before releasing, the FD may have been reused. -- (#7646) release fd closeFdWith closer (fromIntegral (fdFD fd)) release :: FD -> IO () release fd = do _ <- unlockFile (fromIntegral $ fdFD fd) return () Solved in GHC 7.8 11 years ago: https://gitlab.haskell.org/ghc/ghc/-/issues/7646#note_68902 This assumes that the application is not closing the file descriptor "behind GHC's back". That is, you're not using the POSIX package to directly close file descriptors underlying Haskell file Handles (which would then orphan the associated "lock"). -- Viktor. From harendra.kumar at gmail.com Wed Oct 9 04:54:30 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 9 Oct 2024 10:24:30 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: I just noticed that cabal seems to be running test suites in parallel. We have two test suites. Even though each test suite generates the temp names randomly, they use the same prefix, if the generated names have a possibility of conflict due to PRNG it may cause a problem. That is perhaps the more likely cause rather than hunting this in GHC. cabal running tests in parallel without explicitly saying so came as a surprise to me. In fact I found an issue in cabal repo asking for a "feature" to run them sequentially, the issue is still open - https://github.com/haskell/cabal/issues/6751 . Hopefully this is it. -harendra On Wed, 9 Oct 2024 at 08:34, Viktor Dukhovni wrote: > > On Tue, Oct 08, 2024 at 06:08:52PM +0530, Harendra Kumar wrote: > > > What if we closed a file and created another one and the inode of the > > previous file got reused for the new one? Is it possible that there is > > a small window after the deletion of the old one in which GHC keeps > > the lock in its hash table? > > That SHOULD NOT happen, GHC releases the (internal hash table entry) > lock before closing the file descriptor: > > close :: FD -> IO () > close fd = > do let closer realFd = > throwErrnoIfMinus1Retry_ "GHC.IO.FD.close" $ > #if defined(mingw32_HOST_OS) > if fdIsSocket fd then > c_closesocket (fromIntegral realFd) > else > #endif > c_close (fromIntegral realFd) > > -- release the lock *first*, because otherwise if we're preempted > -- after closing but before releasing, the FD may have been reused. > -- (#7646) > release fd > > closeFdWith closer (fromIntegral (fdFD fd)) > > release :: FD -> IO () > release fd = do _ <- unlockFile (fromIntegral $ fdFD fd) > return () > > Solved in GHC 7.8 11 years ago: > > https://gitlab.haskell.org/ghc/ghc/-/issues/7646#note_68902 > > This assumes that the application is not closing the file descriptor > "behind GHC's back". That is, you're not using the POSIX package to > directly close file descriptors underlying Haskell file Handles > (which would then orphan the associated "lock"). > > -- > Viktor. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ietf-dane at dukhovni.org Wed Oct 9 05:01:47 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Oct 2024 16:01:47 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Wed, Oct 09, 2024 at 10:24:30AM +0530, Harendra Kumar wrote: > I just noticed that cabal seems to be running test suites in parallel. > We have two test suites. Even though each test suite generates the > temp names randomly, they use the same prefix, if the generated names > have a possibility of conflict due to PRNG it may cause a problem. > That is perhaps the more likely cause rather than hunting this in GHC. > cabal running tests in parallel without explicitly saying so came as a > surprise to me. In fact I found an issue in cabal repo asking for a > "feature" to run them sequentially, the issue is still open - > https://github.com/haskell/cabal/issues/6751 . Hopefully this is it. Just parallel execution is not sufficient to explain the observed problem, you still need to have the same inode/dev already open in the same process, or bookkeeping of which dev/ino pairs are in use to be incorrect. So either the Github filesystem is reusing inodes of already deleted, but still open files (a deviation from expected Unix behaviour), or somehow GHC fails to correctly track the dev/ino pairs of open handles. My best guess is that something is manipulating file descriptors directly, bypassing the Handle layer, and *then* parallel execution could exacerbate the resulting inconsistent state. -- Viktor. From harendra.kumar at gmail.com Wed Oct 9 05:58:51 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 9 Oct 2024 11:28:51 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: You are right I guess. I changed the temp prefix for both the test suites and the issue is still happening. Let me try creating a minimal test. The problem is - changing the code affects the reproducibility. -harendra On Wed, 9 Oct 2024 at 10:31, Viktor Dukhovni wrote: > > On Wed, Oct 09, 2024 at 10:24:30AM +0530, Harendra Kumar wrote: > > > I just noticed that cabal seems to be running test suites in parallel. > > We have two test suites. Even though each test suite generates the > > temp names randomly, they use the same prefix, if the generated names > > have a possibility of conflict due to PRNG it may cause a problem. > > That is perhaps the more likely cause rather than hunting this in GHC. > > cabal running tests in parallel without explicitly saying so came as a > > surprise to me. In fact I found an issue in cabal repo asking for a > > "feature" to run them sequentially, the issue is still open - > > https://github.com/haskell/cabal/issues/6751 . Hopefully this is it. > > Just parallel execution is not sufficient to explain the observed > problem, you still need to have the same inode/dev already open > in the same process, or bookkeeping of which dev/ino pairs are > in use to be incorrect. > > So either the Github filesystem is reusing inodes of already deleted, > but still open files (a deviation from expected Unix behaviour), or > somehow GHC fails to correctly track the dev/ino pairs of open handles. > > My best guess is that something is manipulating file descriptors > directly, bypassing the Handle layer, and *then* parallel execution > could exacerbate the resulting inconsistent state. > > -- > Viktor. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mle+ocaml at mega-nerd.com Wed Oct 9 06:19:24 2024 From: mle+ocaml at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 9 Oct 2024 17:19:24 +1100 Subject: GHC 9.12 forked In-Reply-To: References: Message-ID: <20241009171924.2cecf6efadda69d8854d0d93@mega-nerd.com> Hi, I have checked out this branch and built the compiler, but I notice that it still defines the same version of the `base` library as `ghc-9.10`. What are the next steps? Is there anything I can do to help? Thanks, Erik Zubin Duggal wrote: > GHC 9.12 has been forked, feel free to assign MRs to marge. > > You can tag patches as backport-needed-9.12 for them to be > considered for inclusion into GHC 9.12.1. > > On 24/09/25 15:52, Zubin Duggal wrote: > >Hi all, > > > >I hope to fork GHC 9.12 by the end of this week. To do so, > >I need a few large MRs to land. The list is in this comment: > >https://gitlab.haskell.org/ghc/ghc/-/issues/25123#note_585059 > > > >Due to our ongoing CI capacity issues, I ask that you hold > >off on assigning any new MRs to marge, particularly ones that > >have not passed a full-ci pipeline. > > > >If you need your MR to be included in GHC 9.12.1, all you need > >to do is add the appropriate milestone. If the MRs do not make > >it in by the fork date, I will follow up on them and backport > >them to the branch if appropriate. > > > >I will send an email once the fork has been successfully > >completed and it is safe to assign to Marge once more. > > > >Thanks, > >Zubin > -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From harendra.kumar at gmail.com Wed Oct 9 06:45:32 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 9 Oct 2024 12:15:32 +0530 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: We do use low level C APIs and GHC APIs to create a Handle in the event watching module. But that is for the watch-root and not for the file that is experiencing this problem. So here is how it works. We have a top level directory which is watched for events using inotify. We first create this directory, this directory is opened using inotify_init which returns a C file descriptor. We then create a Handle from this fd, this Handle is used for watching inotify events. We are then creating a file inside this directory which is being watched while we are reading events from the parent directory. The resource-busy issue occurs when creating a file inside this directory. So we are not creating the Handle for the file in question in a non-standard manner, but the parent directory Handle is being created in that manner. I do not know if that somehow affects anything. Or if the fact that the directory is being watched using inotify makes any difference? The code for creating the watch Handle is here: https://github.com/composewell/streamly/blob/bbac52d9e09fa5ad760ab6ee5572c701e198d4ee/src/Streamly/Internal/FileSystem/Event/Linux.hs#L589 . Viktor, you may want to take a quick look at this to see if it can make any difference to the issue at hand. -harendra On Wed, 9 Oct 2024 at 10:31, Viktor Dukhovni wrote: > > On Wed, Oct 09, 2024 at 10:24:30AM +0530, Harendra Kumar wrote: > > > I just noticed that cabal seems to be running test suites in parallel. > > We have two test suites. Even though each test suite generates the > > temp names randomly, they use the same prefix, if the generated names > > have a possibility of conflict due to PRNG it may cause a problem. > > That is perhaps the more likely cause rather than hunting this in GHC. > > cabal running tests in parallel without explicitly saying so came as a > > surprise to me. In fact I found an issue in cabal repo asking for a > > "feature" to run them sequentially, the issue is still open - > > https://github.com/haskell/cabal/issues/6751 . Hopefully this is it. > > Just parallel execution is not sufficient to explain the observed > problem, you still need to have the same inode/dev already open > in the same process, or bookkeeping of which dev/ino pairs are > in use to be incorrect. > > So either the Github filesystem is reusing inodes of already deleted, > but still open files (a deviation from expected Unix behaviour), or > somehow GHC fails to correctly track the dev/ino pairs of open handles. > > My best guess is that something is manipulating file descriptors > directly, bypassing the Handle layer, and *then* parallel execution > could exacerbate the resulting inconsistent state. > > -- > Viktor. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ietf-dane at dukhovni.org Wed Oct 9 23:02:32 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Oct 2024 10:02:32 +1100 Subject: openFile gives "file is locked" error on Linux when creating a non-existing file In-Reply-To: References: Message-ID: On Wed, Oct 09, 2024 at 12:15:32PM +0530, Harendra Kumar wrote: > We do use low level C APIs and GHC APIs to create a Handle in the > event watching module. But that is for the watch-root and not for the > file that is experiencing this problem. So here is how it works. We > have a top level directory which is watched for events using inotify. > We first create this directory, this directory is opened using > inotify_init which returns a C file descriptor. We then create a > Handle from this fd, this Handle is used for watching inotify events. > We are then creating a file inside this directory which is being > watched while we are reading events from the parent directory. The > resource-busy issue occurs when creating a file inside this directory. > So we are not creating the Handle for the file in question in a > non-standard manner, but the parent directory Handle is being created > in that manner. I do not know if that somehow affects anything. Or if > the fact that the directory is being watched using inotify makes any > difference? > > The code for creating the watch Handle is here: > https://github.com/composewell/streamly/blob/bbac52d9e09fa5ad760ab6ee5572c701e198d4ee/src/Streamly/Internal/FileSystem/Event/Linux.hs#L589 > . Viktor, you may want to take a quick look at this to see if it can > make any difference to the issue at hand. I don't have the cycles to isolate the problem. I still suspect that your code is somehow directly closing file descriptors associated with a Handle. This then orphans the associated logical reader/writer lock, which then gets inherited by the next incarnation of the same (dev, ino) pair. However, if the filesystem underlying "/tmp" were actually "tmpfs", inode reuse would be quite unlikely, because tmpfs inodes are assigned from a strictly incrementing counter: $ for i in {1..10}; do touch /tmp/foobar; ls -i /tmp/foobar; rm /tmp/foobar; done 3830 /tmp/foobar 3831 /tmp/foobar 3832 /tmp/foobar 3833 /tmp/foobar 3834 /tmp/foobar 3835 /tmp/foobar 3836 /tmp/foobar 3837 /tmp/foobar 3838 /tmp/foobar 3839 /tmp/foobar but IIRC you mentioned that on Github "/tmp" is ext4, not "tmpfs" (perhaps RAM-backed storage is a more scarce resource), in which case indeed inode reuse is quite likely: $ for i in {1..10}; do touch /var/tmp/foobar; ls -i /var/tmp/foobar; rm /var/tmp/foobar; done 25854141 /var/tmp/foobar 25854142 /var/tmp/foobar 25854141 /var/tmp/foobar 25854142 /var/tmp/foobar 25854141 /var/tmp/foobar 25854142 /var/tmp/foobar 25854141 /var/tmp/foobar 25854142 /var/tmp/foobar 25854141 /var/tmp/foobar 25854142 /var/tmp/foobar But since normal open/close of Handles acquires the lock after open, and releases it before close, the evidence points to a bypass of the normal open file lifecycle. Your codebase contains a bunch of custom file management logic, which could be the source the of problem. To find the problem code path, you'd probably need to instrument the RTS lock/unlock code to log its activity: (mode, descriptor, dev, ino) tuples being added and removed. And strace execution to be able to identify descriptor open and close events. Ideally the problem will be reproducible even with strace. Good luck. -- Viktor. From zubin at well-typed.com Wed Oct 16 11:51:10 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Wed, 16 Oct 2024 17:21:10 +0530 Subject: [ANNOUNCE] GHC 9.12.1-alpha1 is now available Message-ID: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst Cheers, Zubin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From george.colpitts at gmail.com Wed Oct 16 19:52:44 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 16 Oct 2024 16:52:44 -0300 Subject: [ANNOUNCE] GHC 9.12.1-alpha1 is now available In-Reply-To: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> References: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> Message-ID: It worked for me on my M2 mac but only after uninstalling and reinstalling Command Line Tools. Hopefully the problem I had was unique to me. I got an error when I ran ./configure on my M2 mac: checking C++ standard library flavour... actest.cpp:1:10: fatal error: 'iostream' file not found 1 | #include | ^~~~~~~~~~ 1 error generated. configure: error: Failed to compile test program Following is the complete output I got checking for opt-17... no checking for opt-17.0... no checking for opt17... no checking for opt-16... no checking for opt-16.0... no checking for opt16... no checking for opt-15... no checking for opt-15.0... no checking for opt15... no checking for opt-14... no checking for opt-14.0... no checking for opt14... no checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt... opt checking opt version (18.1.8) is between 13 and 20... yes checking for clang-19... no checking for clang-19.0... no checking for clang19... no checking for clang-18... clang-18 checking clang-18 version (18.1.8) is between 13 and 20... yes configure: $CC is not gcc; assuming it's a reasonably new C compiler checking whether CC supports -no-pie... no checking whether CC supports flags passed by GHC when compiling via C... yes checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether ld supports response files... yes checking C++ standard library flavour... actest.cpp:1:10: fatal error: 'iostream' file not found 1 | #include | ^~~~~~~~~~ 1 error generated. configure: error: Failed to compile test program On Wed, Oct 16, 2024 at 8:51 AM Zubin Duggal wrote: > The GHC developers are very pleased to announce the availability > of the first alpha release of GHC 9.12.1. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org > ][]. > > > We hope to have this release available via ghcup shortly. > > GHC 9.12 will bring a number of new features and improvements, including: > > * The new language extension [OrPatterns] allowing you to combine > multiple > pattern clauses into one. > > * The [MultilineStrings] language extension to allow you to more easily > write > strings spanning multiple lines in your source code. > > * Improvements to the OverloadedRecordDot extension, allowing the > built-in > `HasField` class to be used for records with fields of non lifted > representations. > > * The [NamedDefaults] language extension has been introduced allowing > you to > define defaults for typeclasses other than `Num`. > > * More deterministic object code output, controlled by the > `-fobject-determinism` > flag, which improves determinism of builds a lot (though does not > fully do so) > at the cost of some compiler performance (1-2%). See #12935 for the > details > > * GHC now accepts type syntax in expressions as part of [GHC Proposal > #281]. > > * ... and many more > > A full accounting of changes can be found in the [release notes][]. > As always, GHC's release status, including planned future releases, can > be found on the GHC Wiki [status][]. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket][] if you see > anything amiss. > > > [release notes]: > https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html > [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status > [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [OrPatterns]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > [MultilineStrings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst > [GHC Proposal #281]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > [NamedDefaults]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst > > > Cheers, > Zubin > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Oct 16 23:37:46 2024 From: ben at well-typed.com (Ben Gamari) Date: Wed, 16 Oct 2024 19:37:46 -0400 Subject: GHC 9.8.3 release status Message-ID: <87msj3d3g9.fsf@smart-cactus.org> Hi all, Unfortunately, GHC's packaging testsuite has revealed an installation issue affecting the GHC 9.8.3 release which was scheduled to be published today. Consequently, the release date will be pushed back to Friday at the earliest. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Wed Oct 16 23:44:12 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 16 Oct 2024 20:44:12 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available In-Reply-To: <42D560B6-8769-4004-AFB0-FD36C1B8E828@gmail.com> References: <42D560B6-8769-4004-AFB0-FD36C1B8E828@gmail.com> Message-ID: Thanks Vanessa, it seems you had the same workaround: " remove and reinstall XCode command-line tools." Zubin What OS were the install tests run on? I'm running on 15.0.1. I think 15.1 is coming at the end of the month around the same time as alpha 2, hopefully 15.1 will be accompanied by a new version of XCode command-line tools that resolves these issues. On Wed, Oct 16, 2024 at 7:58 PM Vanessa McHale wrote: > I encountered something similar, Apple had been majorly slacking. > > [image: 89166504e40f4869ea825dd70048017861ec8578.png] > > Cabal can't find C++ headers for digest/text on Mac (Sequoia) > > discourse.haskell.org > > > > > > On Oct 16, 2024, at 3:53 PM, George Colpitts > wrote: > >  > It worked for me on my M2 mac but only after uninstalling and reinstalling > Command Line Tools. > > Hopefully the problem I had was unique to me. I got an error when I ran > ./configure on my M2 mac: > > checking C++ standard library flavour... actest.cpp:1:10: fatal error: > 'iostream' file not found > 1 | #include > | ^~~~~~~~~~ > 1 error generated. > configure: error: Failed to compile test program > > Following is the complete output I got > > checking for opt-17... no > checking for opt-17.0... no > checking for opt17... no > checking for opt-16... no > checking for opt-16.0... no > checking for opt16... no > checking for opt-15... no > checking for opt-15.0... no > checking for opt15... no > checking for opt-14... no > checking for opt-14.0... no > checking for opt14... no > checking for opt-13... no > checking for opt-13.0... no > checking for opt13... no > checking for opt... opt > checking opt version (18.1.8) is between 13 and 20... yes > checking for clang-19... no > checking for clang-19.0... no > checking for clang19... no > checking for clang-18... clang-18 > checking clang-18 version (18.1.8) is between 13 and 20... yes > configure: $CC is not gcc; assuming it's a reasonably new C compiler > checking whether CC supports -no-pie... no > checking whether CC supports flags passed by GHC when compiling via C... > yes > checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and > CPPFLAGS... done > checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, > CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done > checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, > CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done > checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, > CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether ld supports response files... yes > checking C++ standard library flavour... actest.cpp:1:10: fatal error: > 'iostream' file not found > 1 | #include > | ^~~~~~~~~~ > 1 error generated. > configure: error: Failed to compile test program > > On Wed, Oct 16, 2024 at 8:51 AM Zubin Duggal wrote: > >> The GHC developers are very pleased to announce the availability >> of the first alpha release of GHC 9.12.1. Binary distributions, source >> distributions, and documentation are available at [downloads.haskell.org >> ][]. >> >> >> We hope to have this release available via ghcup shortly. >> >> GHC 9.12 will bring a number of new features and improvements, including: >> >> * The new language extension [OrPatterns] allowing you to combine >> multiple >> pattern clauses into one. >> >> * The [MultilineStrings] language extension to allow you to more easily >> write >> strings spanning multiple lines in your source code. >> >> * Improvements to the OverloadedRecordDot extension, allowing the >> built-in >> `HasField` class to be used for records with fields of non lifted >> representations. >> >> * The [NamedDefaults] language extension has been introduced allowing >> you to >> define defaults for typeclasses other than `Num`. >> >> * More deterministic object code output, controlled by the >> `-fobject-determinism` >> flag, which improves determinism of builds a lot (though does not >> fully do so) >> at the cost of some compiler performance (1-2%). See #12935 for the >> details >> >> * GHC now accepts type syntax in expressions as part of [GHC Proposal >> #281]. >> >> * ... and many more >> >> A full accounting of changes can be found in the [release notes][]. >> As always, GHC's release status, including planned future releases, can >> be found on the GHC Wiki [status][]. >> >> We would like to thank GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell >> Foundation, and other anonymous contributors whose on-going financial >> and in-kind support has facilitated GHC maintenance and release >> management over the years. Finally, this release would not have been >> possible without the hundreds of open-source contributors whose work >> comprise this release. >> >> As always, do give this release a try and open a [ticket][] if you see >> anything amiss. >> >> >> [release notes]: >> https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html >> [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status >> [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [OrPatterns]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst >> [MultilineStrings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst >> [GHC Proposal #281]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst >> [NamedDefaults]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst >> >> >> Cheers, >> Zubin >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 89166504e40f4869ea825dd70048017861ec8578.png Type: image/png Size: 2738 bytes Desc: not available URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sun Oct 20 12:06:01 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 20 Oct 2024 13:06:01 +0100 Subject: How is ExitCode handled? Message-ID: Hello all, I'm not sure I understand how an `ExitCode` exception is used to terminate a running program. Can anyone clarify? When we call `exitWith`, what we're doing is `throw`ing an `ExitCode` exception: https://www.stackage.org/haddock/lts-22.38/base-4.18.2.1/src/System.Exit.html#exitWith That exception must be caught somewhere, and used to cause the running program to exit with the exit code in question. But where? It's not in the default `uncaughtExceptionHandler`: https://hackage.haskell.org/package/base-4.20.0.0/docs/src/GHC-Conc-Sync.html#setUncaughtExceptionHandler That doesn't do anything special with exit code. It seems like real_handler does: https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.TopHandler.html#topHandler >From my experiements with a small program (below) I conclude that the default handler is installed on every thread, and real_handler is installed *on the main thread only* *below* the default handler, so that if an `ExitCode` exception is thrown the default handler never gets a chance to see it. Is that right? Thanks, Tom {-# LANGUAGE GHC2021 #-} {-# LANGUAGE LambdaCase #-} import System.Environment (getArgs) import System.Exit (ExitCode (ExitFailure)) import Control.Exception (Exception, SomeException (SomeException), throw) import GHC.Conc (forkIO, setUncaughtExceptionHandler, threadDelay) data MyEx = MyEx deriving Show instance Exception MyEx myHandler (SomeException e) = putStrLn $ "In myHandler: " <> show e run f = do setUncaughtExceptionHandler myHandler f main = do getArgs >>= \case -- Exits with exit code 1 ["1"] -> run (throw (ExitFailure 1)) -- Print: In myHandler: MyEx -- Exits with exit code 1 ["2"] -> run (throw MyEx) -- Print: In myHandler: ExitFailure 1 -- Exits with exit code 0 ["3"] -> run (forkIO (throw (ExitFailure 1))) -- Print: In myHandler: MyEx -- Exits with exit code 0 ["4"] -> run (forkIO (throw MyEx)) _ -> error "Need an argument" threadDelay (1000 * 1000) From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sun Oct 20 12:24:34 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 20 Oct 2024 13:24:34 +0100 Subject: How is ExitCode handled? In-Reply-To: References: Message-ID: On Sun, Oct 20, 2024 at 01:06:01PM +0100, Tom Ellis wrote: > From my experiements with a small program (below) I conclude that the > default handler is installed on every thread, and real_handler is > installed *on the main thread only* *below* the default handler, so > that if an `ExitCode` exception is thrown the default handler never > gets a chance to see it. Oh, I see that the uncaught exception handler is called in `reportError`, itself used by `real_handler`, thence `child_handler`, and `forkIO`. https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src//GHC.Internal.Conc.Sync.html#reportError It's also used by the `real_handler` in TopHandler.hs, and thence `topHandler` and `runIO`. https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.TopHandler.html So the uncaught exception handler is not really "installed", it's just used by the handlers installed by `forkIO` and `runMainIO` (the latter wraps main, as per the documentation). So I think I probably understand what's going on now. Tom From ben at well-typed.com Sun Oct 20 16:35:00 2024 From: ben at well-typed.com (Ben Gamari) Date: Sun, 20 Oct 2024 12:35:00 -0400 Subject: [ANNOUNCE] GHC 9.8.3 is now available Message-ID: <87bjzed972.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.8.3. Binary distributions, source distributions, and documentation are available on the [release] page. This release is primarily a bugfix release the 9.8 series. These include: * Significantly improve performance of code loading via dynamic linking (#23415) * Fix a variety of miscompilations involving sub-word-size FFI arguments (#25018, #24314) * Fix a rare miscompilation by the x86 native code generator (#24507) * Improve runtime performance of some applications of `runRW#` (#25055) * Reduce fragmentation when using the non-moving garbage collector (#23340) * Fix source links in Haddock's hyperlinked sources output (#24086) A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling! - Ben [release]: https://www.haskell.org/ghc/download_ghc_9_8_3.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.3/docs/users_guide/9.8.3-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Oct 21 11:02:18 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 21 Oct 2024 12:02:18 +0100 Subject: How is ExitCode handled? In-Reply-To: References: Message-ID: On Sun, Oct 20, 2024 at 01:24:34PM +0100, Tom Ellis wrote: > On Sun, Oct 20, 2024 at 01:06:01PM +0100, Tom Ellis wrote: > > From my experiements with a small program (below) I conclude that the > > default handler is installed on every thread, and real_handler is > > installed *on the main thread only* *below* the default handler, so > > that if an `ExitCode` exception is thrown the default handler never > > gets a chance to see it. > > Oh, I see that the uncaught exception handler is called in > `reportError`, itself used by `real_handler`, thence `child_handler`, > and `forkIO`. > > https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src//GHC.Internal.Conc.Sync.html#reportError > > It's also used by the `real_handler` in TopHandler.hs, and thence > `topHandler` and `runIO`. > > https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.TopHandler.html > > So the uncaught exception handler is not really "installed", it's just > used by the handlers installed by `forkIO` and `runMainIO` (the latter > wraps main, as per the documentation). > > So I think I probably understand what's going on now. I wrote a short article on my findings: https://h2.jaguarpaw.co.uk/posts/exitfailure-doesnt-exit/ Tom From simon.peytonjones at gmail.com Tue Oct 22 10:34:08 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 22 Oct 2024 11:34:08 +0100 Subject: Can't build GHC any more Message-ID: Friends On all my builds, using ./boot; ./configure; ./hadrian/build I am getting the crash below. What should I do? My boot compiler is ghc-9.6. I can't build GHC at all right now, so this is somewhat urgent. Thank you! Simon ]0;Running for 5m11s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] Pattern match is redundant In a case alternative: _ -> ... | 1704 | _ -> pure () | ^^^^^^^^^^^^ | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => _build/stage0/ghc/build/Main.o | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o (and 6 more) => _build/stage0/bin/ghc Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/lib/package.conf.d' '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include -I/home/simonpj/code/HEAD/compiler -I/home/simonpj/code/HEAD/_build/stage0/compiler/build -I/home/simonpj/code/HEAD/libraries/process/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include -I/home/simonpj/code/HEAD/libraries/directory -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build -I/home/simonpj/code/HEAD/libraries/unix/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include -I/home/simonpj/code/HEAD/libraries/time/lib/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o _build/stage0/ghc/build/GHCi/UI/Monad.o _build/stage0/ghc/build/GHCi/UI/Exception.o _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG ===> Command failed with error code: 1 /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldNext' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldDefault' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_push_module' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_clocks_per_second' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_readdir' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_d_name' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_free_dirent' /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed Build failed. make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 simonpj at LHR-WD-22561:~/code/HEAD$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Tue Oct 22 10:54:19 2024 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Tue, 22 Oct 2024 12:54:19 +0200 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: Maybe git submodule update --init --recursive would help, as said in https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources? If not that, a "hadrian/build distclean" maybe? On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones wrote: > > Friends > > On all my builds, using > ./boot; ./configure; ./hadrian/build > I am getting the crash below. What should I do? My boot compiler is ghc-9.6. > > I can't build GHC at all right now, so this is somewhat urgent. > > Thank you! > > Simon > > > ]0;Running for 5m11s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) > ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: _ -> ... > | > 1704 | _ -> pure () > | ^^^^^^^^^^^^ > | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => _build/stage0/ghc/build/Main.o > | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o (and 6 more) => _build/stage0/bin/ghc > Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/lib/package.conf.d' '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include -I/home/simonpj/code/HEAD/compiler -I/home/simonpj/code/HEAD/_build/stage0/compiler/build -I/home/simonpj/code/HEAD/libraries/process/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include -I/home/simonpj/code/HEAD/libraries/directory -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build -I/home/simonpj/code/HEAD/libraries/unix/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include -I/home/simonpj/code/HEAD/libraries/time/lib/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o _build/stage0/ghc/build/GHCi/UI/Monad.o _build/stage0/ghc/build/GHCi/UI/Exception.o _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG > ===> Command failed with error code: 1 > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldNext' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldDefault' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_push_module' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_clocks_per_second' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_readdir' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_d_name' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_free_dirent' > /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed > Build failed. > make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 > simonpj at LHR-WD-22561:~/code/HEAD$ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sam.derbyshire at gmail.com Tue Oct 22 11:01:32 2024 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Tue, 22 Oct 2024 13:01:32 +0200 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: Simon, I think Sebastian already ran into this issue and reported it as #25406 . You might try cherry-picking the commit from !13469 . Best, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Tue Oct 22 11:33:12 2024 From: hecate at glitchbra.in (=?UTF-8?Q?H=C3=A9cate?=) Date: Tue, 22 Oct 2024 13:33:12 +0200 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: I can confirm that using my good old update() function in the repository, I don't encounter the problem (but also I clean the tree all the time): update () {     git pull upstream master     git submodule update --recursive } Le 22/10/2024 à 12:54, Mikolaj Konarski a écrit : > Maybe > > git submodule update --init --recursive > > would help, as said in > https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources? > > If not that, a "hadrian/build distclean" maybe? > > On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones > wrote: >> Friends >> >> On all my builds, using >> ./boot; ./configure; ./hadrian/build >> I am getting the crash below. What should I do? My boot compiler is ghc-9.6. >> >> I can't build GHC at all right now, so this is somewhat urgent. >> >> Thank you! >> >> Simon >> >> >> ]0;Running for 5m11s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], predicted 49s (86%)(/home/simonpj/code/HEAD) >> ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] >> Pattern match is redundant >> In a case alternative: _ -> ... >> | >> 1704 | _ -> pure () >> | ^^^^^^^^^^^^ >> | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => _build/stage0/ghc/build/Main.o >> | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o (and 6 more) => _build/stage0/bin/ghc >> Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/lib/package.conf.d' '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include -I/home/simonpj/code/HEAD/compiler -I/home/simonpj/code/HEAD/_build/stage0/compiler/build -I/home/simonpj/code/HEAD/libraries/process/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include -I/home/simonpj/code/HEAD/libraries/directory -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build -I/home/simonpj/code/HEAD/libraries/unix/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include -I/home/simonpj/code/HEAD/libraries/time/lib/include -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o _build/stage0/ghc/build/GHCi/UI/Monad.o _build/stage0/ghc/build/GHCi/UI/Exception.o _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG >> ===> Command failed with error code: 1 >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldNext' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_rtldDefault' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_push_module' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hsunix_clocks_per_second' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_readdir' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_d_name' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> /usr/bin/ld.gold: error: _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): multiple definition of '__hscore_free_dirent' >> /usr/bin/ld.gold: /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): previous definition here >> collect2: error: ld returned 1 exit status >> `gcc' failed in phase `Linker'. (Exit code: 1) >> ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed >> Build failed. >> make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 >> simonpj at LHR-WD-22561:~/code/HEAD$ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From sgraf1337 at gmail.com Tue Oct 22 13:38:04 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 22 Oct 2024 15:38:04 +0200 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: It is likely that anyone who cannot reproduce the issue is using a boot compiler > 9.6.2. I think Simon has the exact same issue I was having, so !13469 is a cure. Am Di., 22. Okt. 2024 um 13:33 Uhr schrieb Hécate via ghc-devs < ghc-devs at haskell.org>: > I can confirm that using my good old update() function in the > repository, I don't encounter the problem (but also I clean the tree all > the time): > > update () { > git pull upstream master > git submodule update --recursive > } > > Le 22/10/2024 à 12:54, Mikolaj Konarski a écrit : > > Maybe > > > > git submodule update --init --recursive > > > > would help, as said in > > https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources? > > > > If not that, a "hadrian/build distclean" maybe? > > > > On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones > > wrote: > >> Friends > >> > >> On all my builds, using > >> ./boot; ./configure; ./hadrian/build > >> I am getting the crash below. What should I do? My boot compiler is > ghc-9.6. > >> > >> I can't build GHC at all right now, so this is somewhat urgent. > >> > >> Thank you! > >> > >> Simon > >> > >> > >> ]0;Running for 5m11s [11771/39023], predicted 49s > (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], > predicted 49s (86%)(/home/simonpj/code/HEAD) > >> ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] > >> Pattern match is redundant > >> In a case alternative: _ -> ... > >> | > >> 1704 | _ -> pure () > >> | ^^^^^^^^^^^^ > >> | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => > _build/stage0/ghc/build/Main.o > >> | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o > (and 6 more) => _build/stage0/bin/ghc > >> Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi > -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db > '-package-env -' '-package-db _build/stage0/lib/package.conf.d' > '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' > '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id > bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id > deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id > exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id > ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id > ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id > haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id > time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id > unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build > -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen > -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include > -I/home/simonpj/code/HEAD/compiler > -I/home/simonpj/code/HEAD/_build/stage0/compiler/build > -I/home/simonpj/code/HEAD/libraries/process/include > -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include > -I/home/simonpj/code/HEAD/libraries/directory > -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build > -I/home/simonpj/code/HEAD/libraries/unix/include > -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include > -I/home/simonpj/code/HEAD/libraries/time/lib/include > -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include > -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include > -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h > -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build > -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances > -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 > -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables > -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline > _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o > _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o > _build/stage0/ghc/build/GHCi/UI/Monad.o > _build/stage0/ghc/build/GHCi/UI/Exception.o > _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m > -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG > >> ===> Command failed with error code: 1 > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hsunix_rtldNext' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hsunix_rtldDefault' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hsunix_push_module' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hsunix_clocks_per_second' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hscore_readdir' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hscore_d_name' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> /usr/bin/ld.gold: error: > _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): > multiple definition of '__hscore_free_dirent' > >> /usr/bin/ld.gold: > /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): > previous definition here > >> collect2: error: ld returned 1 exit status > >> `gcc' failed in phase `Linker'. (Exit code: 1) > >> ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed > >> Build failed. > >> make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 > >> simonpj at LHR-WD-22561:~/code/HEAD$ > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Oct 22 15:11:55 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 22 Oct 2024 11:11:55 -0400 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: I can confirm that recent ghc doesn't work with 9.6.x. I upgraded my updater/booter script to configure with 9.10.1 and the build was much happier, On Tue, Oct 22, 2024 at 9:38 AM Sebastian Graf wrote: > It is likely that anyone who cannot reproduce the issue is using a boot > compiler > 9.6.2. > I think Simon has the exact same issue I was having, so !13469 is a cure. > > Am Di., 22. Okt. 2024 um 13:33 Uhr schrieb Hécate via ghc-devs < > ghc-devs at haskell.org>: > >> I can confirm that using my good old update() function in the >> repository, I don't encounter the problem (but also I clean the tree all >> the time): >> >> update () { >> git pull upstream master >> git submodule update --recursive >> } >> >> Le 22/10/2024 à 12:54, Mikolaj Konarski a écrit : >> > Maybe >> > >> > git submodule update --init --recursive >> > >> > would help, as said in >> > https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources >> ? >> > >> > If not that, a "hadrian/build distclean" maybe? >> > >> > On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones >> > wrote: >> >> Friends >> >> >> >> On all my builds, using >> >> ./boot; ./configure; ./hadrian/build >> >> I am getting the crash below. What should I do? My boot compiler is >> ghc-9.6. >> >> >> >> I can't build GHC at all right now, so this is somewhat urgent. >> >> >> >> Thank you! >> >> >> >> Simon >> >> >> >> >> >> ]0;Running for 5m11s [11771/39023], predicted 49s >> (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], >> predicted 49s (86%)(/home/simonpj/code/HEAD) >> >> ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] >> >> Pattern match is redundant >> >> In a case alternative: _ -> ... >> >> | >> >> 1704 | _ -> pure () >> >> | ^^^^^^^^^^^^ >> >> | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => >> _build/stage0/ghc/build/Main.o >> >> | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o >> (and 6 more) => _build/stage0/bin/ghc >> >> Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi >> -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db >> '-package-env -' '-package-db _build/stage0/lib/package.conf.d' >> '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' >> '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id >> bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id >> deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id >> exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id >> ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id >> ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id >> haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id >> time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id >> unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build >> -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen >> -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include >> -I/home/simonpj/code/HEAD/compiler >> -I/home/simonpj/code/HEAD/_build/stage0/compiler/build >> -I/home/simonpj/code/HEAD/libraries/process/include >> -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include >> -I/home/simonpj/code/HEAD/libraries/directory >> -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build >> -I/home/simonpj/code/HEAD/libraries/unix/include >> -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include >> -I/home/simonpj/code/HEAD/libraries/time/lib/include >> -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include >> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include >> -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h >> -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build >> -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances >> -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 >> -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables >> -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline >> _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o >> _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o >> _build/stage0/ghc/build/GHCi/UI/Monad.o >> _build/stage0/ghc/build/GHCi/UI/Exception.o >> _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m >> -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG >> >> ===> Command failed with error code: 1 >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hsunix_rtldNext' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hsunix_rtldDefault' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hsunix_push_module' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hsunix_clocks_per_second' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hscore_readdir' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hscore_d_name' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> /usr/bin/ld.gold: error: >> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >> multiple definition of '__hscore_free_dirent' >> >> /usr/bin/ld.gold: >> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >> previous definition here >> >> collect2: error: ld returned 1 exit status >> >> `gcc' failed in phase `Linker'. (Exit code: 1) >> >> ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed >> >> Build failed. >> >> make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 >> >> simonpj at LHR-WD-22561:~/code/HEAD$ >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -- >> Hécate ✨ >> 🐦: @TechnoEmpress >> IRC: Hecate >> WWW: https://glitchbra.in >> RUN: BSD >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Thu Oct 24 09:31:12 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Thu, 24 Oct 2024 11:31:12 +0200 Subject: Can't build GHC any more In-Reply-To: References: Message-ID: FWIW, https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13479 has landed and should have fixed the issue. Am Di., 22. Okt. 2024 um 17:12 Uhr schrieb Brandon Allbery < allbery.b at gmail.com>: > I can confirm that recent ghc doesn't work with 9.6.x. I upgraded my > updater/booter script to configure with 9.10.1 and the build was much > happier, > > On Tue, Oct 22, 2024 at 9:38 AM Sebastian Graf > wrote: > >> It is likely that anyone who cannot reproduce the issue is using a boot >> compiler > 9.6.2. >> I think Simon has the exact same issue I was having, so !13469 is a cure. >> >> Am Di., 22. Okt. 2024 um 13:33 Uhr schrieb Hécate via ghc-devs < >> ghc-devs at haskell.org>: >> >>> I can confirm that using my good old update() function in the >>> repository, I don't encounter the problem (but also I clean the tree all >>> the time): >>> >>> update () { >>> git pull upstream master >>> git submodule update --recursive >>> } >>> >>> Le 22/10/2024 à 12:54, Mikolaj Konarski a écrit : >>> > Maybe >>> > >>> > git submodule update --init --recursive >>> > >>> > would help, as said in >>> > >>> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/getting-the-sources? >>> > >>> > If not that, a "hadrian/build distclean" maybe? >>> > >>> > On Tue, Oct 22, 2024 at 12:34 PM Simon Peyton Jones >>> > wrote: >>> >> Friends >>> >> >>> >> On all my builds, using >>> >> ./boot; ./configure; ./hadrian/build >>> >> I am getting the crash below. What should I do? My boot compiler is >>> ghc-9.6. >>> >> >>> >> I can't build GHC at all right now, so this is somewhat urgent. >>> >> >>> >> Thank you! >>> >> >>> >> Simon >>> >> >>> >> >>> >> ]0;Running for 5m11s [11771/39023], predicted 49s >>> (86%)(/home/simonpj/code/HEAD) ]0;Running for 5m16s [11771/39023], >>> predicted 49s (86%)(/home/simonpj/code/HEAD) >>> >> ghc/GHCi/UI.hs:1704:5: warning: [GHC-53633] [-Woverlapping-patterns] >>> >> Pattern match is redundant >>> >> In a case alternative: _ -> ... >>> >> | >>> >> 1704 | _ -> pure () >>> >> | ^^^^^^^^^^^^ >>> >> | Run Ghc CompileHs (Stage0 InTreeLibs): ghc/Main.hs => >>> _build/stage0/ghc/build/Main.o >>> >> | Run Ghc LinkHs (Stage0 InTreeLibs): _build/stage0/ghc/build/Main.o >>> (and 6 more) => _build/stage0/bin/ghc >>> >> Command line: /home/simonpj/.ghcup/bin/ghc -Wall -Wcompat -hisuf hi >>> -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db >>> '-package-env -' '-package-db _build/stage0/lib/package.conf.d' >>> '-this-unit-id ghc-bin-9.13.20241015-inplace' '-this-package-name ghc-bin' >>> '-package-id array-0.5.5.0' '-package-id base-4.18.0.0' '-package-id >>> bytestring-0.11.4.0' '-package-id containers-0.6.7' '-package-id >>> deepseq-1.4.8.1' '-package-id directory-1.3.9.0-inplace' '-package-id >>> exceptions-0.10.7' '-package-id filepath-1.5.2.0-inplace' '-package-id >>> ghc-9.13-inplace' '-package-id ghc-boot-9.13-inplace' '-package-id >>> ghc-prim-0.10.0' '-package-id ghci-9.13-inplace' '-package-id >>> haskeline-0.8.2.1' '-package-id process-1.6.25.0-inplace' '-package-id >>> time-1.14-inplace' '-package-id transformers-0.6.1.0' '-package-id >>> unix-2.8.5.1-inplace' -i -i/home/simonpj/code/HEAD/_build/stage0/ghc/build >>> -i/home/simonpj/code/HEAD/_build/stage0/ghc/build/ghc/autogen >>> -i/home/simonpj/code/HEAD/ghc -I_build/stage0/ghc/build >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/process-1.6.17.0/include >>> -I/home/simonpj/code/HEAD/compiler >>> -I/home/simonpj/code/HEAD/_build/stage0/compiler/build >>> -I/home/simonpj/code/HEAD/libraries/process/include >>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/process/build/include >>> -I/home/simonpj/code/HEAD/libraries/directory >>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/directory/build >>> -I/home/simonpj/code/HEAD/libraries/unix/include >>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/unix/build/include >>> -I/home/simonpj/code/HEAD/libraries/time/lib/include >>> -I/home/simonpj/code/HEAD/_build/stage0/libraries/time/build/lib/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/directory-1.3.8.1/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/time-1.12.2/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/bytestring-0.11.4.0/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/base-4.18.0.0/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/ghc-bignum-1.3/include >>> -I/home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include >>> -optP-include -optP_build/stage0/ghc/build/ghc/autogen/cabal_macros.h >>> -optP-DHAVE_INTERNAL_INTERPRETER -outputdir _build/stage0/ghc/build >>> -fdiagnostics-color=always -Wall -Wnoncanonical-monad-instances >>> -Wnoncanonical-monoid-instances -rtsopts=all '-with-rtsopts=-K512M -H -I5 >>> -T' -threaded -XGHC2021 -XNoImplicitPrelude -XScopedTypeVariables >>> -XBangPatterns -no-auto-link-packages -rtsopts -optc-Wno-error=inline >>> _build/stage0/ghc/build/Main.o _build/stage0/ghc/build/GHCi/Leak.o >>> _build/stage0/ghc/build/GHCi/UI.o _build/stage0/ghc/build/GHCi/UI/Info.o >>> _build/stage0/ghc/build/GHCi/UI/Monad.o >>> _build/stage0/ghc/build/GHCi/UI/Exception.o >>> _build/stage0/ghc/build/GHCi/Util.o -o _build/stage0/bin/ghc -O -H32m >>> -dcore-lint -fomit-interface-pragmas -I_build/stage0/compiler/build -DDEBUG >>> >> ===> Command failed with error code: 1 >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hsunix_rtldNext' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hsunix_rtldDefault' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hsunix_push_module' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hsunix_clocks_per_second' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hscore_readdir' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hscore_d_name' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> /usr/bin/ld.gold: error: >>> _build/stage0/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.5.1-inplace/libHSunix-2.8.5.1-inplace.a(HsUnix.o): >>> multiple definition of '__hscore_free_dirent' >>> >> /usr/bin/ld.gold: >>> /home/simonpj/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/x86_64-linux-ghc-9.6.2/unix-2.8.1.0/libHSunix-2.8.1.0.a(HsUnix.o): >>> previous definition here >>> >> collect2: error: ld returned 1 exit status >>> >> `gcc' failed in phase `Linker'. (Exit code: 1) >>> >> ]0;Finished in 5m19s(/home/simonpj/code/HEAD) Command failed >>> >> Build failed. >>> >> make: *** [/home/simonpj/code/Makefile-spj:12: all] Error 1 >>> >> simonpj at LHR-WD-22561:~/code/HEAD$ >>> >> _______________________________________________ >>> >> ghc-devs mailing list >>> >> ghc-devs at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > ghc-devs at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> -- >>> Hécate ✨ >>> 🐦: @TechnoEmpress >>> IRC: Hecate >>> WWW: https://glitchbra.in >>> RUN: BSD >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: