What goes into determining the GHC version when using stack?
I thought this would be the resolver but...
I have the following stack file:
resolver: nightly-2018-07-10
packages:
- .
This is what is on Stackage:
Stackage Nightly 2018-07-10 (ghc-8.4.3)
Published on 2018-07-10
View changes
stack resolver: nightly-2018-07-10
Then I build:
$ stack clean
$ stack build
Building all executables for `PyrethrumPre' once. After a successful build
of all of them, only specified executables will be rebuilt.
PyrethrumPre-0.1.0.0: configure (exe)
Configuring PyrethrumPre-0.1.0.0...
PyrethrumPre-0.1.0.0: build (exe)
Preprocessing executable 'PyrethrumPre' for PyrethrumPre-0.1.0.0..
Building executable 'PyrethrumPre' for PyrethrumPre-0.1.0.0..
[1 of 2] Compiling MTLPlusLens ( src\MTLPlusLens.hs, .stack-work\dist \7d103d30\build\PyrethrumPre\PyrethrumPre-tmp\MTLPlusLens.o )
[2 of 2] Compiling Main ( src\Main.hs, .stack-work\dist\7d103d30\build\PyrethrumPre\PyrethrumPre-tmp\Main.o )
Linking .stack-work\dist\7d103d30\build\PyrethrumPre\PyrethrumPre.exe ...
PyrethrumPre-0.1.0.0: copy/register
Installing executable PyrethrumPre in C:\PyrethrumPre\.stack-work\install\cd327184\bin
At this point I am expecting GHC to be at 8.4.3 as per the resolver:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
Why is the GHC version not as expected?
Thanks
Stack installs the GHC version it needs for your project in a "private" location under ~/.stack, which will not be ghc on your regular $PATH. The ghc version you're seeing is the one installed system-wide (likely by your system's package manager), which Stack ignores by default. To see the version that Stack will actually use to build your project, use stack exec -- ghc --version. stack exec creates a shell context that includes the right version of ghc on the $PATH, among other changes.
Related
If want to run dotnet-trace on Linux, against an application that ships with its own .NET Core runtime. When I run it, however, I get:
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/user/.net/dotnet-trace/RMBGJOBRwpkX5Kvpq_FShF5s1UmJMO8=/].
If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].
I located the libhostfxr.so library at /home/user/app/libhostfxr.so, then executed DOTNET_ROOT=/home/user/app/ dotnet-trace, but got the same error.
How do I go from the path of this library to the correct setting for DOTNET_ROOT?
According to strace, it is looking for the file /home/user/app/host/fxr which does not exist.
I ended up installing the .NET version that matched the application I was trying to debug using the install script. (I found this by using strings libhostfxr.so; perhaps there's a better way.)
A little confusingly, the runtime version 3.1.28 is not the same as the corresponding SDK version 3.1.422, which I installed with:
$ wget -O - https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --version 3.1.422
It can also be downloaded from versionsof.net which is not an official site, but it links to the files hosted by Microsoft.
This process installed /home/user/.dotnet/host/fxr/3.1.28/libhostfxr.so and I could then run DOTNET_ROOT=/home/user/.dotnet/ dotnet-trace.
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I have Linux Mint 19, and i really want to install SuperCollider. I cant do it by apt-get, because there is old version which do not support SuperDirt. I need to build it from source. I use this guide:
https://github.com/supercollider/supercollider/wiki/Installing-SuperCollider-from-source-on-Ubuntu
Problem is with cmake:
cmake -qt=qt5.11 -DSC_EC=ON -DSC_EL=OFF -DSC_WII=OFF -DSC_IDE=ON ..
-- SuperCollider Version: 3.10.0-beta2
-- Building from branch develop, commit hash is f543f53
-- Build type defaulting to "RelWithDebInfo"
-- Compiling with Qt GUI
-- building boost libraries manually
-- using bundled libyaml-cpp
-- HIDAPI components:
-- linux hidraw
-- libudev stable: 1
-- Found UDev: /usr/lib/x86_64-linux-gnu/libudev.so
-- include: /usr/include
-- hidapi_parser
-- Building with HID support
-- Using fftw3f
-- Found jack: /usr/lib/x86_64-linux-gnu/libjack.so
-- Audio API: jack
-- Found GNU Readline version 6.3: /usr/lib/x86_64-linux-gnu/libreadline.so
CMake Error at QtCollider/CMakeLists.txt:3 (find_package):
Could not find a configuration file for package "Qt5" that is compatible
with requested version "5.7".
The following configuration files were considered but not accepted:
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake, version: 5.5.1
Call Stack (most recent call first):
lang/CMakeLists.txt:155 (include)
-- Configuring incomplete, errors occurred!
See also "/home/nedlo/programming/supcol/bsource/supercollider/build/CMakeFiles/CMakeOutput.log".
So i need at least qt5.7, but i have qt5.5.1 I dont know how to update qt. I installed Qt Creator 5.11, but how do i "show" cmake that i should use qt5.11, if it automatically checks path to /usr/lib/.../qt5 which has qt5.5.1? What am i supposed to do?
Set CMAKE_PREFIX_PATH to the directory in your Qt installation that contains bin, lib, include, etc. It typically looks something like this:
cmake -DCMAKE_PREFIX_PATH=/opt/Qt/5.11.2/gcc_64 ...
I'm trying to set up autobuild appveyor on my Qt project.
My app is using qt5.10.1, with qml and openSSL features.
I'm lost... I didn't know from where to start :/
# 1:
I found some examples of .apveyor.yml config files, but they are all using mingw32 compilator which do not allow me to use qml webview module (why)... I didn't find what I have to write in my appveyor config file to compile my app with msv2017 where is the compilator ?
Actually, my appveyor.yml looks like that (I try to do as QtCreator is doing on my local computer but it's not working)
image: Visual Studio 2017
branches:
only:
- master
install:
- set QTDIR=C:\Qt\5.10.1\msvc2017_64
- set PATH=%QTDIR%\bin;C:\Qt\Tools\mingw530_32\bin;%PATH%;
build_script:
- qmake app/QRegovar.pro -spec win32-msvc
- qmake_all
- C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Release
deploy:
- provider: GitHub
artifact: C:/projects/qregovar
draft: true
prerelease: false
on:
branch: master
appveyor_repo_tag: true
And it's failling with the following error:
Build started
git clone -q --branch=master https://github.com/REGOVAR/QRegovar.git C:\projects\qregovar
git checkout -qf 7357eb2adab349c4de9e0b346dc99027964ea5a5
Running Install scripts
set QTDIR=C:\Qt\5.10.1\msvc2017_64
set PATH=%QTDIR%\bin;C:\Qt\Tools\mingw530_32\bin;%PATH%;
qmake app/QRegovar.pro -spec win32-msvc
Project ERROR: Cannot run compiler 'cl'. Output:
===================
===================
Maybe you forgot to setup the environment?
Command exited with code 3
# 2:
I'm also wondering if appveyor is using qt static build ? As I would like to create "ready to use" package for the user ?
I'm using CMake, but I guess the trick is to setup 'cl' compiler into PATH, so qmake is able to find it.
In sample appveyor scripts the main build script is '.\qtmodules-travis\ci\win\build.bat'. This script will check/use AppVeyor matrix-defined variable for platform (line 7+) and then the script define VC_DIR etc.
And on the end is invoking script referred by you 'build-msvc.bat' where is invoked:
call %VC_DIR% %VC_VARSALL% || exit /B 1
QtCreator will do the setup for you (you are using Kits...)
When you are building in clean command line, you should do 'vcvarsXXX.bat call yourself before 'qmake' call.
In my opinion AppVeyor doesn't trigger this call for you, because developer may wish different build env. setup (e.g. x86, x64, arm etc.). It's your choice. Actually this is the hint as well when you start 'Qt command line' on your PC from start menu (it call 'C:\Qt\5.11.0\msvc2017_64\bit\qtenv2.bat' shell setup script)
From my previous question, I know that JavaFX is not supported in RedHat 5.8 meaning, even when I have Java 8 (jdk1.8.0_05) installed on my Linux, a JAR file created in win7 can't be executed via java -jar helloworld.jar. Does that mean there is NO way to run JavaFX jars on this machine?
The problem with running JavaFX applications on RHEL5 is the version of glib that comes with that OS is not new enough. The trick, then, is to provide a newer version of that library and all of the other libraries that depend on it to the JRE. The next hurdle is that RHEL5 shared library loader won't load those libraries. You have to use a compatible loader. But the JVM has the path to the loader hard-coded in the executable! So you need a separate JVM with a custom loader path patched in. Roughly, the steps to get this working are...
Unpack the following packages from RHEL6:
glib2
libffi
glibc
glibc-common
zlib
gtk2
pango
cairo
pixman
Put all of the shared libraries from those packages in a directory on your RHEL5 system. Let's call it /YOUR-ALIEN-RHEL6-LIBS-PATH.
Unpack another copy of a JRE to, say, /YOUR-ALIEN-JVM-PATH.
Use patchelf to point the JVM executable to the new loader.
./usr/bin/patchelf --set-interpreter /YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64/ld-linux-x86-64.so.2 /YOUR-ALIEN-JVM-PATH/jre1.8.0_25/bin/java
Run the application after setting LD_LIBRARY_PATH=/YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64:/YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64/jli
Although it is not pretty, I have successfully run JavaFX applications on RHEL5 using this method. Having said that, I highly recommend just upgrading your OS if it is even remotely feasible.
Note this builds upon the existing answer from James with more concrete detail
Obtain RPMs from a RedHat 6.x, e.g. http://vault.centos.org/6.2/os/i386/Packages. Copy into directory rpms/
cairo-1.8.8-3.1.el6.i686.rpm
glib2-2.22.5-6.el6.i686.rpm
glibc-2.12-1.47.el6.i686.rpm
glibc-common-2.12-1.47.el6.i686.rpm
gtk2-2.18.9-6.el6.centos.i686.rpm
libffi-3.0.5-3.2.el6.i686.rpm
libXcomposite-0.4.1-2.el6.i686.rpm <== not mentioned in other answer
pango-1.28.1-3.el6_0.centos.5.i686.rpm
pixman-0.18.4-1.el6_0.1.i686.rpm
zlib-1.2.3-27.el6.i686.rpm
libXdamage-1.1.2-1.el6.i686.rpm <== not mentioned in other answer
Extract all the contents from the RPMs into separate directory. Use rpm2cpio and xzcat. xzcat can be installed from these RPMs if necessary [xz, xz-libs, xz-lzma-compat]
mkdir redhat-6u2-libs
cd redhat-6u2-libs/
ls -1 rpms/* | xargs -i{} bash -c "rpm2cpio {} | xzcat | cpio -idmv"
Obtain copy of patchelf. I built from source as couldn't find a Redhat 5 RPM. Only requires dependent RPMs [gcc, gcc-c++, glibc-devel, kernel-headers, libstdc++-devel]
wget https://nixos.org/releases/patchelf/patchelf-0.9/patchelf-0.9.tar.bz2
tar xjf patchelf-0.9.tar.bz2
cd patchelf-0.9
./configure --prefix /tmp/patchelf
make install
Use patchelf to set location of redhat 6u2 loader (aka interpreter)
/tmp/patchelf/bin/patchelf --set-interpreter ~/redhat-6u2-libs/lib/ld-linux.so.2 jdk1.8.0_40/bin/java
Set LD_LIBRARY_PATH, this needs to have both /usr/lib and /lib, otherwise you get a segfault.
export LD_LIBRARY_PATH=/home/user/redhat-6u2-libs/usr/lib:/home/user/redhat-6u2-libs/lib
(Note that any other applications run after LD_LIBRARY_PATH is set other than java which has had its interpreter location corrected will segfault.)
Now run java app...
./jdk1.8.0_40/bin/java -cp etc...
Happy days