Building only gcc using yocto - yocto

I was trying to build only gcc using yocto. I tried with "bitbake-layers show-recipes" it was showing multiple recipes for gcc, similarly for bitbake -s.
#bitbake-layers show-recipes
gcc:
meta 4.8.2
gcc-cross:
meta 4.8.2
gcc-cross-canadian-arm:
meta 4.8.2
gcc-cross-initial:
meta 4.8.2
gcc-crosssdk:
meta 4.8.2
gcc-crosssdk-initial:
meta 4.8.2
gcc-runtime:
meta 4.8.2
gccmakedep:
meta 1:1.0.2
#bitbake -s
gcc :4.8.2-r0
gcc-cross :4.8.2-r0
gcc-cross-canadian-arm :4.8.2-r0
gcc-cross-initial :4.8.2-r0
gcc-crosssdk :4.8.2-r0
gcc-crosssdk-initial :4.8.2-r0
gcc-runtime :4.8.2-r0
gccmakedep 1:1.0.2-r3
Please guide me to understand why there are multiple recipes related to gcc and which one I have to build.
In yocto, is there one to one match for recipe and package. i.e for creating each package there is a corresponding only one recipe?

To explain each one in turn:
gcc is the recipe for gcc that runs on the target machine itself.
gcc-cross is the cross-compiler that the build system uses. If you build any recipe for the target that needs to be compiled with gcc, this is what will be used to compile that.
gcc-cross-canadian- is the final relocatable cross-compiler for the SDK, in this case for the ARM architecture.
gcc-crosssdk is an intermediate step in producing gcc-cross-canadian.
the *-initial are the initial versions of the compiler required to bootstrap the toolchain separately for the standard cross-compiler and for the SDK.
gcc-runtime builds the runtime components that come as part of gcc (e.g. libstdc++).
gccmakedep isn't really part of gcc itself, it's a script that comes as part of the X11 utilities that some projects need to determine dependencies for each source file.
When you say "you only need to build gcc", it's not entirely clear what you mean, but I suspect it's either gcc for the target (in which case it's "gcc", though I suspect you'll probably need more than that - packagegroup-core-buildessential may be what you want) or you want a cross-compiler you can install separately in which case you probably ought to bitbake meta-toolchain or bitbake -c populate_sdk imagename. That'll contain more than just gcc but it's likely gcc alone isn't going to be enough anyway.

GCC is a huge project. Maybe this recipe could help you understand GCC and Yocto a little bit better. The following information is some information paraphrase from "Embedded Linux Projects Using Yocto Project Cookbook" by Alex Gonzalez
GNU toolchain contains the following components:
Assembler (GNU as): part of the binutils package
Linker (GNU Id):
part of the binutils package
Compiler (GNU gcc): support for C, C++,
Java, Ada, Fortran, and Objective C
Debugger (GNU gdb): GNU debugger
Binary file tools (objdump, nm, objcopy, readelf, strip, and so on):
these are part of the binutils package
These components are enough to build bare metal applications
bootloaders like u-boot, Linux Kernel because they do not need C
library and they implement C library functions they need.
POSIX-compliant C library is needed for LInux user space applications.
glibc is the default C library used in the Yocto Project.
On Embedded Systems, we need a cross-compilation toolchain. We build
in a host computer but run the result binarines on the target which is
usually different architecture. There are several types of toolchains
based on build machine, target machine.
The most common combinations are:
Native: An example of this is an x86 machine running a toolchain that >has also been built on an x86 machine
producing binaries to run on an x86 machine. This is common in desktop
computers.
Cross-compilation: This is the most common on embedded
systems; for example, an x86 machine running a toolchain that has also
been built on an x86 machine but producing binaries to run on a
different architecture, like ARM.
Cross-native: This is typically the
toolchain running on targets. An example of this is where a toolchain
has been built on an x86 machine but runs on ARM and produces
Canadian: Rarely seen, this is where the build, host, and target
machines are all different.

Related

How can I get Ada GNAT gcc 7.3 for Solaris 11?

We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).

