More failure

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

More failure

GHC - devs mailing list

More pain.  I said

sh validate --fast --no-clean

and got this output

Error when running Shake build system:

  at action, called at src/Rules.hs:71:19 in main:Rules

  at need, called at src/Rules.hs:93:5 in main:Rules

* Depends on: _validatebuild/stage1/lib/package.conf.d/base-4.14.0.0.conf

  at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register

* Depends on: _validatebuild/stage1/libraries/base/build/libHSbase-4.14.0.0-ghc8.11.0.20191201.so

  at need, called at src/Rules/Library.hs:146:5 in main:Rules.Library

* Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o

  at &%>, called at src/Rules/Compile.hs:54:7 in main:Rules.Compile

* Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi

  at error, called at src/Development/Shake/Internal/Rules/Files.hs:245:13 in shake-0.18.3-593067565aafb558d09b4352b8abc327d8911a39a0e9abab2804b002b1ae536e:Development.Shake.Internal.Rules.Files

* Raised the exception:

Error, &%> rule failed to produce 1 file (out of 2)

  _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o

  _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi – MISSING

I think I’m going to have to revert to ‘sh validate –legacy’.  Please let me know when I should try again with Hadrian.

Simon


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: More failure

Ben Gamari-2
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> More pain.  I said
> sh validate --fast --no-clean
> and got this output
>
> Error when running Shake build system:
>
>   at action, called at src/Rules.hs:71:19 in main:Rules
>
>   at need, called at src/Rules.hs:93:5 in main:Rules
>
> * Depends on: _validatebuild/stage1/lib/package.conf.d/base-4.14.0.0.conf
>
>   at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register
>
> * Depends on: _validatebuild/stage1/libraries/base/build/libHSbase-4.14.0.0-ghc8.11.0.20191201.so
>
>   at need, called at src/Rules/Library.hs:146:5 in main:Rules.Library
>
> * Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o
>
>   at &%>, called at src/Rules/Compile.hs:54:7 in main:Rules.Compile
>
> * Depends on: _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi
>
>   at error, called at src/Development/Shake/Internal/Rules/Files.hs:245:13 in shake-0.18.3-593067565aafb558d09b4352b8abc327d8911a39a0e9abab2804b002b1ae536e:Development.Shake.Internal.Rules.Files
>
> * Raised the exception:
>
> Error, &%> rule failed to produce 1 file (out of 2)
>
>   _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_o
>
>   _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_hi - MISSING
I suspect that this is due to a previously-failed build and #17534.
The workaround is to remove the traces of the half-finished build:

    rm _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.*

and rerun the build; this may require multiple iterations.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: More failure

GHC - devs mailing list
| I suspect that this is due to a previously-failed build and #17534.
| The workaround is to remove the traces of the half-finished build:
|
|     rm
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.*
|
| and rerun the build; this may require multiple iterations.

Ugh.  That's not a very happy state of affairs, is it?  It didn't happen with 'make'.  Is it a fundamental problem, or just not yet fixed?

Simon

| -----Original Message-----
| From: Ben Gamari <[hidden email]>
| Sent: 09 December 2019 22:28
| To: Simon Peyton Jones <[hidden email]>; [hidden email]
| Subject: Re: More failure
|
| Simon Peyton Jones via ghc-devs <[hidden email]> writes:
|
| > More pain.  I said
| > sh validate --fast --no-clean
| > and got this output
| >
| > Error when running Shake build system:
| >
| >   at action, called at src/Rules.hs:71:19 in main:Rules
| >
| >   at need, called at src/Rules.hs:93:5 in main:Rules
| >
| > * Depends on: _validatebuild/stage1/lib/package.conf.d/base-
| 4.14.0.0.conf
| >
| >   at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register
| >
| > * Depends on: _validatebuild/stage1/libraries/base/build/libHSbase-
| 4.14.0.0-ghc8.11.0.20191201.so
| >
| >   at need, called at src/Rules/Library.hs:146:5 in main:Rules.Library
| >
| > * Depends on:
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_
| o
| >
| >   at &%>, called at src/Rules/Compile.hs:54:7 in main:Rules.Compile
| >
| > * Depends on:
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_
| o
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_
| hi
| >
| >   at error, called at
| src/Development/Shake/Internal/Rules/Files.hs:245:13 in shake-0.18.3-
| 593067565aafb558d09b4352b8abc327d8911a39a0e9abab2804b002b1ae536e:Developm
| ent.Shake.Internal.Rules.Files
| >
| > * Raised the exception:
| >
| > Error, &%> rule failed to produce 1 file (out of 2)
| >
| >
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_
| o
| >
| >
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.dyn_
| hi - MISSING
|
| I suspect that this is due to a previously-failed build and #17534.
| The workaround is to remove the traces of the half-finished build:
|
|     rm
| _validatebuild/stage1/libraries/base/build/GHC/IO/Handle/Lock/Common.*
|
| and rerun the build; this may require multiple iterations.
|
| Cheers,
|
| - Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: More failure

