following example in Tensorflow site;
i am trying to retrain inception model final layer in Ubuntu+python 2.7 environment.when running below command
$ bazel build /home/incept/tensorflow/tensorflow/examples/image_retraining:retrain
it gives an error.
ERROR: not a valid absolute pattern (absolute target patterns must start with exactly two slashes)
any suggestion to fix this? example mention try
$ bazel build tensorflow/examples/image_retraining:retrain
Just to summarize general TensorFlow build issue debugging (on Linux) in case other people end up here with similar issues:
Make sure you're in the directory you checked out. So if git clone made you a tensorflow directory, bazel commands should be run in that directory tree. It doesn't matter where in the tree if the build target is absolute (//tensorflow/...).
Run ./configure in the tensorflow directory. This fetches necessary dependencies in addition to allowing you to configure the build (you can yes "" | ./configure if you don't want to bother answering the questions and just want the defaults).
Make sure you have the latest version of Bazel and a compatible Java installation.
The git repository changes quite a bit. git pull will get you the latest (git checkout can get you any version you'd like).
Related
I am using conan in an enterprise environment where the operating system is rather old and has an old version of glibc (2.11). As a result, a lot of the pre-built binaries on conan.io do not end up working in my environment. However, conan doesn't know that and will happily download and install them on my system, resulting in link-time errors.
I have found that if I build from source I can get the libraries to work.
My desired behavior would be as follows:
The first time using conan install to install the library (e.g. it is not in my cache) then conan will build from source and place it in my cache, then use it.
On subsequent invocations of conan install, conan finds the cached library and uses that without having to rebuild from source.
I am invoking conan install as part of an automated build script, so I would like to not have to modify the invocation depending on if this is the first time the library is installed or not (but modifying a configuration file is fine).
I have had troubles obtaining this behavior in practice. Here are the challenges I have run into:
If I use conan install --build=thelibrary then conan will rebuild that library from source every time I invoke conan install --build=thelibrary, even if it is already present in my cache.
If I use conan install --build=missing, then Ican trick conan into building the library by setting some build options that do not have a pre-built binary associated with them.
This is fragile, as it only works for projects with enough build options that it is not tractable to create pre-built options for all combinations.
It also doesn't work if all the build options I need correspond to a pre-built binary.
Here is what I am looking for (and I assume exists but am not able to find):
Some setting I can place in my conanfile.txt (or some other configuration file) that tells conan to ignore pre-built binaries for a given library or libraries and instead build from source, but use the cached version if it is available.
This ideally should work without me having to tinker with build options.
I don't necessarily want to build all libraries from source, just the ones that won't run on my ancient OS, but if I have to settle for "all-or-nothing" I will take "all".
Is this possible with conan?
glibc version is an old headache for Conan, because it's not part of settings, thus is not counted as part of package ID. The Conan Docker images are running Ubuntu, some of them are old, others are new. But there is a specific Docker image running CentOS6, which was created because of glibc 2.12 and could help with package generation.
For your specific case, we have few options:
Add glibc as part of settings, so Conan won't replace your package because of its package ID. As you should have more coworkers, you can use conan config command for settings distribution.
# ~/.conan/settings.yml
glibc: [None, 2.11, ...]
Adding it, you can update you profile too, making glibc=2.11 as a default setting.
Another alternative is package revisions feature, where you can lock a specific binary package for usage, which means, you want use that specific package. You just need to upload your generated package with glibc and use its binary package revision, e.g. lib/1.0#conan/stable#RREV:PACKAGE_ID#PREV
Also, answering your question:
Some setting I can place in my conanfile.txt (or some other configuration file) that tells conan to ignore pre-built binaries for a given library or libraries and instead build from source, but use the cached version if it is available.
Your cache is Conan first option, it will look for a pre-built package there first, if it's not available, it will look into your remotes, following a sorted order. Your request is not possible, first, because conanfile.txt doesn't support build policies, second, because conanfile.py only supports build all from sources, or build only missing.
My propose is, install an Artifactory instance, build what you need, upload your custom packages, and make it as your default remote.
I don't necessarily want to build all libraries from source, just the ones that won't run on my ancient OS, but if I have to settle for "all-or-nothing" I will take "all".
You can associate some package reference to a remote, running conan remote command. Let's say you want to download zlib/1.2.11 built with glibc-2.11 and it's available only in your organization remote:
$ conan remote add_ref zlib/1.2.11#org/stable my_org_repo
$ conan remote list_ref # only to validate, not mandatory
zlib/1.2.11#org/stable: my_org_repo
Now your specific package is associated to your organization. Conan still will look for that package your local cache first, but when not found, it will try to find at your Artifactory.
As you can see, your case could be solved easier using a new setting, instead of trying to hack build policies. As another alternative, you can replace glib setting by distro and its version.
Boost using this build system I'm not otherwise familiar with, based on "Jam" files. Now, I've forked and cloned a specific Boost library (program_options), and I want to build it and perhaps also run the tests. I notice a build/Jamfile.v2 - what should I do with it?
I tried apt-get install jam on my distribution, but that did not get me very far:
$ jam -fbuild/Jamfile.v2
warning: unknown rule project
warning: unknown rule boost-lib
don't know how to make all
...found 2 target(s)...
...can't find 1 target(s)...
Also, do I have to get the absolute latest development version of all of Boost to build the cloned library against, or can I use a local boost release I already have?
Notes:
I'm on a recent GNU/Linux distribution (Mint 18.3 but this shouldn't matter).
What I've done, based on #SergeyA and others' advice, is:
Clone all of Boost, recursively (see this page (this will create a boost/ folder )
cd boost
in .git/modules/my_boost_lib/config, change the origin URL to your fork
in .gitmodules, under [submodule "my_boost_lib"], change the URL to your fork
execute git submodule update --init libs/my_boost_lib/ (perhaps after deleting that library; not sure if that's actually necessary)
cd libs/my_boost_lib/build
../../../b2
The latter works because b2 looks for a Jamfile.v2 in its current working directory, and that file exists and is intended to build just the library. The build results will be located outside of libs/my_boost_lib though.
Note: To build run the library tests, build the same way but from libs/my_boost_lib/test.
Essentially the build steps is
Run bootstrap to build the build tool b2
Build boost with b2 install or similar. You may want to provide options to it.
Read more in the boost getting started document:
http://www.boost.org/doc/libs/1_66_0/more/getting_started/index.html
(hint, look at lower right to go to next page..)
If you are on windows / VS2017, the use of vcpkg to get boost is very easy.
I'm trying to install Loris package link which is a library also for Python (my language). I have installed the package through bash commands in my OSX 10.12 system following these steps:
cd to the directory containing the package's source code and type
./configure to configure the package for your system. If you're
using csh on an old version of System V, you might need to type
sh ./configure instead to prevent csh from trying to execute
configure itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
Optionally, type `make check' to run any self-tests that come with
the package.
Type `make install' to install the programs and any data files and
documentation.
You can remove the program binaries and object files from the
source code directory by typing make clean. To also remove the
files that configure created (so you can compile the package for
a different kind of computer), type make distclean. There is
also a make maintainer-clean target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
The problem is that when I run both python 2.7 IDLE and the Atom editor it says that the module named Loris was not found. By default, make install will install the package's files in
/usr/local/bin,/usr/local/man.
Is this the problem? How can I install properly this library?
I have searched here on StackOverflow and other sites to figure out how to install OpenCV 3.0 the Contrib Modules. I have downloaded the extra modules and extracted the zip file to the /opt/local/include/opencv2/opencv_contrib/ folder. I've navigated to the /opt/local/include/opencv2 folder and typed the following command in the terminal:
cmake -DOPENCV_EXTRA_MODULES_PATH=/opt/local/include/opencv2/opencv_contrib/modules/ /opt/local/include/opencv2
I get:
-bash: $: command not found
If I just type in cmake -D, I get:
CMake Error: -D must be followed with VAR=VALUE.
CMake Error: Problem processing arguments. Aborting.
So I know it recognizes the cmake command with the -D tag.
Any ideas?
Nobody said that installing OpenCV and their modules was easy.
Just like you, I already had Opencv 3.0.0 installed and running and wanted to add the contrib modules.
Steps:
1st- Delete and download again the OpenCV3.0.0 folder (is not necessary, but after twitching around, I prefer to download a new one) download the openccv_contrib and place them in the same folder.
2nd- Go to the OpenCV3.0.0 and create the build folder.
3rd- Open Cmake gui and follow the steps form https://github.com/itseez/opencv_contrib.
3.1- Fill “Where is the source code” with the rotute of where is openCV3.0.0. (my case /Users/Rafearl/Program/ComputerVision/opencv-3.0.0)
3.2- Fill “Where to build binaries” with the build route(/Users/Rafearl/Program/ComputerVision/opencv-3.0.0/build)
3.3- Press configure
3.4- In the search bar search for “OPENCV_EXTRA_MODULES_PATH” and fill with the Opencv_contrib modules(/Users/Rafearl/Program/ComputerVision/opencv_contrib-master/modules)
3.5- Click configure again and then click generate. By default current generator: Unix makefiles
4th- In terminal go to your build folder
5th- make -j4 (4 is the number of cores of the processor)
6th- sudo make install
Now you can check the lib in the build folder that the contrib libraries are added
If you don´t want to download the OpenCV3.0.0 again just follow the same steps without downloading or deleting anything.
If you already have Opencv in Xcode, everything should work but just as a piece of advise; many of the OpenCV2.4 examples does´t work in the 3.0 version.
I am new in Ubuntu/Linux and I've been working with java using the NetBeans IDE, so I don't have much experience with building c++ projects. But now I have to provide a proof of concept and I need to connect a C++ client with my ActiveMQ server. I downloaded The ActiveMQ-CPP API from this link, but I can't build/run it.
The download came with the files: Maklefile.am and Makefile.in. I searched it and I found that I need automake/autoconf to build it. I tried running ./configure but it says that it couldn't find such file or directory. I tried
sudo apt-get update
sudo apt-get install automake
sudo apt-get install autoconf
and a lot of other commands that I found on the Internet. None of then worked. I know that this question is really basic and it seems to be already answered somewhere else, but every attempt I've made failed. I think I'm missing something. I even tried the solution provided in the last message in this topic but it didn't work either.
Can anyone help me install autoconf/automake, or tell me how to use Makefile.am / Makefile.in to build the project I downloaded, or even suggest me some other way of building it?
Since you're open to other methods of building your project, I'm going to suggest CMake. It is a far better build system than autotools (at least from where I stand).
#CMakeLists.txt
project(MyProject CXX)
set_minimum_required(VERSION 2.8)
add_executable(foobar foo.cpp bar.cpp)
That example will build an executable called "foobar" by compiling and linking foo.cpp and bar.cpp. Put the above code in a file called CMakeLists.txt, then run the following commands:
cmake <path to project> #run in the folder you want to build in
make #this does the actual work
The really cool thing about CMake is that it generates a build system (Makefiles by default) but you can use it to generate project files for Eclipse, a Visual Studio solution, and a bunch of other things. If you want more information, I'd check out their documentation.
The "configure" script should be in your ActiveMQ-cpp source directory. From the Linux command line, you should be able to:
1) "cd" into your ActiveMQ* directory
2) "ls -l" to see the "configure" script
3) "./configure" to set things up for building the library\
4) "make" to actually build the library
This is mentioned in comments, but this particular point of confusion has been common for well over a decade and I think needs to be clarified as often as possible. You DO NOT need to have autoconf or automake installed to build a project that used those tools. The entire point of the autotools is to generate a build system that will build on a system using only the standard tools (make, a c compiler, sh, and few others.) Unfortunately, many developers release tarballs that do not build cleanly. If you unpack the tarball and it does not contain a configure script, or if the configure script is broken, that is a bug in the package. The solution is absolutely not to install autoconf/automake/libtool and try to produce a working configure script. The solution is to report the build error as a bug to the package maintainer.
The world would be a better place if Linux distributions stopped installing multiple versions of the autotools by default as less than .002% of the population needs those tools, and anyone who actually needs to have the tools should be capable of installing it themselves. Anyone incapable of acquiring and installing the tools has no business using them.