buildrpm fails when cross building C++ for 32-bit ARM (from x86-64)

I successfully compiled C++ code for a Raspberry Pi (ARM architecture).
Such binaries have a file command return the following :
usr/local/company/product/this: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=9fe73c254b317e239758e4445d12b8441a3cb13e, not stripped
I now wish to generate RPM packages (not .deb packages, real .RPM packages!).
I've tried many --target and spec's file buildarch combinations without much success.
Tried armv7l, arm-linux-gnueabihf, arm-linux ...
Same result is returned by rpmbuild :
Building target platforms: arm-unknown-linux
Building for target arm-unknown-linux
error: No compatible architectures found for build
I'm compiling from an x86_64 Ubuntu. The destination architecture is arm-linux-gnueabihf.
I call rpmbuild as follow :
rpmbuild -bb --target armv7l myfile.spec
On my RHEL 7 computer, the /usr/lib/rpm/rpmrc includes several ARM variants:
armv3l, armv4b, armv4l, armv4tl, armv5tel, armv5tejl, armv6l, armv7l, armv7hl, armv7hnl. I guess your file will have a similar selection, and thus include the armv7l option you selected.
I found that for cross-packaging, running rpmbuild --target _target_ was not enough. I also had to use a setarch _target_ wrapper around the build command.
You may need to add your arm architecture (displayed by uname -m) to /usr/lib/rpm/rpmrc configuration.
GOARCH=amd64 or arm64
used the command:
rpmbuild ... --define="GOARCH ${GOARCH}"
spec file should include this content
%if %{GOARCH} == "amd64"
BuildArch: x86_64
%endif
%if %{GOARCH} == "arm64"
BuildArch: aarch64
%endif

In compiling shogun machine learning toolbox for matlab interface, what are the necessary packages I need to install for cygwin?

I don't want to install all as it consumes much space..
the following is what i'm sure is needed:
gcc, make python..
what else?
On the site, in their documentation on installing...
http://www.shogun-toolbox.org/doc/en/current/installation.html
Requirements
SHOGUN requires the standard linux utils like bash, grep, test, sed,
cut, ldd, uname gcc g++ and cat python (debian package: python2.4 or
python2.5) for the ./configure to work.
Optionally you will need atlas and lapack (debian packages
lapack3-dev, atlas3-headers atlas3-base-dev or atlas3-altivec-dev
atlas3-sse2-dev) installed. Note that atlas/lapack is only supported
under linux (high performance computing should be done under linux
only anyway). In case atlas/lapack is unavailable, don't worry most of
shogun will work without, though slightly slower versions are used.
To
enable Multiple Kernel Learning with CPLEX(tm) just make sure cplex
can be found in the PATH. If it is not found shogun will resort to
GLPK (if version at least 4.29 is found) for 1-norm MKL, p-norm MKL
with p>1 will work nonetheless.
To compile the C# interface you need to have the C# developer files
(debian package mono-utils) installed.
To compile the Lua interface
you need to have the Lua developer files (debian package lua)
installed.
To compile the Java interface you need to have the Java
developer files (debian package openjdk-6-jdk) installed.
To compile
the R interface you need to have the R developer files (debian package
r-base-dev) installed.
To compile the Ruby interface you need to have
the Ruby developer files (debian package ruby) installed.
To compile
the octave interface you need to have the octave developer files
(debian package octave3.0-headers) installed.
To compile the python
interface you need to have numpy version 1.x installed (debian package
python-numpy) installed.

buildroot environment with host toolchain

