Go to file
Arsalan H. Awan 8d202b0a3c dpdk: support build with external & multilib toolchains
This fixes dpdk build when using an external toolchain by adding
the HOST_CC_ARCH & TOOLCHAIN_OPTIONS to EXTRA_CFLAGS the way
standard Yocto does it to gather all the necessary flags for
compilation.
The TOOLCHAIN_OPTIONS variable also provides the sysroot flag, so
no need to explicitly provide the sysroot.

This commit also fixes the build when using a multilib toolchain
by adding the LDEMULATION flags to the LDFLAGS via TUNE_LDARGS
which are required while linking with a multilib toolchain.

Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
2018-10-18 10:10:22 +08:00
conf Add compatible for "sumo" 2018-04-09 12:14:52 -07:00
recipes-extended dpdk: support build with external & multilib toolchains 2018-10-18 10:10:22 +08:00
COPYING.MIT Initial commit from meta-intel 2f1bcac3fb3b42602f689fb4a1092aa5f4cf0c8a 2017-09-26 08:25:37 -07:00
LICENSE Initial commit from meta-intel 2f1bcac3fb3b42602f689fb4a1092aa5f4cf0c8a 2017-09-26 08:25:37 -07:00
README Removal of meta-intel content to make meta-dpdk standalone 2017-09-26 08:35:13 -07:00

meta-dpdk

This README file contains information on building and booting meta-intel BSP layers. Please see the corresponding sections below for details.

Yocto Project Compatible

The BSPs contained in this layer are compatible with the Yocto Project as per the requirements listed here:

https://www.yoctoproject.org/webform/yocto-project-compatible-registration

Dependencies

This layer depends on:

URI: git://git.openembedded.org/bitbake branch: 1.34

URI: git://git.openembedded.org/openembedded-core layers: meta branch: rocko

Guidelines for submitting patches

Please submit any patches against meta-dpdk to the meta-intel mailing list (meta-intel@yoctoproject.org). Also, if your patches are available via a public git repository, please also include a URL to the repo and branch containing your patches as that makes it easier for maintainers to grab and test your patches.

There are patch submission scripts available that will, among other things, automatically include the repo URL and branch as mentioned. Please see the Yocto Project Development Manual sections entitled 'Using Scripts to Push a Change Upstream and Request a Pull' and 'Using Email to Submit a Patch' for details.

Regardless of how you submit a patch or patchset, the patches should at minimum follow the suggestions outlined in the 'Submitting a Change to the Yocto Project' section in the Yocto Project Development Manual. Specifically, they should:

  • Include a 'Signed-off-by:' line. A commit can't legally be pulled in without this.

  • Provide a single-line, short summary of the change. This short description should be prefixed by the BSP or recipe name, as appropriate, followed by a colon. Capitalize the first character of the summary (following the colon).

  • For the body of the commit message, provide detailed information that describes what you changed, why you made the change, and the approach you used.

  • If the change addresses a specific bug or issue that is associated with a bug-tracking ID, include a reference to that ID in your detailed description in the following format: [YOCTO #].

  • Pay attention to line length - please don't allow any particular line in the commit message to stretch past 72 characters.

  • For any non-trivial patch, provide information about how you tested the patch, and for any non-trivial or non-obvious testing setup, provide details of that setup.

Doing a quick 'git log' in meta-intel will provide you with many examples of good example commits if you have questions about any aspect of the preferred format.

The meta-intel maintainers will do their best to review and/or pull in a patch or patchset within 24 hours of the time it was posted. For larger and/or more involved patches and patchsets, the review process may take longer.

Please see the meta-intel/MAINTAINERS file for the list of maintainers and their specific areas; it's also a good idea to cc: the specific maintainer, if applicable.