mirror of
https://git.yoctoproject.org/poky
synced 2026-05-09 05:29:32 +00:00
Hongxu Jia
3be1c1251b
1, There are a set of GCC built-in functions for atomic memory access. The definition given in the Intel documentation allows only for the use of the types int, long, long long as well as their unsigned counterparts. GCC will allow any integral scalar or pointer type that is 1, 2, 4, 8 or 16 bytes in length, suffix `_n' where n is the size of the data type.Such as: __sync_fetch_and_add_n __sync_fetch_and_sub_n __sync_fetch_and_or_n __sync_fetch_and_and_n __sync_fetch_and_xor_n __sync_fetch_and_nand_n The above builtins are intended to be compatible with those described in the Intel Itanium Processor-specific Application Binary Interface, section 7.4. 2, The glib-2.0-native and qemu-native invoke the above builtin function with suffix `_4', and glib-2.0-native uses __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to test the existance. 3, Not all above builtin functions are supported by all target processors.Such as i386 does not support the functions with suffix `_4', but i486 or later support. 4, Prior to GCC 4.5, on the Intel's processor, the default arch is i386 unless GCC is built with the --with-arch switch. Since GCC 4.5 the default arch is implied by the target. 5, If your host GCC is older than 4.5 and it is built without the --with-arch switch, when you use the GCC to compile target, you should specify -march to tell GCC what the target's arch is, otherwise i386 is used as default. Above all, when use older GCC to compile glib-2.0-native or glib-2.0-native, and the GCC incorrectly uses i386 as default, the above builtin function with suffix `_4' is not referenced. We should have a check in sanity.bbclass to tell the user if necessary to add march to BUILD_CFLAGS in this situation. http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins http://gcc.gnu.org/ml/gcc-help/2009-06/msg00037.html http://gcc.gnu.org/gcc-4.5/changes.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460 http://llvm.org/bugs/show_bug.cgi?id=11174 http://download.intel.com/design/itanium/downloads/245370.pdf [YOCTO #3563] (From OE-Core rev: 38042ed8586b3abe427af33debc2402caeca52cb) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
====
Poky is an integration of various components to form a complete prepackaged
build system and development environment. It features support for building
customised embedded device style images. There are reference demo images
featuring a X11/Matchbox/GTK themed UI called Sato. The system supports
cross-architecture application development using QEMU emulation and a
standalone toolchain and SDK with IDE integration.
Additional information on the specifics of hardware that Poky supports
is available in README.hardware. Further hardware support can easily be added
in the form of layers which extend the systems capabilities in a modular way.
As an integration layer Poky consists of several upstream projects such as
BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information
e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
The Yocto Project has extensive documentation about the system including a
reference manual which can be found at:
http://yoctoproject.org/documentation
OpenEmbedded-Core is a layer containing the core metadata for current versions
of OpenEmbedded. It is distro-less (can build a functional image with
DISTRO = "") and contains only emulated machine support.
For information about OpenEmbedded, see the OpenEmbedded website:
http://www.openembedded.org/
Where to Send Patches
=====================
As Poky is an integration repository, patches against the various components
should be sent to their respective upstreams.
bitbake:
bitbake-devel@lists.openembedded.org
meta-yocto:
poky@yoctoproject.org
Most everything else should be sent to the OpenEmbedded Core mailing list. If
in doubt, check the oe-core git repository for the content you intend to modify.
Before sending, be sure the patches apply cleanly to the current oe-core git
repository.
openembedded-core@lists.openembedded.org
Note: The scripts directory should be treated with extra care as it is a mix
of oe-core and poky-specific files.