For running testcases etc. I would like to compile parts of our buildroot environment for the Host system (/usr/bin/gcc etc.).
I tried specifying an external_toolchain in /usr but this fails. Has anyone managed to do something like this?
The buildroot manual says this is unsupported because they can not import it into a rootfs. But for testcases a rootfs is not necessary.
Yeah, unfortunately, it is not possible to do this. To be useful for Buildroot, a toolchain has to be a "pure" toolchain, i.e containing only the C library binaries and headers. You /usr is cluttered with gazillions of libraries from your host machine, and since Buildroot makes a full copy of the toolchain sysroot (which in your case, would be /usr), it would copy many, many things.
So definitely, it is not something that we support, and we don't intend to support this. You can also decide to build your programs with a x86 or x86_64 cross-compiler, have Buildroot generate a minimal Linux system, and chroot into it directly on your development PC.
The current documentation also seems to explain that this is not possible https://github.com/buildroot/buildroot/blob/2018.08/docs/manual/configure.txt#L198
We also do not support using the distribution toolchain (i.e. the
gcc/binutils/C library installed by your distribution) as the
toolchain to build software for the target. This is because your
distribution toolchain is not a "pure" toolchain (i.e. only with the
C/C++ library), so we cannot import it properly into the Buildroot
build environment. So even if you are building a system for a x86 or
x86_64 target, you have to generate a cross-compilation toolchain with
Buildroot or crosstool-NG.
Furthermore, current Buildroot seems to check if your toolchain path seems to be a global toolchain, and bails out automatically if it is https://github.com/buildroot/buildroot/blob/2018.08/toolchain/helpers.mk#L395
with_sysroot=`$${__CROSS_CC} -v 2>&1 |sed -r -e '/.* --with-sysroot=([^[:space:]]+)[[:space:]].*/!d; s//\1/'`; \
if test "$${with_sysroot}" = "/" ; then \
echo "Distribution toolchains are unsuitable for use by Buildroot," ; \
echo "as they were configured in a way that makes them non-relocatable,"; \
echo "and contain a lot of pre-built libraries that would conflict with"; \
echo "the ones Buildroot wants to build."; \
exit 1; \
fi; \

solaris sparc 9/10 libstdc++ compatibilty issue (64 bit)

I have gcc 3.4.6 installed on sparc9 and sparc10 systems. I am having incompatibility issues when I try to use shared object(built on sparc9) on sparc10. I am not seeing any issue if I use same shared object on sparc9 system. Snippet from makefile:-
LIB=-L/usr/lib/sparcv9 -L/usr/local/lib/sparcv9 -L/lib/sparcv9
gcc -m64 -shared -fPIC -o myapi.so.1 myapi.o $(LIB) -lc -lstdc++ -luuid
Now following in sparc10:-
ldd -d /home/myapi.so
libstdc++.so.6 => /usr/local/lib/sparcv9/libstdc++.so.6
symbol not found: _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode (./myapi.so)
I have skipped other dependencies in above output which appear normal.
Then, I ran "nm" against libstdc++.so.6 in /usr/local/lib/sparcv9 for above unreferenced symbol and came with following conclusion:-
V9---> _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode
V10--->_ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode
If you look carefully, you can see a difference in mangled-name symbol in sparc9 and sparc10... "ExSt12" v/s "ElSt12".
Similarly, if I build myapi.so on sparc10, it fails on sparc9 because of symbol mismatch in V9 and V10.
Can someone please point me to any helpful hints as to if I am missing something? Or do I need to install any package on V9. I am assuming that shared object built on V9 should work on V10.
I would like to add that there is a size of libstdc++.so.6 on V9 is different from V10. V9 has SMCgcc and V10 has both SUNWgccruntime and SMCgcc.
Those symbols demangle as:
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode)
and
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)
Notice that one uses long and the other uses long long
I suspect that means one was built with 64-bit file offsets (aka large file support) and the other wasn't. That means the two versions of GCC have been built differently (by sunfreeware.com or whoever provided them) and are incompatible.
Looks like you're using incompatible versions of the GNU C++ compiler & standard library on the two OS'es. Unfortunately, there is no standard ABI for C++ and many compilers change symbol mangling conventions incompatibly between major releases (such as Sun C++ compiler 4.x vs. 5.x, or g++ 2.x vs. 3.x vs. 4.x).
The /usr/local/lib path implies you're using the libraries from the SMCgcc packages downloaded from the sunfreeware.com site - make sure you have matching versions on the Solaris 9 and 10 machines. (There is no "sparc 10", so you must mean Solaris 10.)