I'm new to platform builder, this might be obvious..
I'm working on wince6.0.
I've looked everywhere, didn't find how to add flags to the compilation of the image.
I've noticed there are many flags which are specific to ARM:
http://207.46.16.248/en-us/library/ee479941%28WinEmbedded.60%29.aspx
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
How do I add them to the build and which ones take parameters (and what are they)?
Are there any general flags too? what are they?
Thank you
Apparently, you need to do two things:
Go to project properties
Add environment variable named "cl" with value such as the following or a subset of them:
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
Afterwards, you edit the sources.cmn located in the BSP folder, adding:
CDEFINES=$(CDEFINES) <the flags you picked above>
For example if I wanted to use /QRArch4 and /QRimplicit-import-
The cl variable value would be /QRArch4 /QRimplicit-import-
and the line added to the sources is:
CDEFINES=$(CDEFINES) /QRArch4 /QRimplicit-import-
Related
I have a working Linux system image being produced for my ARM board with Yocto ( Dunfell branch ).
Space occupied by the rootfs is a premium and I am working on shrinking the image.
I want to experiment with the GCC '-Os' flag, to optimize for space. I would like to set this globally for my experiment. I found the following information in a presentation ( https://pretalx.com/yocto-project-summit-2020/talk/AY37HF/ ):
I added the following to my image_0.1.bb file. However, I do not see the '-Os' optimization flag being used in any package.
# Disabled until the option works properly -feliminate-dwarf2-dups
FULL_OPTIMIZATION = "-Os -pipe ${DEBUG_FLAGS}"
DEBUG_OPTIMIZATION = "-Og ${DEBUG_FLAGS} -pipe"
SELECTED_OPTIMIZATION = "${#d.getVar(oe.utils.vartrue('DEBUG_BUILD', 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}"
Is the code correct and, if so, where should I put this code? If not correct, how can I globally add the '-Os' compiler optimization flag to my project?
Global options must be added to one of the global configuration files.
For testing things this would typically be conf/local.conf.
You only need to add the variables you actually change as bitbake uses lazy evaluation of variables values.
Variables in recipe files only affect the tasks for that recipe. This means that nothing you do in the image recipe can affect how tasks in other recipes are done.
In general, how do I know what set of kernel config options are necessary to have some .ko file built?
For example, I need 'xt_conntrack.ko'. What resources are there that let me know whether or not enabling CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m in my kernel config is necessary or even sufficient to result in my built .ko file? How do I find the full set of kconfig options required to yield a kernel module?
http://cateee.net/lkddb/web-lkddb/NETFILTER_XT_MATCH_CONNTRACK.html indicates it will build "xt_conntrack", but I am not seeing it when I =m it and all of its dependencies.
On the other side, there is no set of kconfig flags visible here (http://modules.libres.ch/browse/linux/v3.0/x86_64/xt_conntrack/)
How do I find the full set of kconfig options required to yield a kernel module?
In general, determining set of options for building a kernel module is complex process. Steps described below may guide in that process.
1. Find a Makefile
Find a Makefile which builds a kernel module. This file is located in the same directory, where .ko file is produced; this directory usually coincides with a directory of module's source files. This Makefile contains a line which builds a module:
obj-${CONFIG_...} := <module_name>.o
Example:
A module xt_conntrack.ko is built by the line
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNTRACK) += xt_conntrack.o
in file net/netfilter/Makefile.
2. Determine final option
There are several ways how configuration options may affect on building a module.
The option is used directly in the line, produced the module:
obj-${CONFIG_X} := <module_name>.o
means that option CONFIG_X should be set for the module to be built.
Given Makefile is conditionally included into the upper one:
obj-${CONFIG_Y} := <dir>/
The line produced the module is guarded by "if" clause:
ifeq ($(CONFIG_F),y)
obj-m := <module_name>.o
endif
Alternatively, guard may protect inclusion of the Makefile from the upper one:
ifeq ($(CONFIG_F),y)
obj-m := <dir>/
endif
Example:
A module xt_conntrack depends by rule 1 from CONFIG_NETFILTER_XT_MATCH_CONNTRACK option.
Also it depends by rule 2 from CONFIG_NETFILTER option, because outer net/Makefile includes net/netfilter/Makefile via
obj-$(CONFIG_NETFILTER) += netfilter/
3. Find definition of the option and determine its availability
Note: This is the most complicated step, mainly because availability of the option is expressed in terms of other options. It is recommended to use ready-made tools for that. E.g., make menuconfig tool may search options and show their definition.
Every configuration option is defined in one of Kconfig files.
Definition determines:
availability of the option (when the option can be used),
possible values of the option (y/n - boolean, y/m/n - tristate, etc.),
whether the option can be set by a user.
Example:
Option NETFILTER_XT_MATCH_CONNTRACK is defined in net/netfilter/Kconfig as
config NETFILTER_XT_MATCH_CONNTRACK
tristate '"conntrack" connection tracking match support'
depends on NF_CONNTRACK
default m if NETFILTER_ADVANCED=n
help
This is a general conntrack match module, a superset of the state match.
It allows matching on additional conntrack information, which is
useful in complex configurations, such as NAT gateways with multiple
internet links or tunnels.
To compile it as a module, choose M here. If unsure, say N.
That is, the option is available (can be set) only when NF_CONNTRACK option is set.
Documentation for format of Kconfig files is located at Documentation/kbuild/kconfig-language.txt.
How do I add linker-flags "DEF" and "NODEFAULTLIB" to vs2012 project via CMAKE?
You can append them to CMAKE_EXE_LINKER_FLAGS:
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def /NODEFAULTLIB")
endif()
The general way is to add linker flags to CMAKE_xxx_LINKER_FLAGS, yes. However in case of CMAKE_SHARED_LINKER_FLAGS and /DEF: parameter, there is a special case that made me run into trouble.
If you already use CMAKE_EXPORT_ALL_SYMBOLS (CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS) then the /DEF: parameter will not appear in the linking command, even if you specified it in CMAKE_SHARED_LINKER_FLAGS.
This is because MSVC linker accepts only one /DEF: parameter, and CMake does not want to override the existing one: /DEF:<build_path>/exports.def (which is added due to CMAKE_EXPORT_ALL_SYMBOLS) with the one which you specify in the CMAKE_SHARED_LINKER_FLAGS.
You can use also CMAKE_CXX_STANDARD_LIBRARIES. It adds arbitrary linker flags without checking them, but it adds them into the middle of the linking command before the /DEF:<build_path>/exports.def so that the latter won't get overridden.
The full discussion of this case here: https://cmake.org/pipermail/cmake-developers/2019-November/031274.html.
I am developing a Linux kernel module (driver) for an embedded system in the Eclipse IDE for C/C++ Linux Developers (Indigo SR2). I have added the kernel's include directory to my project's paths to index (Project > Properties > C/C++ General > Paths and Sybmols -> Includes (tab) -> Add ... (button).) However, several of the kernel's header files refer to the asm dir, which is really an overlay of the linux/asm-powerpc directory (in my case) over the top of the linux/asm-generic directory, where the specific version overrides the generic.
How can I tell Eclipse's indexer to interpret "asm" as "asm-powerpc" first, and if that fails, then look in "asm-generic" second, instead of just looking for "asm"? Symlinking asm-powerpc to asm helps some, but too many header files exist only in the generic location to make this usable.
Thanks!
As I have discovered, there are many pieces required to direct Eclipse to index similarly to the kernel build process. However, the answer to this specific question was fairly simple:
Assuming your Linux kernel build directory is defined as ${KDIR}, and your kernel architecture is ${ARCH}, then you need to add the following include paths to your project:
${KDIR}/include
${KDIR}/arch/${ARCH}/include
You can do this in the Project Explorer, by right clicking the project, then Properties > C/C++ General > Paths and Symbols > Includes (tab) > Add ... (button).
I was missing the second entry. Adding it resolved this question. With these 2 entries, checking for unresolved includes (Right click Project > Index > Search for Unresolved Includes) produced 0 errors.
Now I have hit another stumbling block. Some of the types (like, u32 and bool) are still undefined in Eclipse. (My Makefile does not produce any errors.) I believe this is related to some kernel specific variables being undefined in the Eclipse header parsing, causing the include's IFDEF's to not be evaluated the same as during the kernel module compilation. But, I have not resolved this yet, and that pertains to another question. :)
Instead of adding the paths per project, one can also add global environment variables to Eclipse CDT.
For Eclipse Kepler, in Window > Preferences > C/C++ > Build > Environment, add variables:
C_INCLUDE_PATH = /usr/include/c++/${gcc-version}
CPLUS_INCLUDE_PATH = /usr/include:${KDIR}/include:${KDIR}/include/linux:${KDIR}/arch/${ARCH}/include
Replace ${var} above with real entries, e.g. replace ${gcc-version} with 4.6.3.
Then restart Eclipse and variables should be properly resolved.
For Kernel module development these are probably enough.
If one needs to read the whole Kernel source, read this link:
http://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source
Is there a kind of "include" directive in RPM spec? I couldn't find an answer by googling.
Motivation: I have a RPM spec template which the build process modifies with the version, revision and other build-specific data. This is done by sed currently. I think it would be cleaner if the spec would #include a build-specific definitions file, which would be generated by the build process, so I don't need to search and replace in the spec.
If there is no include, is there an idiomatic way to do this (quite common, I believe) task?
Sufficiently recent versions of rpmbuild certainly do support %include:
%include common.inc
Unfortunately, they aren't very smart about it -- there is no known set of directories, in which it will look for the requested files, for example. But it is there and variables are expanded, for example:
%include %{_topdir}/Common/common.inc
RPM does not support includes.
I have solved similar problems with either m4 macro processor or by just concatenating parts of spec (when the "include" was at the beginning).
If you only need to pass a few variables at build time, and not include several lines from another file, you can run
rpmbuild --define 'myvar SOMEVALUE' -bb myspec.spec
and you can use %myvar in the spec.
I faced this same issue recently. I wanted to define multiple sub-packages that were similar, but each varied just slightly (they were language-specific RPMs). I didn't want to repeat the same boiler-plate stuff for each sub-package.
Here's a generic version of what I did:
%define foo_spec() %{expand:%(cat '%{myloc}/main-foo.spec')}
%{foo_spec bar}
%{foo_spec baz}
%{foo_spec qux}
The use of %{expand} ensures that %(cat) is only executed a single time, when the macro is defined. The content of the main-foo.spec file is then three times, and each time %1 in the main-foo.spec file expands to each of bar, baz and qux, in turn, allowing me to treat it as a template. You could easily expand this to more than one parameter, if you have the need (I did not).
For the underlying issue, there maybe two additional solutions that are present in all rpm versions that I am aware of.
Subpackages
macro and rpmrc files.
Subpackages
Another alternative (and perhaps the "RPM way") is to use sub-packages. Maximum RPM also has information and examples of subpackages.
I think the question is trying to structure something like,
two spec files; say rpm_debug.spec and rpm_production.spec
both use %include common.spec
debug and production could also be client and server, etc. For the examples of redefining a variable, each subpackage can have it's own list of variables.
Limitations
The main advantage of subpackages is that only one build takes place; This may also be a disadvantage. The debug and production example may highlight this. That can be worked around using strip to create variants or compiling twice with different output; perhaps using VPATH with Gnu Make). Having to compile large packages and then only have simple variations, like with/without developer info, like headers, static libraries, etc. can make you appreciate this approach.
Macros and Rpmrc
Subpackages don't solve the problem of structural defines that you wish for an entire rootfs hierarchy, or larger collection of RPMs. We have rpmbuild --showrc for this. You can have a large amount of variables and macros defined by altering rpmrc and macros when you run rpm and rpmbuild. From the man page,
rpmrc Configuration
/usr/lib/rpm/rpmrc
/usr/lib/rpm/redhat/rpmrc
/etc/rpmrc
~/.rpmrc
Macro Configuration
/usr/lib/rpm/macros
/usr/lib/rpm/redhat/macros
/etc/rpm/macros
~/.rpmmacros
I think these two features can solve all the problems that %include can. However, %include is a familiar concept and was probably added to make rpm more full-featured and developer friendly.
Which version are you talking about? I currently have %include filename.txt in my spec file and it seems to work just like the C #include directive.
> rpmbuild --version
RPM version 4.8.1
You can include the *.inc files from the SOURCES directory (%_sourcedir):
Source1: common.inc
%include %{SOURCE1}
In this way they will go automatically into SRPMS.
I've used scripts (name your favorite) to take a template and create the spec file from that. Also, the %files tag can import a file that is created by another process, e.g. Python's bdist-rpm.