On a Ubuntu 16.04.2 I am trying to compile code with a newer gcc.
So I did the following:
in the workspace create a file tools/cpp/CROSSTOOL
copy latest CROSSTOOL content from bazel repo into that
in CROSSTOOL file, under identifier local_linux, change /usr/bin/gcc to /usr/bin/gcc-7
Call bazel build //foo
When I output the commandline executed to build //foo:foo, it calls /usr/bin/gcc.
Can someone point out what I am doing wrong?
You are probably using static crosstool that is only used for bootstrapping and some tests (and some other details). What bazel usually uses is tools/cpp/CROSSTOOL.tpl which is a template populated by tools/cpp/cc_configure.bzl. This is the script that inspects CC environment variable and if set, it uses that for gcc.
Of course you can use static crosstool, you just have to tell bazel about it using --crosstool_top=//some/crosstool flag. You can save it in a project local .bazelrc.
Related
Scenario:
We would like to build our sources by an external / hermetic toolchain so all includes, libs and tools from the host are ignored
To do so, a new toolchain is introduced to Bazel-Configuration. >>> working well
Using -Wl,-rpath=$ORIGIN/%{runtime_library_search_directories}/... the relative path from the binary to the libs that should be loaded on runtime gets defined >>> works quite well
When doing bazel run the Binary is executed but the host's LD is being used
To get rid of this a wrapper (written in Bash) is injected using --run_under. >>> dirty workaround
Problem:
--run_under could only be used once. We also need this option to execute tests within a specific environment and so this option is not the way of choice for us. IMHO it's also a bit dirty workaround.
We also tried to use -Wl,--dynamic-linker=<<PATH_TO_LD>>. But we were not able to get neither a relative nor an absolute path to LD when linking the executable.
Questions:
Is there ...
... any way to get the absolute/relative path to LD when linking?
... any other way of running a binary on Host using a toolchain?
... a possibility to do sandboxing/chroot so the correct LD of the toolchain is being used automatically?
Sidenotes:
Bazel 1.1.0 is used
the toolchain is GCC8 build from sources
the host is an Ubuntu 18.04.1 image running in docker
I'm trying to use rustlearn crate in my project. Added the dependency in Cargo.toml.
Since rustlearn requires gcc, I downloaded and installed MinGW64.
I tried the following gcc builds:
x86_64-8.1.0-posix-seh-rt_v6-rev0
x86_64-8.1.0-posix-sjlj-rt_v6-rev0
i686-8.1.0-posix-sjlj-rt_v6-rev0
each time setting a PATH environment variable to the appropriate g++.exe and restarting VSCode.
But everytime I tried to build my Rust package I got a such error:
= note: C:\Rust\PF\machinelearning\target\debug\deps\librustlearn-4ae611e3fd449ac0.rlib(svm.o): In function `ZN6KernelC2EiPKP8svm_nodeRK13svm_parameter':
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:256: undefined reference to `__gxx_personality_sj0'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:256: undefined reference to `_Unwind_SjLj_Register'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:258: undefined reference to `_Unwind_SjLj_Resume'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:289: undefined reference to `_Unwind_SjLj_Unregister'
repeated many times.
I realize that the problem is somehow related to exception handling (seh/sjlj).
My system is Windows 7 x86-64, rust toolchain is stable-i686-pc-windows-gnu.
What am I doing wrong?
I found that the right build of MinGW is i686-7.1.0-posix-dwarf-rt_v5-rev2.
I did not run into these errors when I created a MWE.
To me, this looks like you are trying to use gcc to link a *.o that was compiled with g++.
I was unable to replicate your problem. Here's what I did--which resulted in a successfully built project:
I created a new project with cargo new and added the following to Cargo.toml:
rustlearn = "0.5.0"
I ran cargo check to download all the required dependencies.
I edited src/main.rs to include the logistic regression example from here, modified so that it was called in a main() function.
I ran cargo build, which successfully compiled crossbeam, libc, serde, rand, rustlearn, and rustlearn-test--the name of my test package. Several linting warnings were outputted; they were ignored.
I ran cargo run, which successfully ran the program.
FWIW, I'm using the WSL on Windows 10.
How can I build a Linux kernel in Travis CI. I have added script: make menuconfig to my Travis config and it doesn't work and says
No output has been received in the last 10 minutes
How can I fix this?
Link to GitHub repo : https://github.com/ProjectPolyester/tegra_kernel and submit fixes in PRs if possible
Travis monitors your build process and if there is no output for about 10 minutes, it assumes that your process is stuck somewhere for unknown reasons, and then kills it.
Solution in your case :
You need to provide with the actual build command.
make menuconfig
actually just allows you to configure the kernel. It doesn't really starts the kernel build process. So there is no output of this command.
Also, the kernel should already be configured or you can download the appropriate .config file if its available some where online. And then there will be no need to execute:
make menuconfig
The build command
It can be simply
make
or something like
make -j3 modules ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOCALVERSION=-$SOURCE_VERSION
The second one is actually to perform cross compilation.
You also need to set all the prerequisites like downloading the header file etc
You may want to take a look at this script , it crosscompiles the modules only, not the entire kernel.
If you want to use the old config for a new kernel, you can use make olddefconfig. Here is my example how to compile and boot a new kernel in travis: https://github.com/avagin/criu/blob/linux-next/scripts/travis/kexec.sh#L54
I know that this is an old thread but I was recently able to get Travis CI working on building a Linux kernel
https://github.com/GlassROM-devices/android_kernel_oneplus_msm8994/commit/6ed484812bbd4a25c3b22e730b7489eaaf668da1
GCC fix is for toolchains compiled on Debian unstable, arch, gentoo, etc. These toolchains will fail to compile on Ubuntu so you'll have to use the GCC fix for these toolchains
And you really want to upgrade GCC before you even try building a kernel. Travis CI has a very old GCC that will fail if you try to compile the kernel
In my commit I'm building it with GCC 8 linaro built by myself
I'm using CMake 2.8.6 and the latest Intel C++ Compiler for a program which is compiled for Linux, MacOSX and Windows. For the development I'm using Eclipse with CDT on Linux and MacOSX.
Until recently I used CMake to create usual Makefiles which I ran from the console. To have a working environment, the Intel compiler comes with a shell-script called iccvars.sh which can be sourced to set all required include- and library-paths.
Now I decided to give the Eclipse-CDT build-system a chance and used the "Eclipse CDT4 - Unix Makefiles" generator of CMake to create an Eclipse project file. Everything works fine under Linux, but under OSX, Eclipse does not know about the environment variables and therefore paths like DYLD_LIBRARY_PATH are missing and the compilation stops because libraries are not found.
Update
Let me explain in more detail what I do. I'm running
cmake -G "Eclipse CDT4 - Unix Makefiles" path/to/src
from within the terminal where source iccvars.sh was executed and all environment-variables are set correctly. If I would have created a normal Makefile there and would run make, the compilation would succeed. This is because of the DYLIB_LIBRARY_PATH (in Linux LD_LIBRARY_PATH) is set correctly and I do not have to give -L/path/to/libs as option to the compiler.
But instead, I start Eclipse and import the created .project which works fine. The problem is that Eclipse do not know about my environment in the console and therefore cannot find the required libraries. One solution would be to use find_library inside CMakeLists.txt and locate every required library because then the full path should be included in the created Makefiles. Instead, I was wondering whether...
Question: Is there a way to source the iccvars.sh into my CMakeLists.txt so that the paths are available even when I'm not in my usual terminal-environment? Are there other possibilities?
Please note, that I know you can set environment variables for GUI-programs under OSX. What you have to do is to create a file environment.plist in your home under ~/.MacOSX. In this xml-file you put all your variables a GUI program should have. This works fine for other applications, but especially the Eclipse-builder seems to ignore this.
How can I integrate SCIP with MinGW and Msys?
Whilst you are waiting for a real answer, I can already guide you to this page from the official site on how to build SCIP (see below). For actual integration there is a pointer in the faq:
How do I construct a problem instance in SCIP?
First you have to create a SCIP object via SCIPcreate(), then you
start to build the problem via SCIPcreateProb(). Then you create
variables via SCIPcreateVar() and add them to the problem via
SCIPaddVar(). The same has to be done for the constraints. For
example, if you want to fill in the rows of a general MIP, you have to
call SCIPcreateConsLinear(), SCIPaddConsLinear() and additionally
SCIPreleaseCons() after finishing. If all variables and constraints
are present, you can initiate the solution process via SCIPsolve().
Make sure to also call SCIPreleaseVar() if you do not need the
variable pointer anymore. For an explanation of creating and releasing
objects, please see the doxygen documentation.
NOTE: See the directories "examples/MIPsolver/" and "examples/Queens/" for simple examples
Remarks on Building/Installing under Windows using MinGW (from http://scip.zib.de/doc/html/INSTALL.php)
To build your own Windows binaries under Windows, we recommend using
the MinGW-Compiler with MSYS from mingw.org
First install MSYS, then MinGW to the mingw folder inside the msys
folder. Now you need to install the following packages to the mingw
folder:
- zlib (or use ZLIB=false ZIMPL=false since zlib is needed for ZIMPL and ZIMPL-support in SCIP)
- pcre (or use ZIMPL=false since pcre is needed for ZIMPL and ZIMPL-support in SCIP)
- gmplib (or use ZIMPL=false since gmplib is needed for ZIMPL and ZIMPL-support in SCIP)
(After calling "make clean" in the ZIMPL folder you will also need
flex and bison to remake ZIMPL. We recommend NOT to use "make clean"
inside the ZIMPL-folder if you do not have these packages installed.)
You can download these additional packages as precompiled binaries for
example from: http://gnuwin32.sourceforge.net/packages.html
(zlib&pcre) http://cs.nyu.edu/exact/core/gmp/ (gmplib) or compile the
source on your own from the project homepages: http://www.zlib.net/
http://www.pcre.org/ http://www.gmplib.org/ (The command "./configure
--prefix=/mingw ; make ; make install" should succeed without problems and installs the packages into the mingw folder.)
Now "make READLINE=false" should be compiling without errors. Please
note that we do NOT support creating the doxygen documentation or
readline-usage under Windows.
Since there are no real symlinks in MSYS, the include and library
files of SoPlex and ZIMPL are actually copied into the
SCIP-lib-folder. When you recompile ZIMPL or SoPlex after compiling
SCIP you have to copy the libraries manually into the SCIP-lib-folder
and recompile SCIP afterwards.