I've cloned go source code using git clone https://go.googlesource.com/go into my ~/godev/ directory (outside of GOPATH as the docs advise).
My $GOPATH is ~/gocode
I installed go 1.8.1 using the official osx installer.
If I cd into ~/godev/go/src/net/http and run go test, I get these errors:
h2_bundle.go:46:2: cannot find package "golang_org/x/net/http2/hpack" in any of:
/usr/local/go/src/golang_org/x/net/http2/hpack (from $GOROOT)
~/gocode/src/golang_org/x/net/http2/hpack (from $GOPATH)
h2_bundle.go:47:2: cannot find package "golang_org/x/net/idna" in any of:
/usr/local/go/src/golang_org/x/net/idna (from $GOROOT)
~/gocode/src/golang_org/x/net/idna (from $GOPATH)
h2_bundle.go:48:2: cannot find package "golang_org/x/net/lex/httplex" in any of:
/usr/local/go/src/golang_org/x/net/lex/httplex (from $GOROOT)
~/gocode/src/golang_org/x/net/lex/httplex (from $GOPATH)
transport.go:32:2: cannot find package "golang_org/x/net/proxy" in any of:
/usr/local/go/src/golang_org/x/net/proxy (from $GOROOT)
~/gocode/src/golang_org/x/net/proxy (from $GOPATH)
transfer.go:14:2: use of internal package not allowed
After I follow the directions here by doing cd $GOPATH/src
followed by cp -R /usr/local/go/src/vendor/golang_org ., I still get these errors:
h2_bundle.go:47:2: code in directory ~/gocode/src/golang_org/x/net/idna expects import "golang.org/x/net/idna"
transport.go:32:2: cannot find package "golang_org/x/net/proxy" in any of:
/usr/local/go/src/golang_org/x/net/proxy (from $GOROOT)
~/gocode/src/golang_org/x/net/proxy (from $GOPATH)
transfer.go:14:2: use of internal package not allowed
It is true that there is no proxy package under ~/gocode/src/golang_org/x/net, but I still don't know how to fix that and the other 2 errors.
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="~/gocode"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/71/k_tftg2d1qd7gf5ww0n_wl_r0000gn/T/go-build541211050=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
If I run the all.bash script, it will run all unit tests, but that is time consuming. Is there a way to run just net/http tests without getting these errors?
The problem here is that you're running go test, where the go command is your 1.8.1 installation. For the tests to work properly you should run with the Go toolchain built from your development directory.
Make sure you've built the Go toolchain, cd ~/godev/src; ./make.bash (./all.bash will work too, but then you'll have to wait for tests to run instead of just building the toolchain).
Run the tests with the newly compiled toolchain, cd ~/godev/src/net/http; ~/godev/bin/go test.
I suggest adding an alias to your profile, such as alias godev=~/godev/bin/go, then you can run godev test.
Also make sure that you are not setting the GOROOT environment variable as it will cause the go command to use the specified path as the GOROOT regardless of which toolchain you're running with, which is not what you want.
Update
As requested in the comments, here's as brief an explaination as I can come up with:
The errors that mention "cannot find package" are looking for some packages that are vendored in ~/godev/src/vendor/golang_net/.... However, the vendoring support added in 1.5/1.6 only works when the package is inside the GOPATH or GOROOT. Your godev installation is not (and should not be) inside GOPATH and GOROOT is pointing to your 1.8.1 install.
transfer.go:14:2: use of internal package not allowed is because transfer.go imports net/http/internal. Since this is not a relative path it'll be found in $GOROOT/src/net/http/internal, instead of ~/godev/src/net/http/internal and internal packages cannot be imported if the importing package does not share a common root with the internal directory.
It boils down to GOROOT pointing to your 1.8.1 installation. You might wonder if you could just set GOROOT to point at your godev directory, but this is not going to work correctly either. I'm not as certain of the mechanics here, but I think the problems come down to mismatches between what the 1.8.1 compiler expects are what is in ~/godev/src/runtime.
When the toolchain is compiled the location of GOROOT is compiled in, so when ~/godev/bin/go is run, it uses ~/godev as it's GOROOT.
Related
I'm trying to install JAGS through homebrew so I can use it in R. I am getting the following warning every time I install:
Warning: jags dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.
Then, when I try to install rjags in R, I get the following error:
configure: error: "cannot link to JAGS library in /usr/local/Cellar/jags/4.3.0_2/lib."
ERROR: configuration failed for package ‘rjags’
* removing ‘/usr/local/lib/R/4.0/site-library/rjags’
I also tried following the installation guide in the JAGS 4.3.0 readme. This yielded the same error once I moved to R.
Googling leads me to the following links, none of which seem closely related enough to help me:
https://github.com/Homebrew/brew/issues/4904
https://github.com/Homebrew/homebrew-core/issues/32112
Link different C++ standard libraries on Mac OS X
Here also is the entire result of my brew doctor
(base) aridf#Aris-MacBook-Pro ~ % brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/Users/aridf/opt/anaconda3/bin/icu-config
/Users/aridf/opt/anaconda3/bin/krb5-config
/Users/aridf/opt/anaconda3/bin/freetype-config
/Users/aridf/opt/anaconda3/bin/xslt-config
/Users/aridf/opt/anaconda3/bin/libpng16-config
/Users/aridf/opt/anaconda3/bin/libpng-config
/Users/aridf/opt/anaconda3/bin/xml2-config
/Users/aridf/opt/anaconda3/bin/python3-config
/Users/aridf/opt/anaconda3/bin/curl-config
/Users/aridf/opt/anaconda3/bin/ncursesw6-config
/Users/aridf/opt/anaconda3/bin/pcre-config
/Users/aridf/opt/anaconda3/bin/python3.8-config
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libtcl8.6.dylib
/usr/local/lib/libtk8.6.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/mysqlStubs.h
/usr/local/include/odbcStubs.h
/usr/local/include/pqStubs.h
/usr/local/include/tcl.h
/usr/local/include/tclDecls.h
/usr/local/include/tclOO.h
/usr/local/include/tclOODecls.h
/usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
Thanks!
The solution, per https://gist.github.com/casallas/8411082, was to change ~/.R/Makedir to the following:
CC=clang
CXX=clang++
Then reinstall the package in R
I want to be able to import or using a package that I'm writing in a directory ~/projects/ExamplePkg from my main Julia REPL / from another project or environment.
By ]foo I mean "use the foo command at the Julia Pkg REPL". Type ] at the Julia REPL to enter the Pkg REPL. Use ]help <command name> for more info or check the link below.
Ensure that your package has a Project.toml that gives it a UUID and names it (generate one with ]generate from the Julia REPL or with the PkgTemplates package) and that it is in a git repo with at least one commit including all the relevant files.
Then choose how you would like to use the package.
You probably want to run ]dev ~/projects/ExamplePkg:
If dev is used on a local path, that path to that package is recorded and used when loading that package. The path will be recorded relative to the project file, unless it is given as an absolute path.
If you use dev and you change the dependencies in the dev'd package, then you should probably run ]resolve in all environments that depend on the package.
Or you can run ]add ~/projects/ExamplePkg:
Instead of giving a URL of a git repo to add we could instead have given a local path to a git repo. This works similarly to adding a URL. The local repository will be tracked (at some branch) and updates from that local repo are pulled when packages are updated. Note that changes to files in the local package repository will not immediately be reflected when loading that package. The changes would have to be committed and the packages updated in order to pull in the changes.
In Julia versions <1.4: If you accidentally ]add a package before the git repo is set up correctly then you might get ERROR: GitError(Code:EUNBORNBRANCH, Class:Reference, reference 'refs/heads/master' not found). Unfortunately, Julia will probably have cached the bad repo, and you will need to remove that from ~/.julia/clones/<gibberish>/. You can find the dir to remove with grep: $ grep ExamplePkg ~/.julia/clones/*/config.
Documentation: https://julialang.github.io/Pkg.jl/v1/managing-packages/
you can try
path_to_package = "~/projects/ExamplePkg"
push!(LOAD_PATH,path_to_package)
# then use it, ExamplePkg is the package's name
using ExamplePkg
But you have to run codes above whenever you restart Julia.
reference is Workflow tips-Julia Documentation
I am working on a Symfony 2.7 project. I ran composer update --dry-run to check which packages could need an update. Composer notified me about a deprecated package:
Package symfony/icu is abandoned, you should avoid using it. Use
symfony/intl instead.
I simply removed the dependency from the composer.json file and ran composer update --dry-run again. The message did not show up again, symfony/icu was uninstalled and symfony/intl was not installed.
Fine, this means that non of the other requirements depends on symfony/icu or symfony/intl. But can I be sure, that non of my own code requires any of these packages?
I created the project white a while ago and I do not remember why I added symfony/icu. I is possible, that the code that once required this packages has been removed, but I am not sure.
I used grep to search for any import of symfony/icu and found nothing. However that does not guarantee, that the package is not uses somewhere within my code, does it?
Is there any way to check if there are any dependencies within the complete Symfony project that require a specific package?
Check for every package? :(
I think you can do this only with automated testing.
There are no tools (I'm aware of) to detect whether some package is required to complete missing classes. There are also optional dependencies (package works without them, but with them will add some new features), so you will find missing classes but not required to run application.
How to check one package? :)
You heading right direction with grep. Yet rather look for namespace instead of package name. Package name is not always 1:1 to package namespace.
I would look for:
repo on Github: https://github.com/symfony/icu
open some file: https://github.com/symfony/icu/blob/1.2.x/IcuRegionBundle.php
find namespace
namespace Symfony\Component\Icu;
then search for "Symfony\Component\Icu" in code in PhpStorm or grep
I think the cleanest way is to start with composer and tell it dump all packages that caused your package to install:
For example, I'm trying to figure out why monolog/monolog is installed:
$ composer depends monolog/monolog
symfony/monolog-bundle 2.11.1 requires monolog/monolog (~1.18)
So monolog/monolog was installed because of symfony/monolog-bundle.
As you said you might have unintentionally use a package that's a dependency of another package so you didn't add it to your dependencies.
I'd use grep just as you did to search my source code. Just note that it's better to search for an actual class name, not the package name. Searching for package name would give you composer.json files but that's easier to analyze with composer depends than grep:
$ grep --include=\*.php -rnw './vendor' -e 'use Monolog'
./vendor/monolog/monolog/src/Monolog/ErrorHandler.php:16:use Monolog\Handler\AbstractHandler;
./vendor/monolog/monolog/src/Monolog/Formatter/ChromePHPFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/FluentdFormatter.php:45: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s FluentdUnixFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/GelfMessageFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/HtmlFormatter.php:13:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/NormalizerFormatter.php:34: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s NormalizerFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/WildfireFormatter.php:14:use Monolog\Logger;
This command searches all *.php files and dups also line numbers containing Monolog.
Unfortunately, the these two methods just analyze your code post-mortem. Really the best way to avoid dealing with this is to write unit tests. Then clone your fresh repository, install dependencies with composer install and run tests. This should guarantee that your code is run in isolation from any other unwanted dependencies.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)
I'm building an R package and need to build a jni library for OSX (called myPackage.jnilib) as part of my build process and then have R's automatic installation mechanisms put it inside the libs directory of my package.
The problem is that R's default is to try and build an object called myPackage.so. I'd like to be able to customize this but can't see how.
I can get part of the way by subverting R's mechanisms using a phony "all" target in Makevars (described here) and then copying the file to the inst directory of my package. This is OK for my own local uses but generates headaches when trying to build universal binaries and isn't very portable. I'm currently preparing the package for CRAN so this method isn't likely to work.
I can see two potential solutions but haven't got either to work yet
Copy my library manually to the libs directory of my package during installation. Since this directory is created on the fly, how would I find out what it is from within Makevars or a configure script
The best solution: Tell R CMD SHLIB the name of my output file so I can use R's normal package mechanisms and let it copy the file to the right directory.
In case anyone else encounters this problem I'm posting my own workaround here.
I define targets in my Makevars and copy the libraries directly (ie answer 1). The variable R_LIBRARY_DIR provides the temporary location where the package is being built.
My Makevars now looks something like this
OBJECTS =
LIBSINSTDIR=$(R_LIBRARY_DIR)/myPackage/libs/
#ARCHFLAG is set in the configure script to i386 or ppc as appropriate
JNIINSTDIR=$(LIBSINSTDIR)/#ARCHFLAG#/
.PHONY: all
all: $(SHLIB) jnilib
jnilib: object1.o object2.o
$(CXX) -bundle $(JAVA_LIBS) $(JAVA_CPPFLAGS) -o libmyPackage.jnilib object1.o object2.o
mkdir -p $(JNIINSTDIR)
cp libmyPackage.jnilib $(JNIINSTDIR)