I want my Jenkins installation (on Windows) to utilise slave machines with distcc to reduce compile time.
I am using Cygwin on the slaves to run distcc, but I am having problems during the configuration i.e."./configure". The configuration does compiler checks but as I am cross-compiling for an embedded device using CMake to generate the build files, I assume I do not need to specify all this information to distcc.
I tried to explicity set it anyway using:
export CC=path/to/compiler
however, this results in error:
$ ./configure --prefix=/usr/local
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking for gcc... path/to/compiler.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.elf
checking for suffix of executables... .elf
checking whether we are cross compiling... configure: error: in `/distcc-3.2rc1':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
I believe that --build is configured correctly as I will be running distcc through Cygwin, but the values for the other variables are unclear.
Anyone had success with this kind of setup? Any other settings I am missing or has any resources for hints/tips? There doesn't seem to be howto for configuring on Windows machines.
Usually from ./configure --help
you can see the option to inform the build system that you want to compile a program that will run on a different system (HOST)
System types:
--build=BUILD configure for building on BUILD
[guessed]
--host=HOST cross-compile to build programs to run
on HOST [BUILD]
See also, for Automake:
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html
For any others who might be unfamiliar with this type of install, the compiler in this case means the compiler used to build the distcc program itself (GCC and Make).
In my case, since I will be running distcc on Cygwin on all machines, I did not need to cross compile - therefore I could simple let automake guess build/host/target option (required moving config.guess and config.sub files from automake into distcc).
Related
I am trying to build and install the OpenFst library on windows10 using MINGW64 with Msys but i got the following error during the building with make. I first used this command:
./configure --enable-grm --enable-far --enable-ngram-fsts MAKE="mingw32-make"
some of the checking results from this command generates no:
checking whether we are cross compiling... no
checking for sysroot... no
checking for a working dd... ./configure: line 7016: cmp: command not found
./configure: line 7016: cmp: command not found
checking for mt... no
checking if : is a manifest tool... no
checking for unistd.h... no
checking if gcc supports -fno-rtti -fno-exceptions... ./configure: line 8930: diff: command `not found`
checking whether to build static libraries... no
The other checking results are ok and yes. Then I used the make command:
mingw32-make
it works for some files then terminated by that error:
libtool: error: can't build x86_64-w64-mingw32 shared library unless -no-undefined is
specified
It is my first time to build with MinGW. So, I do not know what the error means and if the resulting "no" checking from the configuration responsible for it.
This is normal.
MinGW does not allow building shared libraries (DLLs) when there are still unresolved symbols, because on Windows each symbol referenced from a DLL must point to something that exists. On other platforms this is not always required.
So you should pass to -Wl,-no-undefined to gcc when linking.
For projects using autoconf's configure this is normally already done if it was a recent enough version of autoconf. Otherwise you may need to add LDFLAGS="-Wl,-no-undefined" to the configure line.
If that doesn't help you can try to change it in the libtool file generated by configure.
So specicially you can try this in MSYS/MSYS2 shell:
./configure LDFLAGS="-Wl,-no-undefined"
and if that doesn't work you can also try this (after the configure command and before running make):
sed -i.bak -e "s/\(allow_undefined=\)yes/\1no/" libtool
Other build tools like cmake, meson or scons already know how to build Windows DLLs and need no special treatment.
I'm trying to compile the binutils for the i686-elf target according to this tutorial:
https://wiki.osdev.org/GCC_Cross-Compiler
I just added the --enable-tui option, so that I have the support in the gdb.
I did the following:
# get sources
git clone git://sourceware.org/git/binutils-gdb.git
# store settings
export PREFIX="`pwd`/opt/cross"
export TARGET=i686-elf
export PATH="$PREFIX/bin:$PATH"
# create build folder
mkdir build-binutils
cd build-binutils
# run configure
../binutils-gdb/configure -target=$TARGET --prefix="$PREFIX" --with-sysroot --disable-nls --disable-werror --enable-tui
# make
make
This runs for some time and terminates with the following error:
checking for library containing socketpair... (cached) none required
checking for ld used by GCC... (cached) ld
checking if the linker (ld) is GNU ld... (cached) yes
checking for shared library run path origin... (cached) done
checking for iconv... (cached) yes
checking for iconv declaration... (cached)
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for library containing waddstr... (cached) no
configure: error: no enhanced curses library found; disable TUI
make[1]: *** [Makefile:11329: configure-gdb] Error 1
make[1]: Leaving directory '/home/noexpandtab/dev/build-binutils'
make: *** [Makefile:853: all] Error 2
For me it seems, that the ncurses library cannot be found.
I have a Debian 10 running and installed the following additional packages:
libncurses-dev
ncurses-base
ncurses-doc
libncurses5-dev
Do I have to install additional packages? Or am I missing some options for the configure script?
You're cross-compiling to a different architecture (i686-elf) than whatever you're running on—the $TARGET mentioned in the question. gdb will have to be linked with libraries which are built for that architecture.
Debian provides ncurses packages which run on the current architecture, but does not provide a suitable package for the cross-compiled application. So you get to do this for yourself.
When cross-compiling ncurses, you'll have to keep in mind that part of it builds/runs on the current architecture (to generate source-files for compiling by the cross-compiler). That's defined in the environment as $BUILD_CC (rather than $CC), as you might see when reading the script for the mingw cross-compiling. There's a section in the INSTALL file (in the ncurses sources) which outlines the process.
There's no tutorial (that would be off-topic here anyway), but others have read the instructions and cross-compiled ncurses as evidenced by a recent bug report.
I retried the whole compilation, and suddenly it works! I tested a bit and I assume I found my fault: I executed configure without --enable-tui, where make worked. Then I executed configure with --enable-tui in the same folder without cleaning it. After cleaning or running in a new folder it compiled.
Thanks to the one user who posted to delete the contents of opt/cross. (The comment itself was already somehow deleted in between.) This wasn't the solution, but leaded me in the right direction.
TL;DR: Clean the build folder before running configure with different parameters again.
I took the stage3 (experimental mips32 - stage3-mips32-20140904.tar.bz2) Gentoo tarball and put it on my Ubuntu14x64. I set binfmt in cooperation with qemu to support mips binaries, mounted /dev, /proc and so on and chrooted to the unpacked tarball. I emerge --sync-ed and it suggested me to do a emerge --oneshot portage at the end. And so I did. The problem is if it gets down to compiling it says:
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/var/tmp/portage/dev-lang/python-exec-2.0.2/work/python-exec-2.0.2_build':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
Is there any variable read from the host (maybe via /proc) making the ditro think it is cross compiling? How can I redeem that?
PS: logfiles
This may not be easy to answer concisely but I don't consider it to be open-ended: when using automakeand configure to cross-compile a library, what should be the most important things I need to avoid 'toolchain leaks'?
Here is some context...
First off, a toolchain leak is defined here: http://landley.net/writing/docs/cross-compiling.html
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
So far, I've tried to supply my toolchain's gcc compiler which looks okay, but when I run ./configure there are many things it checks for, and I'm not sure how to tell which ones truly matter, and I'm not sure how to have it only check in my toolchain and ignore anything on the host system. Here are a few examples:
Here you can see that ./configure is happy with my toolchain compiler:
checking whether we are using the GNU C compiler... yes
checking whether <toolchain>/bin/i686-linux-gcc accepts -g... yes
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
checking for grep that handles long lines and -e... /bin/grep
Then later on it searches the host system for some headers. I think I can specify where it should look, but I still don't know which headers are required:
checking for linux/compiler.h... no
checking for linux/blkpg.h... yes
checking for linux/major.h... yes
checking asm/io.h usability... no
<...>
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
I would not call that a 'toolchain leak', and the referenced article doesn't either. It does mention these things as being 'leaks':
Improper header files from the autoconf --build system (called "host" in the article, and in your post).
Improper libraries from the --build system
I don't think any toolchain I've used has it's own grep executable. What would it do differently?
That being said, it shouldn't be using --builds linux headers. Usually the toolchain has it's own copy of those. That would be a 'leak'.
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
It'll go something like this: compile the dependency with the toolchain and install it in the toolchain /usr/lib (or somewhere where you plan on keeping cross compiled libraries, if you don't want to clutter up your toolchain). Compile libuuid with the toolchain (referencing the dependency, of course).
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package