I've been trying to install Tensorflow and get it working over the past few days. Whilst I have managed to install TF and get it working as tested by opening Python in the terminal and typing,
import tensorflow as tf
I have not been successful attempting to retrain Inception v3. I managed to install it from source once by following the instructions laid out here however I am no longer able to do so. When I get to the section 'Create the pip package and install' and go to run bazel build -c opt //tensorflow/tools/pip_package:build_pip_package in the root of my Tensorflow directiory I get the following error.
kieran#kieranUbuntu:~/tensorflow$ bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/spec.json': target 'gen/spec.json' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/head': target 'gen/head' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/branch_ref': target 'gen/branch_ref' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: Analysis of target '//tensorflow/tools/pip_package:build_pip_package' failed; build aborted.
INFO: Elapsed time: 3.063s
This is the same error I ran into when I managed to install it and then attempted retaining the classifier following this tutorial. At the section, bazel build tensorflow/examples/image_retraining:retrain.
I just can't figure out what is going wrong and I have been trying for so long.
I'm using this pip version, # Ubuntu/Linux 64-bit, CPU only, Python 2.7
I think you should search before ask, This link can probably solve your issue.
The issue lied in the incorrect use of ./configure. Whilst it was ran I currently have two versions of python on my computer, both of which are stored in different locations, when running ./configure I pointed it to the wrong python version. After rectifying the issue everything worked correctly.
Related
I am running Raspbian and have so far installed Swift 5.1.5 and cloned Vapor Branch 18.0.0 beta 27. I can't seem to get version 5.2 of Swift installed on my system somehow.
Nonetheless, the next step is to build Vapor, but it gives me the following error:
sudo swift build -c release
Updating https://github.com/jpsim/Yams.git
Updating https://github.com/apple/swift-nio.git
Updating https://github.com/vapor/console-kit.git
Updating https://github.com/apple/swift-log.git
Updating https://github.com/tanner0101/mustache.git
https://github.com/apple/swift-nio.git # master: error: terminated(128): git -C /home/pi/Downloads/toolbox/.build/repositories/swift-nio-b68c973e rev-parse --verify 'master^{commit}' output:
fatal: Needed a single revision
Not sure where to go from there, can't find any relevant info online.
Vapor 4 and the new toolbox all require Swift 5.2 - you'll need to get the installed before anything else.
Next that's an old version of the toolbox, you can find the latest release at https://github.com/vapor/toolbox/releases
Finally, the chances are you don't need the toolbox. It's used for creating new projects. If you just want to build or run existing ones, just use the swift commands
I'm trying to build a simple web app using Yew, Diesel, and Postgres. When I run
wasm-pack build --target web --out-name wasm --out-dir ./static
I get the following error:
*rust-lld: error: unable to find library -lpq*
I'm on macOS Catalina. I installed Postgres through Homebrew. My libpq.dylib file is at /usr/local/lib.
These are the troubleshooting I've tried already:
Added /usr/local/lib to $PATH. My pg_config shows LIBDIR = /usr/local/lib.
Re-installed Postgres
Updated rustc -nightly
Ideas here are not helpful as well: How can I link a Rust Wasm application with libpq via wasm-pack?
Still it is not resolved. I'd be grateful for any suggestions.
Libpq does not support the wasm-web platform as far as I'm aware therefore there is no way to make this work. As already mentioned in the comments you probably want to use diesel in your backend code, not in the frontend.
I am currently learning haskell and just tried using postgresql as a database.
I generated my project with stack (stack new <name> -> stack setup -> stack build)
and then all I changed was adding the dependencies needed to persistent and postgresql to the
package.yaml file (under "dependencies:").
These are:
persistent
persistent-postgresql
persistent-template
This however results in a failing build with the following message:
postgresql-libpq > setup.exe: The program 'pg_config' is required but it could not be found.
postgresql-libpq >
-- While building package postgresql-libpq-0.9.4.2 using:
C:\Users\\AppData\Local\Temp\stack14388\postgresql-libpq-0.9.4.2.stack-work\dist\e626a42b\setup\setup --builddir=.stack-work\dist\e626a42b configure --user --package-db=clear --package-db=global --package-db=C:\sr\snapshots\365a3dde\pkgdb --libdir=C:\sr\snapshots\365a3dde\lib --bindir=C:\sr\snapshots\365a3dde\bin --datadir=C:\sr\snapshots\365a3dde\share --libexecdir=C:\sr\snapshots\365a3dde\libexec --sysconfdir=C:\sr\snapshots\365a3dde\etc --docdir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --htmldir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --haddockdir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --dependency=Cabal=Cabal-2.4.1.0-5rQrtDcYhR2LOcYye7obEr --dependency=Win32=Win32-2.6.1.0 --dependency=base=base-4.12.0.0 --dependency=bytestring=bytestring-0.10.8.2 -f-use-pkg-config --extra-include-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\include --extra-lib-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\lib --extra-lib-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\bin --exact-configuration --ghc-option=-fhide-source-paths
Process exited with code: ExitFailure 1
Does anyone know how to resolve this issue and why it even occurs?
Do I have to install postgresql just for being able to run build the project? If so, how would you
do this in production, when the database could basically lie everywhere?
It looks like Haskell is trying to build with the PostgreSQL client shared library libpq.dll and uses pg_config at build time to determine where PostgreSQL is installed and how it was built.
That would mean that you have to install PostgreSQL on the machine where you build Haskell, including the header files, build environment or however it is called by the installer.
For running Haskell you would only need libpq.dll and the dependent shared libraries.
I solved the issue in Ubuntu with the following command:
apt install libpq-dev
I am currently following the document from swift.org to play around with the new Swift Package Manager.
I cloned the demo project from Github and run the following command from terminal.
git clone https://github.com/apple/example-package-dealer.git
cd example-package-dealer
swift build
.build/debug/Dealer
While I run swift build, error arise.
<unknown>:0: error: no such file or directory: 'build'
Any idea?
I stuck for an hour. Sadly, it's just an epic fail that downloading the wrong swift package. If you want to use swift build, MAKE SURE you download the development version.
You did not add the newly installed swift to your PATH. The instructions for doing that are here.
On OS X:
export PATH=/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin:"${PATH}"
On Linux:
export PATH=/path/to/Swift/usr/bin:"${PATH}"
Then to test it works:
swift build --version
I think it is a problem with the latest snapshot:
Ubuntu 14.04 Swift 2.2 Snapshot of January 11 contains swift-build in usr/bin
Ubuntu 14.04 Swift 2.2 Snapshot of January 25 doesn't contain swift-build in usr/bin
Besides, the January 25 release also seems to miss other files (libFoundation.so and libXCTest.so in usr/lib/swift/linux for instances).
Either there has been a structure change....or, simply, the latest snapshot had a problem ;)
While they fix the snapshot, simply take the older (January 11th) snapshot, and you should be fine.
I was facing the same issue and in my case, I recently updated my Xcode to 8.2.1 and swift 3.0 comes with it.
I was getting this log.
Ranvijay-Mac-mini:PerfectTemplate ranaranvijaysingh$ swift build
error: unable to invoke subcommand: /Library/Developer/CommandLineTools/usr/bin/swift-build (No such file or directory)
The path it was taking was incorrect. It was suppose to be:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
To change the path, run this command.
export PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH
And DONE.
Run : swift build again on your project and if you get this error.
xcrun: error: unable to lookup item 'PlatformPath' from command line tools installation
xcrun: error: unable to lookup item 'PlatformPath' in SDK '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk'
error: Invalid platform path
then you need to change the SDK path as well.
In my case, I had two .sdk at path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
MacOSX.sdk MacOSX10.12.sdk
To know what is your SDK path, run this command.
xcrun --sdk macosx --show-sdk-path
My case i got this.
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
To change it run this command.
sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
and NOW DONE.
Try running swift build now.
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.