Creating a fresh haskell-stack project fails to find the project-exec executable, despite searching the appropriate path. I'm not sure why. In particular,
stack build creates the project-exec inside $PROJECT_DIR/.stack-work/install/x86_64-linux-ncurses6/.../bin/project-exe
However, stack exec project-exec fails with:
Executable named rse8-exec not found on path: ["$PROJECT_DIR/.stack-work/install/x86_64-linux-ncurses6/lts-7.14/8.0.1/bin", ]
(to clarify, $PROJECT_DIR references and ... are (hopefully) obvious placeholders for paths. the actual error contains the full path)
Apologies for the lack of attention showed here. This question should probably just be deleted.
Stack creates a file named <project>-exe not <project>-exec.
Stack replaces dashes - with underscores _. Try stack exec project_exec see if it works.
This should have been a comment actually, but I don't have enough reputation to write a comment, while I have enough to post an answer!
Related
I am encountering the following error every time I try to use stack except for stack --version:
PS D:\Currentdir\version2\code> stack update
InvalidRelDir "D:\\Currentdir\\code\\.stack-work"
PS D:\Currentdir\version2\code> stack clean
InvalidRelDir "D:\\Currentdir\\version2\\code\\.stack-work"
PS D:\Currentdir\version2\code> stack test
InvalidRelDir "D:\\Currentdir\\version2\\code\\.stack-work"
PS D:\Currentdir\version2\code>
I think I deleted the .stack/work subfolder in one of my projects (from within Windows 10 file explorer), and this might be causing the problems since the commands might look for that specific folder, and since stack test did work before.
There are however .stack-work subfolders in other projects such as in the one indicated above. So I am not entirely sure.
I just discovered that my stack has somehow been set to look for a .stack-work folder that is within a specific folder, as seen below where I have tried to navigate first to other folders and after that to that particular folder in windows powershell:
PS D:\Redo_haskell_folder\code> stack path
InvalidRelDir "D:\\HaskellAppFolder\\version2\\code\\.stack-work"
PS D:\Redo_haskell_folder\code> stack --stack-root STACK-ROOT
option --stack-root: InvalidAbsDir "STACK-ROOT"
PS C:\sr> stack path
InvalidRelDir "D:\\HaskellAppFolder\\version2\\code\\.stack-work"
PS D:\HaskellAppFolder\version2\code> stack path
InvalidRelDir "D:\\HaskellAppFolder\\version2\\code\\.stack-work"
I have tried the following steps to troubleshoot the "InvalidRelDir" error when running stack update or stack clean, I:
Made sure that I am using the latest version of stack by running stack --version and tried updating stack with stack upgrade.
Checked the contents of my stack.yaml file to make sure that it is correct and specifies the correct dependencies and packages for my project. It is just the one initilialized with the stack init in my current folder.
Ran stack init in my project directory to create a new stack.yaml file and configure my project for use with stack. This gives back the same error message.
Tried to delete the .stack-work directory using Remove-Item -Recurse -Force .stack-work (I am using windows 10 and powershell terminal) and ran stack update or stack clean again to see if the issue is resolved. The remove-command caused same InvalidRelDir error.
Tried to change the permission of the folders I am working in, within the windows 10 explorer, by un-checking the 'Read only'-permission. The problem persists.
I also tried suing stack-root I get the following in the powershell prompt
code> stack --stack-root STACK-ROOT
option --stack-root: InvalidAbsDir "STACK-ROOT"
Despite these efforts, I am still encountering the "InvalidRelDir" error. I haven't been able to find any posts that mentions the same problem they encountered, any good ideas?
EDIT
Since I have gotten very few responses, perhaps I could help open op the trouble shooting by asking about the default location for stack root.
Furthermore is there a way to un-install only stack rather than all of the ghc and cabal packages that comes with it?
EDIT EDIT
Or if none of the above works, would there be a way to uninstall the above and re-install in such a way that I would have taken into consideration the multiple .stack-work folders that might have been created from my trouple shooting proces.
EDIT x3
I finally found the InvalidRelDir in the documentation - not for stack as such but at hackage . As far as I can see this is a haskell documentation, and somehow the stack build is using the function parselRelDir described as:
parseRelDir :: MonadThrow m => FilePath -> m (Path Rel Dir)
Convert a relative FilePath to a normalized relative dir Path.
Throws: InvalidRelDir when the supplied path:
is not a relative path
is ""
contains a .. path component representing the parent directory
is not a valid path (See isValid)
I suspect that I get the error because the stack library is using this library as well. If any of you find this to be an incorrect tenet or have any suggestions about how to proceed from here without uninstalling all of stack it will be appreciated.
As seen in the post above, I have now narrowed the problem down even further, to some kind of 'pointer' to an 'old' or wrong directory. And I think my question therefore is: "Is there a way to 'reset' the .stack-workfolder that stack is looking for with the parseRelDir function mentioned before?"
I have now uninstalled stack according to: this and have in that process also removed C:\sr and the %AppData%\Roaming\stack.
I have then installed it with this windows package as recommended from official documentary.
I do however still get the same error now that I have installed it again.
EDIT x4
I have now made progress! I went to "Edit System Variables" and edited "STACK ROOT" to C:\sr and C:\sr\.stack-work but got the following error with the output of those paths respectively
PS D:\Redo_haskell_folder\code> stack path InvalidRelDir "C:\\sr"
So now that I know why the pointer kept being the same despite re-installing stack, I now have to find out the following: What is the correct path for "STACK ROOT"
PS: after reinstalling the C:\sr is empty except for a config.yaml file
I got in touch with the stack-support and used the following 'reset of the STACK_ROOT' to solve the issue.
STACK_ROOT is an environment variable that specifies the location of
the Stack Root directory. See
https://docs.haskellstack.org/en/stable/environment_variables/#stack_root.
See also:
https://docs.haskellstack.org/en/stable/global_flags/#the-stack-root-option.
On Windows, the default value is C:\sr (because some Windows operating
systems have problems with long paths). Stack will populate the Stack
root the first time it needs the contents of the Stack root.
❯ echo $Env:STACK_WORK
> $Env:STACK_WORK="C:\temp"
> echo $Env:STACK_WORK
C:\temp
> stack path --dist-dir
InvalidRelDir "C:\\temp"
> $Env:STACK_WORK=""
> stack path --dist-dir
.stack-work\dist\8a54c84f
i want to install cpanm WWW::Curl::Form on my Synology NAS. But that fails. Here is the output cpanm WWW::Curl::Form WWW::Curl::Easy File::Find::Rule String::CRC32 URI::Escape
--> Working on WWW::Curl::Form
Fetching http://www.cpan.org/authors/id/S/SZ/SZBALINT/WWW-Curl-4.17.tar.gz ... OK
Configuring WWW-Curl-4.17 ... OK
Building and testing WWW-Curl-4.17 ... FAIL
! Installing WWW::Curl::Form failed. See /var/services/homes/fox/.cpanm/work/1541095458.25803/build.log
the log file gives me:
make: i686-linux-gnu-ld: Command not found
But i dont know how to fix it on my Synology NAS (DSM 6.2 and appollolake architecture DS918+)
After reviewing your additional comments, I believe I have potential solution. It looks like you are trying to install some Perl modules via the default Perl shell, cpan. As part of the installation process, the make utility is being executed. This utility is heavily used for compiling and building source from C and C++ source code, along with other languages.
The make utility is trying to call some executable i686-linux-gnu-ld which is a linker, see ld. A linker is a utility used in C programming for linking (combining) multiple compiled object files into a single executable binary. make is calling this utility as some sort of build process. Instead of calling i686-linux-gnu-ld it should probably just be calling ld. The only thing I am not sure about is why it is using the full name of the utility instead of ld.
I can think of two solutions. The first would be to update the make file to use the correct name for the linker. I'm not sure how you would do this when it is being installed via cpan since it is downloading a package and executing the make file before you have a chance to modify it. The other option is to create a symbolic link from the incorrect name and path of ld that the make file is using to the correct path /opt/bin/ld. This will result in ld being called when i686-linux-gnu-ld is called. Also, I forgot to mention it earlier but the which command will tell you where an executable / command is located on your shell's path.
The Stack Overflow post, How to symlink a file in Liunx?, gives a good explanation of how to create a symlink. You need to create a symlink to point to the correct name and path of the linker. To do so run the following command:
ln -s /opt/bin/ld /usr/bin/i686-linux-gnu-ld
Depending on the permissions of these directories you may need to run this command under a account with elevated permissions or via sudo. I apologize for this post being rather long and verbose. I just wanted to explain my solution in detail. I hope this helps. Please let me know if this doesn't resolve the problem.
edit: fixed typo in the command.
I'm having this strange issue : I'm trying to add a local package to my stack file and I get the following error. when I try to build it (stack build) it kind of work but fails suggesting me to use stack solver but when I run stack solver I got the following error
Using configuration file: stack.yaml
InvalidRelFile "/home/max/devel/sql-fragment/sql-fragment.cabal"
My stack file looks like
flags: {}
packages:
- '.'
- ../sql-fragment
extra-deps:
...
I'm on Ubuntu 15.02 trying to use GHC-7.8.4 and stack 1.0.4
The two packages, sql-fragment and sql-fragment-mysql-simple can be found on github.
It's probably a bug in stack. I managed to find a workaround by moving sql-fragment directory into sql-fragment-mysql-simple, change ../sql-fragment to sql-fragment in the stack file launch the solver -stack solver --update-config and it works. What is strange is, I add to properly move the directory to make it work (just creating a symbolic link woudn't work) and once the solver has done its job. I moved sql-fragment where it was, revert the path to ../sql-fragment and stack build works perfectly ;-).
Fixed with this commit. https://github.com/commercialhaskell/stack/commit/42a61fb278aeb99ad61bb088da9a87b2313ac325
The issue tracker is a better place for this.
When running stack build --no-terminal --install-ghc, I run into Error parsing targets: No local directories found as children.
I can understand what it means, but why does it happen? I haven't read anywhere in the Stack manual about having to create extra directories ..
Thanks in advance
What's your stack version? Can you still reproduce this with the latest?
This means that it is parsing an argument as if it is a TARGET, but isn't finding the dir. I think in old versions of stack, unrecognized flags would get parsed this way. So, if you're using a command intended for newer stack, this error can happen.
I have a package with bunch of *.c and *.cpp files, listed inside c-sources field of *.cabal file. I need to include it inside a project with IHaskell and some other packages. Everything works fine, and builds without a problem. stack exec ghci works fine and I can import modules and execute any code. stack ghci though throws some weird errors, like this:
In file included from <command-line>:10:0:
/...blabla.../.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen/cabal_macros.h:157:0:
note: this is the location of the previous definition
#define CURRENT_PACKAGE_KEY "blabla"
^
And stack ghci inside my package complains about symbols exported from its C code. Another weird thing is that symbols depend on the order of exposed-modules in the configuration, so the error goes away if I put my *.hs module on top of others, but if I have two *.hs files importing from the same *.c file, it won't work! stack exec jupyter -- console --kernel haskell starts, but immediately throws unknown symbol error if I try to run some code from my package, always the same though.
I have a docker image based on fpco/stack-build, which just installs jupyter and other necessary stuff. I use lts-3.0 snapshot, if it's somehow relevant.
What is going on?
There have been a lot of improvements made recently to stack ghci, which is still mostly a work in progress. I'd recommend testing out stack master, and if the problem still exists opening a Github issue.