Andrey Mokhov
In reply to this post by GHC - devs mailing list

Hi Simon,

 

(Re-sending from the email address that’s allowed on the mailing list.)

 

> Ugh.  That's not a very happy state of affairs, is it?  It didn't happen with 'make'.

> Is it a fundamental problem, or just not yet fixed?

 

I think this is not a fundamental problem, but the problem of getting dependencies right.

 

In this case, the complexity comes from the fact that a single invocation of GHC produces a set of files, and which set depends on the command line flags, which are in turn determined dynamically by reading environment settings (specifically, `platformSupportsSharedLibs`).

 

Such rules are hard to describe precisely, because build systems are tuned to the typical case where we statically know, for every output file, which rule produces it -- recall the Tasks = k -> Maybe Task function from our paper. In this case, we deal with something like k -> f (Maybe Task) instead, i.e. with `f` around the Maybe.

 

The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy.

 

(I never really had a chance to look at dynamic builds, since they are not supported on Windows. I guess I should finally find a Linux box for Hadrian.)

 

Cheers,

Andrey


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: More failure

lonetiger
Hi Andrey, 

I'm not sure what the original issue here is (should probably find the original message) but

The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy.

I believe this typically works because GCC and GHC support dumping the dependencies that a command would have caused to a file. So your dynamic dependencies don't matter as their static to the build system after this invocation. 


These Compilers are able to dump out make rules which enabled better dependency handling.. 

Kind regards, 
Tamar 

Sent from my Mobile

On Tue, Dec 10, 2019, 00:58 Andrey Mokhov <[hidden email]> wrote:

Hi Simon,

 

(Re-sending from the email address that’s allowed on the mailing list.)

 

> Ugh.  That's not a very happy state of affairs, is it?  It didn't happen with 'make'.

> Is it a fundamental problem, or just not yet fixed?

 

I think this is not a fundamental problem, but the problem of getting dependencies right.

 

In this case, the complexity comes from the fact that a single invocation of GHC produces a set of files, and which set depends on the command line flags, which are in turn determined dynamically by reading environment settings (specifically, `platformSupportsSharedLibs`).

 

Such rules are hard to describe precisely, because build systems are tuned to the typical case where we statically know, for every output file, which rule produces it -- recall the Tasks = k -> Maybe Task function from our paper. In this case, we deal with something like k -> f (Maybe Task) instead, i.e. with `f` around the Maybe.

 

The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy.

 

(I never really had a chance to look at dynamic builds, since they are not supported on Windows. I guess I should finally find a Linux box for Hadrian.)

 

Cheers,

Andrey

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: More failure

Andrey Mokhov
Hi Tamar,

I think the difficulty here is more with dynamic *outputs* rather than dynamic inputs/dependencies. 

We do not statically know which of the following three alternatives holds:
  • `*.dyn_o/hi` files are not built at all.
  • `*.dyn_o/hi` files are built via a separate execution of GHC.
  • `*.dyn_o/hi` files are built together with `*.o/hi` files, in a single execution of GHC with `-dynamic-too`.
Here is the current implementation: 


I believe the last person looking into this was James Foster, so CC-ing to him in case he has any insights.

Cheers,
Andrey


From: Phyx <[hidden email]>
Sent: 10 December 2019 07:47
To: Andrey Mokhov <[hidden email]>
Cc: Simon Peyton-Jones ([hidden email]) <[hidden email]>; Ben Gamari <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: More failure
 
Hi Andrey, 

I'm not sure what the original issue here is (should probably find the original message) but

The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy.

I believe this typically works because GCC and GHC support dumping the dependencies that a command would have caused to a file. So your dynamic dependencies don't matter as their static to the build system after this invocation. 


These Compilers are able to dump out make rules which enabled better dependency handling.. 

Kind regards, 
Tamar 

Sent from my Mobile

On Tue, Dec 10, 2019, 00:58 Andrey Mokhov <[hidden email]> wrote:

Hi Simon,

 

(Re-sending from the email address that’s allowed on the mailing list.)

 

> Ugh.  That's not a very happy state of affairs, is it?  It didn't happen with 'make'.

> Is it a fundamental problem, or just not yet fixed?

 

I think this is not a fundamental problem, but the problem of getting dependencies right.

 

In this case, the complexity comes from the fact that a single invocation of GHC produces a set of files, and which set depends on the command line flags, which are in turn determined dynamically by reading environment settings (specifically, `platformSupportsSharedLibs`).

 

Such rules are hard to describe precisely, because build systems are tuned to the typical case where we statically know, for every output file, which rule produces it -- recall the Tasks = k -> Maybe Task function from our paper. In this case, we deal with something like k -> f (Maybe Task) instead, i.e. with `f` around the Maybe.

 

The Make build system happens to do the right thing, somehow. I believe we should be able to express the same logic in Shake, but it's not easy.

 

(I never really had a chance to look at dynamic builds, since they are not supported on Windows. I guess I should finally find a Linux box for Hadrian.)

 

Cheers,

Andrey

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs