Yocto Bitbake fails to find wrapper headers (include_next stind.h no such file) - yocto

I'm trying to create a bitbake recipe to build some source code that resides in a local folder (as opposed to fetching from a remote repo).
After running bitbake, I expect to have an executable file and a shared library in the resulting image.
The source code includes three CMakeLists.
So far, I'm able to:
Run cmake by itself to build the source code on my host and on the target (i.e. not using bitbake)
Using my .bb file, correctly point to the source code by using the variable OECMAKE_SOURCEPATH.
start running cmake using the default do_compile()
The build fails during do_compile() with the error:
In file included from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Inc/typedefs.h:29,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/DOIP/DOIP.h:32,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_MAIN/ISOUDS_Server_Cfg.h:30,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_ClearDiagInfo/ISOUDS_ClearDiagInfo_Cfg.c:25:
| /home/myname/project/nxp_s32/build_s32g274asbc2/tmp/work/aarch64-ms-linux/embitel-uds/1.0.0-r0/recipe-sysroot-native/usr/lib/aarch64-ms-linux/gcc/aarch64-ms-linux/10.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
| 9 | # include_next <stdint.h>
| | ^~~~~~~~~~
| compilation terminated.
| make[2]: *** [CMakeFiles/uds-server.dir/build.make:264: CMakeFiles/uds-server.dir/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_ClearDiagInfo/ISOUDS_ClearDiagInfo_Cfg.c.o] Error 1
| In file included from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Inc/typedefs.h:29,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/DOIP/DOIP.h:32,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_MAIN/ISOUDS_Server_Cfg.h:30,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_CntrlDTCSetting/ISOUDS_CntrlDTCSetting.c:13:
| /home/myname/project/nxp_s32/build_s32g274asbc2/tmp/work/aarch64-ms-linux/embitel-uds/1.0.0-r0/recipe-sysroot-native/usr/lib/aarch64-ms-linux/gcc/aarch64-ms-linux/10.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
| 9 | # include_next <stdint.h>
| | ^~~~~~~~~~
However, stdint.h does exist. I looked up what "include_next" is and it's a "wrapper header". I think GCC is using this to modify the headers for the target environment, i.e. this is a cross-compiler issue. I assume this would indicate that cmake is not configured correctly for cross-compilation, or not looking in the correct location for the modified headers.
I have never encountered this problem building other source code for the same target environment using the same cross-compiler. My .bb recipe is also written using the same variables as for other packages. I even compared the CMakeOutput.log and CMakeCache.txt for this failing recipe and other successful recipes and saw that most of the relevant variables were set with the same values.
This led me to believe this could be an issue with the CMakeLists.txt and not having configured cmake correctly for this particular source code.
I have tried adding -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 based on this thread.
I have also avoided directly setting the cross-compiler based on this.
However, I'm at a loss for what I could be missing.
Other issues I've referenced:
Referencing gcc with yocto recipe Makefile, unable to find stdint
Here are my CMakeLists for reference:
cmake_minimum_required(VERSION 3.13)
project("MyUDS"
VERSION "1.0.0"
LANGUAGES C)
include(GNUInstallDirs)
## --- C++ build flags ---
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_C_FLAGS "-MMD -MP -O4 -fcommon")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu11")
# Set version
set(PROJECT_VERSION_MAJOR 0 CACHE STRING "")
set(PROJECT_VERSION_MINOR 0 CACHE STRING "")
set(PROJECT_VERSION_PATCH 0 CACHE STRING "")
set(PROJECT_VERSION_BUILD 0 CACHE STRING "")
# changes binary and library outputs to ./build/bin and ./build/lib
# set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)
add_library(uds-server SHARED)
set_target_properties(uds-server PROPERTIES
VERSION ${PROJECT_VERSION}
SOVERSION ${PROJECT_VERSION_MAJOR})
add_subdirectory(src/3rdparty/udsdoip)
----- CMakeLists in src/3rdparty/udsdoip ------
file(GLOB_RECURSE sched_sources ${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Sched/*.c)
add_executable(udsserver ${sched_sources})
target_link_libraries(udsserver uds-server pthread)
target_include_directories(
udsserver
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Inc
${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Sched/Inc
...
${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Src/Inc
)
add_subdirectory(UDSSrvonDOIP/DoIPSrvProcess)
install(TARGETS udsserver DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/service/uds_server.sh DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/service/uds_server.service
DESTINATION /etc/systemd/system
)
----- CMakeLists in UDSSrvonDOIP/DoIPSrvProcess ------
project(lib-uds-server)
# Enable helper debugging messages
target_compile_definitions(
uds-server PUBLIC DEBUG_SOCKCOMM DOIP_SERVER_PRINT_TCP_RX_PACKET_DATA DOIP_SERVER_PRINT_FOUND_NET_DEVS
)
file(GLOB_RECURSE isouds_sources RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.c)
target_sources(uds-server PRIVATE ${isouds_sources})
target_include_directories(
uds-server
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/Inc
${CMAKE_CURRENT_SOURCE_DIR}/Sched
${CMAKE_CURRENT_SOURCE_DIR}/Sched/Inc
...
${CMAKE_CURRENT_SOURCE_DIR}/Src/ISOUDS/ISOUDSSecurDtaTrans
)
install(TARGETS uds-server
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

Found the issue, and it's a bit of a dumb mistake.
I was not inheriting the CMake C flags set by Yocto that are needed for the cross-compile environment. So no matter what flags I added in my .bb recipe file, they were being overridden in the source code CMakeLists.txt.
Here, where I was setting the C flags, I was not inheriting Yocto's flags.
set(CMAKE_C_FLAGS "-MMD -MP -O4 -fcommon")
I should have used the existing flags and appended the ones specific to my source code like this:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -MMD -MP -O4 -fcommon")
This got my build working.

Related

Yocto Space Profiling Using KSize

I have a Yocto build that I am trying to shrink. I have removed a lot of unnecessary code by building core-image-full-cmdline. The Yocto mega manual mentions that to strip the size of your kernel you can use the ksize.py script in the project build directory. When I run this script I get an output of all 0s. This cannot be correct as I have a working SD card image with a booting kernel.
As I remember, you need to execute the script in the kernel folder. The script scan the current folder.
cd /path/to/kernel
python /path/to/ksize.py
(use python2 or 3 depending the current Yocto branch)
#PierreOlivier is right, you need to run this specifically from the kernel build directory (not the kernel source directory), in my case it is:
$ cd tmp/work/qemuarm64-poky-linux/linux-yocto/5.15.14+gitAUTOINC+72e4eafb6b_f77b2ba7d5-r0/linux-qemuarm64-standard-build
$ ../../../../../../../scripts/tiny/ksize.py
Linux Kernel total | text data bss
--------------------------------------------------------------------------------
vmlinux 20936031 | 15461191 4784912 689928
--------------------------------------------------------------------------------
fs/built-in.a 4548119 | 3862922 640608 44589
drivers/built-in.a 3991696 | 3591409 339384 60903
kernel/built-in.a 3104792 | 2078218 834883 191691
net/built-in.a 3083322 | 2731018 305491 46813
Additionally I recommend you try setting either:
DISTRO="poky-tiny"
or
PREFERRED_PROVIDER_linux-yocto = "linux-yocto-tiny"
Which would build a smaller kernel and/or rootfs as reference (assuming you are using linux-yocto and poky), you may set this on your local.conf

Yocto rust recipe also produces -native output that needs packaging

I tried this approach on hardknott but I couldn't get it to work recipe also produces -native output that needs packaging
It is a rust recipe that generates an x86_64 app which I would like to package the right way in sdk, so that it can be used.
I can separate the main package to -native-bin, and I see it in the recipe-sysroot, but I can't get it to populate the recipe-sysroot of the workdir of the file when building the -native-helper recipe. And I suspect the reason is that I get an error that the main recipe for x86_64 can't be found?
ERROR: Manifest xxxxxx.populate_sysroot not found in vs_imx8mp cortexa53 armv8a-crc armv8a aarch64 allarch x86_64_x86_64-nativesdk (variant '')?
So any helpful information would be appreciated!
Hacked like this:
Recipe.bb:
do_install_append() {
# Set permision without run flag so that it doesn't fail on checks
chmod 644 ${D}/usr/bin/#RECIPE#-compiler
}
# #RECIPE# generates a compiler during the target generation step
#separate this to the -native-bin package, and skip the ARCH checks
#also in the image file for stations_sdk move the app to right dir and add execute flag
PACKAGES_prepend = "${PN}-native-bin "
PROVIDES_prepend = "${PN}-native-bin "
INSANE_SKIP_${PN}-native-bin = "arch"
FILES_${PN}-native-bin = "/usr/bin/#RECIPE#-compiler"
SYSROOT_DIRS += "/"
Image.bb:
# #RECIPE# produces a compiler that is produced as a part of the target generation
#so we use the recipe and hack it to supply the -compiler as part of the
#host binaries
TOOLCHAIN_TARGET_TASK_append = " #RECIPE#-native-bin"
do_fix_#RECIPE#() {
mv ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/usr/bin/#RECIPE#-compiler ${SDK_OUTPUT}/${SDKPATHNATIVE}/usr/bin/#RECIPE#-compiler
chmod 755 ${SDK_OUTPUT}/${SDKPATHNATIVE}/usr/bin/#RECIPE#-compiler
}
SDK_POSTPROCESS_COMMAND_prepend = "do_fix_#RECIPE#; "
This produces at the end the binary in the right directory

Error with static compilation Qt with postgresql driver

I have installed through Mainteinance Tool Qt 5.12.5 and the sources. I have the next directories:
C:\Qt\5.12.5\Src
C:\Qt\Tools\mingw730_32\
C:\Qt\Tools\mingw730_64\
On the other hand, I have read that downloable Postgres version is compiled with MSVC, and I must to compile my own version. I have do it following link, and now I have a postgresql version in c:\pgsql
Finally I have added c:\pgsql to user Path
Next step, I have opened PowerShell in Admin mode and I´ve gone to C:\Qt\5.12.5\Src\.
Next, set the env path for this PowerShell session:
$env:Path += ";C:\Qt\Tools\mingw730_64\bin\;C:\Qt\5.12.5\Src;C:\pgsql\include\;C:\pgsql\lib\;C:\pgsql\bin\" (setting the pgsql path again....)
After that, I execute configure.bat like that:
configure -v -static -release -static-runtime -platform win32-g++ -prefix C:\Qt\5.12.5\Estatico\ -opensource -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -qt-freetype -opengl desktop -no-openssl -opensource -confirm-license -skip webengine -make libs -nomake tools -nomake examples -nomake tests -sql-psql
But I have get this error:
ERROR: Feature 'sql-psql' was enabled, but the pre-condition 'libs.psql' failed.
Searching in config.log I can read those lines:
loaded result for library config.qtbase_sqldrivers.libraries.psql
Trying source 0 (type pkgConfig) of library psql ...
pkg-config use disabled globally.
=> source produced no result.
Trying source 1 (type psqlConfig) of library psql ...
pg_config not found.
=> source produced no result.
Trying source 2 (type psqlEnv) of library psql ...
None of [liblibpq.dll.a liblibpq.a libpq.dll.a libpq.a libpq.lib] found in [] and global paths.
=> source produced no result.
Trying source 3 (type psqlEnv) of library psql ...
=> source failed condition '!config.win32'.
test config.qtbase_sqldrivers.libraries.psql FAILED
What can I do or what is the properly way to do that?
Thank you in advance.
UPDATE
There are similar question here but it hasn´t been solved, and those question ask about Visual Studio.
I want to compile it under mingw.
The solution suggested by #Soheil Armin doesn´t work too
The solution suggested by #Soheil Armin works fine, but I need to delete the entire source tree and reinstall it as he suggested. If not, a new configure won't work.
Also, the ^ character can be saved:
configure <your parameters>
PSQL_LIBS="C:\pgsql\lib\libpq.a"
-I "C:\pgsql\include"
-L "C:\pgsql\lib"
You need to explicitly define library paths of Postgres.
configure <your parameters> ^
PSQL_LIBS="C:\pgsql\lib\libpq.a" ^
-I "C:\pgsql\include" ^
-L "C:\pgsql\lib"

How can I get "HelloWorld - BitBake Style" working on a newer version of Yocto?

In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !

OpenDDS Perl Script Setup Throwing Error

Continuing from this SO question.
When following the openDDS install guide I attempt to run configure from within the command prompt but receive this output recieve this error set:
C:\Users\Supervisor\Desktop\opendds>C:\Users\Supervisor\Desktop\opendds\configure.cmd
Options:
'compiler' => 'gcc'
'verbose' => 1
host system is: win32
compiler is: gcc
Using ace_src: C:/Users/Supervisor/Desktop/opendds/ACE_wrappers
Using tao_src: C:/Users/Supervisor/Desktop/opendds/ACE_wrappers/TAO
ACE_ROOT/ace/config.h exists, skipping configuration of ACE+TAO
ENV: saving current environment
ENV: Appending ;C:\Users\Supervisor\Desktop\opendds\ACE_wrappers\bin;C:\Users\Supervisor\Desktop\opendds\bin;C:\Users\Supervisor\Desktop\opend
ds\ACE_wrappers\lib;C:\Users\Supervisor\Desktop\opendds\lib to PATH
ENV: Setting ACE_ROOT to C:\Users\Supervisor\Desktop\opendds\ACE_wrappers
ENV: Setting MPC_ROOT to C:\Users\Supervisor\Desktop\opendds\ACE_wrappers\MPC
ENV: Setting CIAO_ROOT to unused
ENV: Setting TAO_ROOT to C:\Users\Supervisor\Desktop\opendds\ACE_wrappers\TAO
ENV: Setting DDS_ROOT to C:\Users\Supervisor\Desktop\opendds
ENV: Setting DANCE_ROOT to unused
Use of uninitialized value $mpctype in concatenation (.) or string at configure line 1028.
OpenDDS mwc command line: -type C:\Users\Supervisor\Desktop\opendds\DDS_TAOv2_all.mwc
Use of uninitialized value $mpctype in string eq at configure line 1031.
Running MPC to generate project files.
MPC_ROOT was set to C:\Users\Supervisor\Desktop\opendds\ACE_wrappers\MPC.
Using .../opendds/ACE_wrappers/bin/MakeProjectCreator/config/MPC.cfg
ERROR: Invalid type: C:\Users\Supervisor\Desktop\opendds\DDS_TAOv2_all.mwc
mwc.pl v4.1.8
Usage: mwc.pl [-global <file>] [-include <directory>] [-recurse]
[-ti <dll | lib | dll_exe | lib_exe>:<file>] [-hierarchy]
[-template <file>] [-relative NAME=VAL] [-base <project>]
[-noreldefs] [-notoplevel] [-static] [-genins] [-use_env]
[-value_template <NAME+=VAL | NAME=VAL | NAME-=VAL>]
[-value_project <NAME+=VAL | NAME=VAL | NAME-=VAL>]
[-make_coexistence] [-feature_file <file name>] [-gendot]
[-expand_vars] [-features <feature definitions>]
[-exclude <directories>] [-name_modifier <pattern>]
[-apply_project] [-version] [-into <directory>]
[-gfeature_file <file name>] [-nocomments]
[-relative_file <file name>] [-for_eclipse]
[-workers <#>] [-workers_dir <dir> | -workers_port <#>]
[-language <cplusplus | csharp | java | vb>]
[-type <automake | bcb2007 | bcb2009 | bds4 | bmake | cc | cdt6 |
cdt7 | em3 | ghs | gnuace | gnuautobuild | html | make |
nmake | rpmspec | sle | vc6 | vc7 | vc8 | vc10 | vc11 |
vc12 | vc14 | vc71 | vc9 | vxtest | wb26 | wb30 | wix>]
[files]
-base Add <project> as a base project to each generated
project file. Do not provide a file extension, the
.mpb extension will be tried first; if that fails the
.mpc extension will be tried.
-exclude Use this option to exclude directories or files when
searching for input files.
-expand_vars Perform direct expansion, instead of performing relative
replacement with either -use_env or -relative options.
-feature_file Specifies the feature file to read before processing.
The default feature file is default.features under the
config directory.
-features Specifies the feature list to set before processing.
-for_eclipse Generate files for use with eclipse. This is only
useful for make based project types.
-gendot Generate .dot files for use with Graphviz.
-genins Generate .ins files for use with prj_install.pl.
-gfeature_file Specifies the global feature file. The
default value is global.features under the
config directory.
-global Specifies the global input file. Values stored
within this file are applied to all projects.
-hierarchy Generate a workspace in a hierarchical fashion.
-include Specifies a directory to search when looking for base
projects, template input files and templates. This
option can be used multiple times to add directories.
-into Place all output files in a mirrored directory
structure starting at <directory>. This should be a
full path. If any project within the workspace is
referenced via a full path, use of this option is
likely to cause problems.
-language Specify the language preference; possible values are
[cplusplus, csharp, java, vb]. The default is
cplusplus.
-make_coexistence If multiple 'make' based project types are
generated, they will be named such that they can coexist.
-name_modifier Modify output names. The pattern passed to this
parameter will have the '*' portion replaced with the
actual output name. Ex. *_Static
-apply_project When used in conjunction with -name_modifier, it applies
the name modifier to the project name also.
-nocomments Do not place comments in the generated files.
-noreldefs Do not try to generate default relative definitions.
-notoplevel Do not generate the top level target file. Files
are still processed, but no top level file is created.
-recurse Recurse from the current directory and generate from
all found input files.
-relative Any $() variable in an mpc file that is matched to NAME
is replaced by VAL only if VAL can be made into a
relative path based on the current working directory.
This option can be used multiple times to add multiple
variables.
-relative_file Specifies the relative file to read before processing.
The default relative file is default.rel under the
config directory.
-static Specifies that only static projects will be generated.
By default, only dynamic projects are generated.
-template Specifies the template name (with no extension).
-workers Specifies number of child processes to use to generate
projects.
-workers_dir The directory for storing temporary output files
from the child processes. The default is '/tmp/mpc'
If neither -workers_dir nor -workers_port is used,
-workers_dir is assumed.
-workers_port The port number for the parent listener. If neither
-workers_dir nor -workers_port is used, -workers_dir
is assumed.
-ti Specifies the template input file (with no extension)
for the specific type (ex. -ti dll_exe:vc8exe).
-type Specifies the type of project file to generate. This
option can be used multiple times to generate multiple
types. There is no longer a default.
-use_env Use environment variables for all uses of $() instead
of the relative replacement values.
-value_project This option allows modification of a project variable
assignment. Use += to add VAL to the NAME's value.
Use -= to subtract and = to override the value.
This can be used to introduce new name value pairs to
a project. However, it must be a valid project
assignment.
-value_template This option allows modification of a template input
name value pair. Use += to add VAL to the NAME's
value. Use -= to subtract and = to override the value.
-version Print the MPC version and exit.
Error from MPC, stopped at configure line 1035.
The cmd script being run is:
#echo off
:: Win32 configure script wrapper for OpenDDS
:: Distributed under the OpenDDS License.
:: See: http://www.opendds.org/license.html
for %%x in (perl.exe) do set PERLPATH=%%~dp$PATH:x
if x%PERLPATH%==x (
echo ERROR: perl.exe was not found. This script requires ActiveState Perl.
exit /b 1
)
set PERLPATH=
perl configure -verbose --compiler=gcc %*
if exist setenv.cmd call setenv.cmd
And the section of configure that generates the error is:
my $mwcargs = "-type $mpctype $buildEnv->{'DDS_ROOT'}$slash$ws $static";
$mwcargs .= ' ' . $opts{'mpcopts'} if defined $opts{'mpcopts'};
print "OpenDDS mwc command line: $mwcargs\n" if $opts{'verbose'};
print 'Running MPC to generate ', ($mpctype eq 'gnuace' ? 'makefiles' :
'project files'), ".\n";
if (!$opts{'dry-run'}) {
if (system("perl $ENV{'ACE_ROOT'}/bin/mwc.pl $mwcargs") != 0) {
die "Error from MPC, stopped";
}
}
Where initial unset variable is set:
my $mpctype = ($slash eq '/') ? 'gnuace' : $opts{'compiler_version'};
I have both perl and visual studio installed. Looking up MPC I can find a 'multi-precision library. Could this be because I am using gcc? I have to use GCC in order to create a library to use with the JNI out of this code eventually...
You need to make sure that you are using ActiveState perl on windows, other perl variants seem not to work 100%