STP_STUB option leads to build failure #595
Comments
|
I didn't realize that this hadn't been fixed! There's a PR #278 open for it. From years ago -- apologies for letting that slip through the cracks! The issue is that the real STP build leaves this in the while the stub STP build leaves this: The build of the And I believe that it follows the links and thus knows what the ultimate name of the library is, and encodes that in the executable. For example, BSC built with the real STP has the following output from while BSC built with the stub STP has this So when BSC is run, it needs to find that exact file name in the LD search patch. That would be fine, if we installed all of the file from This works for BSC built with real STP, but doesn't work for BSC built with the sub (which is expecting to find The PR #278 attempts to make the STP stub situation work by installing multiple files (the variable Any preference? I'm in favor of installing one name, maybe like this: Or we could fix up the stub FYI, I notice that trying to build |
|
I've been working to overhaul the STP_STUB behavior, so I've fixed it there in section "disable STP at runtime". The fix could be backported to work with the old STP_STUB, but with the new API, we could use this opportunity to remove STP_STUB since it was already broken for years (instead of fixing it and annoying people when removing it later). |
|
We're trying to get a 2023.07 release out. The overhaul needs some discussion, so I don't want to hold up a release for it. I'd just like to get the code in a stable form, to tag a release. The stub flag behaviors have been this way for a while, so it's not a problem to leave it, except that I did add mention of the My thought was just to get On your overhaul, I have some thoughts, but maybe I should wait until I've looked at it more. But off the top of head, I wonder if a build with the system library should just not install any object file and use what's in the system. (I guess that depends on whether such a build wants to require the users to also have the library installed.) Also, my sense has been that an installation can change -- like, if it started with a yices stub, but then someone wanted to add yices, they could change what's in the |
In that case I'd say to postpone this fix until after the release. The feature is so obviously broken that everyone can tell not to use it (or patch it, in which case they are on their own). If this was a subtle bug somewhere, that'd be different.
Of course, documenting it without testing wasn't a great decision, but the feature is intended to exist, so the documentation isn't wrong per se.
Any my thought was to precisely not do that if we intend to deprecate it shortly afterwards. If it's absolutely necessary, then getting it to build isn't actually all that difficult (like the NixOS guys have been doing) - and then they know that it might not work with the next release, when the refactor came in.
If I build it explicitly with the stub, then I'd want STP to be disabled. So not sure why it needs to be
On Yices, I don't want to change any behavior, only the flag is supposed to be mirrored in the refactor. If that note comes from the misunderstanding in #599, then we are on the same side. Thoughts on overhaul/refactor
Yeah, that's an entirely different discussion, I've opened the draft PR #600 so we can discuss that there.
So I settled for a refactor - "overhaul" probably set the wrong expectations - of the Makefiles in order to get a quick and immediate improvement. This discussion should be continued in the draft PR though. |
Issue
When using the build option STP_STUB=1 during building in order to disable STP, BSC fails to build with error
Apparently,
bscis looking forlibstp_stub.so, eventhough it should search forlibstp.so.1, which does exist inbsc/inst/lib/SAT/.More information
Error occurs on the main branch (commit 42fb7b6). Omitting the build option builds just fine. Also tried to build with (the randomly chosen) commit a7f3b2c, but failed with the same error.
Command:
make STP_STUB=1 GHC="ghc -dynamic" GHCJOBS=4 GHCRTSFLAGS='+RTS -M5G -A128m -RTS' install-srcSystem information
OS: Arch Linux
Kernel: 6.4.9-arch1-1
GHC: 9.0.2-3
BSC: 42fb7b6 and a7f3b2c (via bluespec-git)
Full error log
The text was updated successfully, but these errors were encountered: