In short, I'm unable to install #pact-foundation/pact-node on my development computer and from what I gather it seems to be loosely related to being on macOS 10.14. When I say loosely, this does not affect my other non-development computer running the same stack.
Within nvm I've tried using Node 8.14.0, 8.15.0, 9.4.0, 10.14.2, 10.15.0 and 11.6.0, in addition to system Node, which is also 11.6.0. Each version results in the same error messages, regardless of whether I'm in my team's project directory or in an otherwise empty sandbox directory.
Until a few minutes ago I was running macOS 10.14.1 and am seeing the same problems on 10.14.2. There are no updates that haven't been installed.
The package installation output is as follows.
$ npm install #pact-foundation/pact-node
> dtrace-provider#0.8.7 install /Users/andrewgould/www/sandbox/node_modules/dtrace-provider
> node-gyp rebuild || node suppress-error.js
ACTION binding_gyp_ndtp_target_build_ndtp .
TOUCH Release/obj.target/ndtp.stamp
> spawn-sync#1.0.15 postinstall /Users/andrewgould/www/sandbox/node_modules/spawn-sync
> node postinstall
> caporal#0.10.0 postinstall /Users/andrewgould/www/sandbox/node_modules/caporal
> (test -f ./node_modules/husky/bin/install.js && node ./node_modules/husky/bin/install.js) || exit 0
> #pact-foundation/pact-node#6.20.0 postinstall /Users/andrewgould/www/sandbox/node_modules/#pact-foundation/pact-node
> node postinstall.js
dyld: lazy symbol binding failed: Symbol not found: _usdt_create_provider
Referenced from: /Users/andrewgould/www/sandbox/node_modules/dtrace-provider/src/build/Release/DTraceProviderBindings.node
Expected in: flat namespace
dyld: Symbol not found: _usdt_create_provider
Referenced from: /Users/andrewgould/www/sandbox/node_modules/dtrace-provider/src/build/Release/DTraceProviderBindings.node
Expected in: flat namespace
Abort trap: 6
Has anyone seen errors like these before? Is there a solution known?
It turns out this issue was caused by binutils, which I had installed via Homebrew. Uninstalling that fixed the problem.
From the GNU binutils website, the main packages included in it are ld, the GNU linker, and as, the GNU assembler. Both tools are included with macOS, however the Homebrew versions of these tools caused the conflicts shown in the above question.
Related
I tried running my program which uses Haskell QuickCheck via ghc MyProgramm.hs , but received the following error:
$ ghc Ex2.hs
[1 of 1] Compiling Ex2 ( Ex2.hs, Ex2.o )
Ex2.hs:21:1: error:
Could not find module ‘Test.QuickCheck’
There are files missing in the ‘QuickCheck-2.11.3’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
21 | import Test.QuickCheck (
| ^^^^^^^^^^^^^^^^^^^^^^^^...
I installed stack, ran stack update and stack install QuickCheck without issue but the error persisted. Then, I ran cabal install QuickCheck and got the following errors:
$ cabal install QuickCheck
Resolving dependencies...
Configuring QuickCheck-2.12.4...
Building QuickCheck-2.12.4...
Failed to install QuickCheck-2.12.4
Build log ( /home/username/.cabal/logs/ghc-8.4.3/QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK.log ):
cabal: Entering directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
Configuring QuickCheck-2.12.4...
Preprocessing library for QuickCheck-2.12.4..
Building library for QuickCheck-2.12.4..
[ 1 of 16] Compiling Test.QuickCheck.Exception ( Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )
[ 2 of 16] Compiling Test.QuickCheck.Random ( Test/QuickCheck/Random.hs, dist/build/Test/QuickCheck/Random.o )
Test/QuickCheck/Random.hs:10:1: error:
Could not find module ‘System.Random’
There are files missing in the ‘random-1.1’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
10 | import System.Random
| ^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:11:1: error:
Could not find module ‘System.Random.TF’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
11 | import System.Random.TF
| ^^^^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:12:1: error:
Could not find module ‘System.Random.TF.Gen’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
12 | import System.Random.TF.Gen(splitn)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cabal: Leaving directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
cabal: Error: some packages failed to install:
QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK failed during the building phase. The
exception was:
ExitFailure 1
However, I already have the arch packages haskell-random, haskell-tf-random and haskell-mwc-random installed. Does anybody know how to fix this?
Edit: I also ran cabal install random --reinstall.
Problem
On Archlinux as of 2022-09-17, pacman -S ghc cabal-install will install
system packages that provide only dynamic files (.so, .dyn_hi) in
installed packages inside /usr/lib/ghc-*; static files (.a, .hi) are (for
the most part) missing. However, the default cabal configuration enables static file
building. Unfortunately, upstream cabal-install doesn't track whether or not
static files are available inside installed packages. It just assumes they
are, and when they are gone, it fails with errors such as you have found:
[1 of 1] Compiling Main ( Main.hs, ../setup.dist/work/depender/dist/build/depender/depender-tmp/Main.o )
Main.hs:3:1: error:
Could not find module `Dynamic'
There are files missing in the `dynamic-1.0' package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
| import qualified Dynamic (number)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Workaround
A quick workaround just to get up and running quickly is to disable static file
building, which is by default enabled. (Note that trying to pass package-local
flags to disable static file with e.g. --enable-shared --enable-executable-dynamic --disable-library-vanilla (which is how most if
not all current Archlinux Haskell packages seem to build packages, e.g. with
https://github.com/archlinux/svntogit-community/blob/master/haskell-scientific/trunk/PKGBUILD)
building using cabal-install may be ignored due to another, related bug; but
~/.cabal/config is a safe bet.) You may do so by adding 3 lines to
~/.cabal/config in the appropriate location:
library-vanilla: False
shared: True
executable-dynamic: True
(Alternatively, consider using alternative tools like stack.)
More complete solution
For a more long-term solution, one option involves 2 pieces: 1) one or more
system packages that provide all types of build artifacts, static and dynamic,
for the base, foundational packages (from GHC and cabal-install), at least as an option besides dynamic-only packages (secondary Haskell packages are optional,
since cabal-install can rebuild these with needed build artifacts (static or
dynamic)), and 2) patching cabal-install (and ghc-pkg, which can handle .conf
files recording information about installed packages) to track whether static
files are available, and to be aware of these when resolving dependencies so
that cabal-install knows when to prefer rebuild a source package with needed
build artifact configuration over an already installed package that doesn't
provid required build artifacts.
There is a merge request (I submitted) that provides such a patchset, called
fix-dynamic-deps, at https://github.com/haskell/cabal/pull/8461. For users
running into exactly the problem that you described (myself included), I also
created an AUR package that provides both pieces based on GHC 9.4.2 with Cabal
3.9.0.0 that includes my patchset (there is a mirror at
https://github.com/bairyn/ghc-cabal-arts.) It provides ghc and
cabal-install but includes both of these pieces.
Further reading
Here are a few more resources I wrote on or are related to this bug:
https://wiki.archlinux.org/index.php?title=Haskell&diff=745459&oldid=738269#Troubleshooting
https://github.com/haskell/cabal/pull/8461
https://github.com/bairyn/ghc-cabal-arts
https://github.com/bairyn/cabal/tree/fix-dynamic-builds
Even though I have a main = do and couldn't get it working that way, I was able to run my QuickCheck test as follows:
To run a quickCheck, first load your program with:
$ ghci MyProg.hs
Then to run the quickCheck, find the test you want to run, then run it with:
$ quickCheck my_quick_check
(Haskell newbie here)
I'm trying to configure HaskForce plugin into IntelliJ IDEA, configured "ghc-mod" with "legacy-interactive" in "GHC Modi" Flags. The root problem seems to be related to cabal version, although when I try autocompleting on any Haskell symbol, I get this:
ghc-modi error
Unable to parse problems from ghc-modi: cabal-helper-wrapper.exe: ghc: readCreateProcess: does not exist (No such file or directory)
ghc-mod: readCreateProcess: C:\ACME\projects\htest\.cabal-sandbox\cabal-helper-0.5.3.0-553kah86RQN6BuDX6XLBiX\cabal-helper-wrapper.exe "C:\\ACME\\projects\\htest" "C:\\ACME\\projects\\htest\\dist" (exit 1): failed
When I run this last command (C:\ACME\projects\htest\.cabal-sandbox\cabal-helper-0.5.3.0-553kah86RQN6BuDX6XLBiX\cabal-helper-wrapper.exe "C:\\ACME\\projects\\htest" "C:\\ACME\\projects\\htest\\dist"), it tries to install cabal 1.18:
cabal-helper-wrapper.exe: Installing Cabal version 1.18.1.3 failed.
I already have cabal, of version 1.22 (installed via Haskell Platform v7.10.2-a, released recently in August).
Is there any way to work around this issue (i.e. still use ghc-mod / ghc-modi)?
Updated Haskforce plugin (0.3-beta24) seems to work correctly with following ghc-mod:
ghc-mod version 5.4.0.0 compiled by GHC 7.10.2
I am facing the following errors while trying to install the caret package in R.
g++: error: /tmp/Rtmp2Tos7n/R.INSTALL2e6e30153a74/nloptr/nlopt-2.4.2/lib/libnlopt_cxx.a:
No such file or directory make: *** [nloptr.so] Error 1
ERROR: compilation failed for package ‘nloptr’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/nloptr’
Warning in install.packages :
installation of package ‘nloptr’ had non-zero exit status
ERROR: dependency ‘nloptr’ is not available for package ‘lme4’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/lme4’
Warning in install.packages :
installation of package ‘lme4’ had non-zero exit status
ERROR: dependency ‘lme4’ is not available for package ‘pbkrtest’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/pbkrtest’
Warning in install.packages :
installation of package ‘pbkrtest’ had non-zero exit status
ERROR: dependency ‘lme4’ is not available for package ‘BradleyTerry2’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/BradleyTerry2’
Warning in install.packages :
installation of package ‘BradleyTerry2’ had non-zero exit status
ERROR: dependency ‘pbkrtest’ is not available for package ‘car’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/car’
Warning in install.packages :
installation of package ‘car’ had non-zero exit status
ERROR: dependencies ‘car’, ‘BradleyTerry2’ are not available for package ‘caret’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/caret’
Warning in install.packages :
installation of package ‘caret’ had non-zero exit status
The downloaded source packages are in
‘/tmp/RtmpG9dYqn/downloaded_packages’
I looked into this other question that had a similar problem
Dependency issue while installing caret package in R
The solution for this problem was to install each of the dependencies first, but they all had the same error message. For example:
>install.packages('nloptr')
g++: error: /tmp/RtmpgEn54A/R.INSTALL7015350f0d03/nloptr/nlopt-2.4.2/lib/libnlopt_cxx.a: No such file or directory
make: *** [nloptr.so] Error 1
ERROR: compilation failed for package ‘nloptr’
* removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/nloptr’
Warning in install.packages :
installation of package ‘nloptr’ had non-zero exit status
The downloaded source packages are in
‘/tmp/RtmpG9dYqn/downloaded_packages’
I also tried changing the repos ie. install.packages('caret', repos='http://cran.rstudio.com/') but it dint work either.
My session info is given below:
> sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: x86_64-suse-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.1.2
I recently encountered the problem with nlopt as well. It was easily solved by installing nlopt-devel and its associated dependencies from YaST (or your preferred package manager).
I was hoping to add a comment first. On Jan 28, 2015, there was an addition to the nloptr package in github that possibly broke the compilation. I used a workaround by installing from an older version with the command
install.packages("http://cran.r-project.org/src/contrib/Archive/nloptr/nloptr_1.0.0.tar.gz",
repos=NULL, type="source")
As mentioned in this R help forum:
http://r.789695.n4.nabble.com/can-t-install-rugarch-and-nloptr-packages-in-R-3-01-opensuse-linux-td4669649.html
add the line to the src/Makevars file
mv .libs lib; \
between
make install; \
ls | grep -v ^include$$ | grep -v ^lib$$ | xargs rm -rf; \
This will remove the compilation error and you would be able to install nloptr package. I have tested this for nloptr_1.0.0.tar.gz .
I solve this issue by installing first "car" from synaptic (use filter with "cran-car").
And then I install "caret" with rstudio but I guess it will work also for R.
Hope it helps,
Regards
I am deploying a node-js app to heroku that requires the npm package imagemagic-native.
I made the buildpack install libmagick++-dev and export the include path:
export INCLUDE_PATH="$BUILD_DIR/.apt/usr/include:$INCLUDE_PATH"
export CPATH="$INCLUDE_PATH"
export CPPPATH="$INCLUDE_PATH"
Upon installing the imagemagic-native package with npm install, node-gyp is invoked to compile it's binaries. However I get this error:
remote: > imagemagick-native#1.7.0 install /tmp/build_720834c3a32b65d69ae603d7c618e20f/node_modules/imagemagick-native
remote: > node-gyp rebuild
remote:
remote: make: Entering directory `/tmp/build_720834c3a32b65d69ae603d7c618e20f/node_modules/imagemagick-native/build'
remote: CXX(target) Release/obj.target/imagemagick/src/imagemagick.o
remote: In file included from ../src/imagemagick.cc:9:
remote: ../src/imagemagick.h:1:22: warning: Magick++.h: No such file or directory
This suggests that gcc doesn't see the header files for libmagick++, because $CCPATH is not available to it.
How can I make npm install add the path to the list of include_dirs that node-gyp uses?
More detail about my use case is here: Using Magick++ in a node.js application on heroku
Try:
setting the environment variable CXX=/path/to/g++ -Ipath/to/include
and then restarting the process. If you're using bash this is done by
export CXX="/path/to/g++ -Ipath/to/include"
/path/to/include being where the missing header Magick++.h is located
if that doesn't work you may manually have to set CXX to include the -I in the makefile at /tmp/build_720834c3a32b65d69ae603d7c618e20f/node_modules/imagemagick-native/build then cding into that directory and calling make.
I've spent some time trying to answer the same question. In the end, i've found the proper way to do this here. You need to set 'include_dirs' property in ~/.node-gyp/x.x.x/common.gypi.
This is how I've set the include dir on Mac OS to /opt/local/include/ (which is where all macports intalls go):
...
['OS=="mac"', {
'defines': ['_DARWIN_USE_64_BIT_INODE=1'],
'include_dirs': ['/opt/local/include'],
'xcode_settings': {
'ALWAYS_SEARCH_USER_PATHS': 'NO',
...
Though I'm not sure it's applicable for heroku environment.
You can also use the "include_dirs" option in your project binding.gyp file. Read more about available options on the format description page.
You can now do OTHER_CFLAGS='-I/usr/local/include' supposedly. See https://github.com/nickdesaulniers/node-nanomsg/pull/144
I'm running a clean install of OSX 10.9 and running into issues running any node.js app with node-opencv dependencies. I've already installed opencv, python, node.js, and npm via Homebrew.
In this case, I'm trying to run: node face_detection.js from the examples folder, and I'm getting this error:
dyld: lazy symbol binding failed: Symbol not found: __ZN2cv6imreadERKSsi
Referenced from: /Users/Jim/GitHub/node-opencv/build/Release/opencv.node
Expected in: dynamic lookup
dyld: Symbol not found: __ZN2cv6imreadERKSsi
Referenced from: /Users/Jim/GitHub/node-opencv/build/Release/opencv.node
Expected in: dynamic lookup
Trace/BPT trap: 5
Whatever the cause was, I had the same problem and solved it by upgrading to the latest homebrew distribution of opencv.