I have been working on a custom patch for my car with MIB2 unit for some time and would like to try my modified MIBRoot file.
The command I used to repack everything is:
mkxfs -t ifs -nn -o ./ -r / ./mkifs_attributes.txt ./ifs_extracted ./patched_ifs.ifs
But the problem is that the repackaging is not working properly, because the mkifs_attribute.txt file used is probably not fine for my MIB2 or I have a version that is not correct.
In fact, when I do a:
diff -r ./original/ifs_extracted ./repack/ifs_extracted
all files in ./repack/ifs_extracted are different from the originals, when instead only the MIBRoot file should be different.
my mkifs_attribute contain this:
#Porsche PCM4/MIB2 ifs-root (stage 2) attributes file
#Before packing FS: EXPORT QNX_TARGET="/"
#Command to pack: mkxfs -t ifs -nn -o ./ -r / attributes.txt /unpacked_fs /packed_fs.ifs
[-followlink] #Do not resolve links
[compress=2] #LZO Compression
[-bigendian] #Little Endian (ARMLE)
[-autolink] #Do not auto link shared objects
[perms=777] #chmod 777
[uid=0 gid=0] #chown root:root
#You can add a script to be executed after mount here, one line only
#[+script] .script = {
#touch /dev/shmem/AudioFadedIn; touch /dev/shmem/production_mode}
#Symlinks. Add lines here to match your dumpifs symlinks
#[type=link] dest_file=source_file
[type=link] /lib/SPC_configuration.so=/lib/libSPC_configuration.so
[type=link] /lib/AudioConfig_ARM.so=/lib/libAudioConfig_ARM.so
[type=link] /lib/AudioConfig_DSP.so=/lib/libAudioConfig_DSP.so
[type=link] /usr/bin/flashunlock=/usr/bin/flashlock
[type=link] /usr/bin/libi2c-inic-master.so=/lib/libi2c-inic-master.so.1.0
[type=link] /lib/librdshbfpga.so.1.0.0=/lib/librdshbfpga.so
[type=link] /lib/libSysMoCCAFrameworkSharedSo.so=/lib/libSysMoCCAFrameworkSharedSo.so.6
[type=link] /lib/AudioConfig_DSP.so=/lib/libAudioConfig_DSP.so
[type=link] /lib/liba2itodspipc.so=/lib/liba2itodspipc.so.1
Or am i wrong something?
If anyone has a correct mkxfs and mkxfs_attribute.txt could you please provide it to me so I can give it a try?
Related
I'm trying to use Make to ... make modular Dockerfiles. Long story short, I want to centralize certain elements and make the composable and reusable, like classes and functions really, but the Dockerfile syntax does not - and according to the developers, will not - offer any facilities in the image of C's #include or similar composability solutions. Not to worry, #include and friends to the rescue!
Except...
I have the following Makefile in my project:
BUILD_DIR := ${CI_PROJECT_DIR}/build
TEMPLATE_FILES := $(shell find ${CI_PROJECT_DIR} -name '*.build')
TEMPLATE_FILENAMES := $(foreach file,$(TEMPLATE_FILES),$(BUILD_DIR)/$(notdir $(file)).built)
BUILT_TEMPLATES := $(TEMPLATE_FILENAMES:.build.built=.built)
DOCKER_FILES := $(shell find ${CI_PROJECT_DIR} -name '*.Dockerfile')
DOCKER_OBJS := $(foreach file,$(DOCKER_FILES),$(BUILD_DIR)/$(notdir $(file)))
all: $(BUILT_TEMPLATES) $(DOCKER_OBJS)
$(BUILD_DIR)/%.built: $(TEMPLATE_FILES) $(BUILD_DIR) # build any templated Dockerfiles
cpp -E -P -o $(BUILD_DIR)/$(notdir $#) -I ${CI_PROJECT_DIR}/modules $<
sed -i 's/__NL__ /\n/g' $(BUILD_DIR)/$(notdir $#)
$(BUILD_DIR)/%.Dockerfile: $(DOCKER_FILES) $(BUILD_DIR)
cp $< $(BUILD_DIR)/$(notdir $(#))
$(BUILD_DIR):
mkdir -p $(BUILD_DIR)
.PHONY: clean
clean:
-rm -r $(BUILD_DIR)
The objective is to run the templated Dockerfiles through GCC to compile the #includes in them into proper Docker instructions, and just copy the rest of the files. Sounds simple enough.
Except that it looks like all the target files are "offset" from their sources - like the file names are correct, but the contents are from a file elsewhere in the list, and with no discernible order either.
One thing that I'm fairly sure is wrong - but even more wrong otherwise - is the line
$(BUILD_DIR)/%.built: $(TEMPLATE_FILES) $(BUILD_DIR) # build any templated Dockerfiles
By all manuals and documentation, it ought to be
$(BUILD_DIR)/%.built: %.build $(BUILD_DIR) # build any templated Dockerfiles
but that's even worse, because then Make just says make: *** No rule to make target '/docker/build/runner-dart-2-18-firebase.built', needed by 'all'. Stop.
I'm out of ideas here, along with my limited knowledge of Make. What am I missing to make Make make - sorry - my Dockerfiles?
This line:
$(BUILD_DIR)/%.built: $(TEMPLATE_FILES) $(BUILD_DIR)
Says that if make wants to build a target that matches that pattern, and it can find all the prerequisites, then the pattern rule matches and the recipe can be used. Let's ignore BUILD_DIR (note that it's always a bad idea to list a directory as a prerequisite, but that's not causing this problem). Suppose TEMPLATE_FILES is set to the value ./foo/foo.build ./bar/bar.build. Now the above rule expands to:
./build/%.built: ./foo/foo.build ./foo/bar.build ./build
What is the recipe?
cpp -E -P -o $(BUILD_DIR)/$(notdir $#) -I ${CI_PROJECT_DIR}/modules $<
First it's always wrong to create a file that is not exactly $# so you should use just $# not $(BUILD_DIR)/$(notdir $#). But more importantly, what will $< be set to? It is always set to the first prerequisite, and the first prerequisite is always ./foo/foo.build. So every time you run this recipe, regardless of which .built file you're trying to create, you will always be preprocessing the first .build file.
Your idea that you want this instead:
$(BUILD_DIR)/%.built: %.build $(BUILD_DIR)
is correct, in general. Why do you get the error? Because if you are trying to build the target ./build/foo.built, then the stem (part that matches %) is foo. Then make will look to see if the prerequisite foo.build exists or can be created, because you said the prerequisite is %.build. That file does NOT exist and CANNOT be created (make doesn't know how to create it), because the file is ./foo/foo.build not foo.build which is a totally different file.
You have three options. You can either write separate rules for each source directory:
$(BUILD_DIR)/%.built: foo/%.build
...
$(BUILD_DIR)/%.built: bar/%.build
...
Or, you can change your generated files so they are not all in the same directory but instead keep the source directory structure; you would change this:
TEMPLATE_FILENAMES := $(foreach file,$(TEMPLATE_FILES),$(BUILD_DIR)/$(notdir $(file)).built)
BUILT_TEMPLATES := $(TEMPLATE_FILENAMES:.build.built=.built)
to just this:
BUILT_TEMPLATES := $(patsubst %.build,$(BUILD_DIR)/%.built,$(TEMPLATE_FILES))
then create the output directory as part of the recipe:
#mkdir -p $(#D)
cpp -E -P -o $# -I ${CI_PROJECT_DIR}/modules $<
sed -i 's/__NL__ /\n/g' $#
Or finally, you could use VPATH to tell make what directories to look in to find the *.build files:
VPATH := $(sort $(dir $(TEMPLATE_FILES)))
(note, you should choose only one of these options).
I have a .tar.gz archive with the following structure:
opt/client/py/utils/mappings/templates/config.json
opt/
opt/mag/
opt/mag/sw/
opt/mag/sw/apps/
opt/mag/sw/apps/service/
opt/mag/etc/
opt/mag/etc/service.environment
opt/mag/etc/service.toml
And this .tar.gz archive is extracted using this command:
tar -zxf ../service.tar.gz -C opt/mag/ --strip-components=2
Thee issue is this will extract the opt/client/py/utils/mappings/templates/config.json file inside opt/mag so it will become: opt/mag/py/utils/mappings/templates/config.json which is obviously wrong. Notice the removal of opt/client/ by --strip-components=2.
The issue is that I cannot change the unzip command
I've tried to hack it around by inserting 2 dummy directories to bypass --strip-components=2 something like this:
dummy1/dummy2/opt/client/py/utils/mappings/templates/config.json
opt/
opt/mag/
opt/mag/sw/
opt/mag/sw/apps/
opt/mag/sw/apps/service/
opt/mag/etc/
opt/mag/etc/service.environment
opt/mag/etc/service.toml
This way --strip-components=2 will remove dummy1/dummy2 and the config file will be extracted to /opt/mag/opt/client/py/utils/mappings/templates/config.json which is still wrong, because that -C opt/mag will force the extraction inside opt/mag.
Given the fact that I cannot change the unzip command is there anyway to bypass the -C switch or some way to hack it around?
Also, I cannot edit or move files on the container where this archive is extracted
mkdir -p /tmp/build &&
cd /tmp/build &&
mkdir -p /tmp/src &&
echo "int main(){return 0;}" > /tmp/src/prog.c &&
gcc --coverage -o prog /tmp/src/prog.c &&
./prog &&
gcovr -v -r .
will output an empty report.
Scanning directory . for gcda/gcno files...
Found 2 files (and will process 1)
Processing file: /tmp/build/prog.gcda
Running gcov: 'gcov /tmp/build/prog.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /tmp/build' in '/tmp/build'
Finding source file corresponding to a gcov data file
currdir /tmp/build
gcov_fname #tmp#src#prog.c.gcov
[' -', ' 0', 'Source', '/tmp/src/prog.c\n']
source_fname /tmp/build/prog.gcda
root /tmp/build
fname /tmp/src/prog.c
Parsing coverage data for file /tmp/src/prog.c
Filtering coverage data for file /tmp/src/prog.c
Gathered coveraged data for 0 files
------------------------------------------------------------------------------
GCC Code Coverage Report
Directory: .
------------------------------------------------------------------------------
File Lines Exec Cover Missing
------------------------------------------------------------------------------
------------------------------------------------------------------------------
TOTAL 0 0 --%
------------------------------------------------------------------------------
However if I manually run
gcov /tmp/build/prog.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /tmp/build
I get correct results
File '/tmp/src/prog.c'
Lines executed:100.00% of 1
No branches
No calls
Creating '#tmp#src#prog.c.gcov'
It seems that gcovr did not extract the coverage from the otherwise correct gcov output. This only happens if the source file is outside the current directory (same as build directory, same as output directory, same as run directory), and gcc ics called with an absolute path to the source file.
How can I fix this?
Edit
Fixed in upstream gcovr for relative paths, but looks like a bug for absolute paths.
See https://github.com/gcovr/gcovr/issues/169.
What I understood from your code up there is that you made everything and ran the program but you are still inside build directory where the object file resides.
So, what you need to understand is:
gcovr -v -r <path>
this -r flag takes the root directory, which means the parent directory inside which the source and object directory resides. So that it can trace them both and generate coverage data and whatever else you want it to generate.
Try doing that and it will work.
For your understanding:
The .gcno files that gets generated after compilation is just the flowchart kind of data for that particular source file.
Then later when you execute the program, a .gcda file gets generated for each source file. This file contains real coverage data, but for gcovr all these three files are necessary (.gcno, .gcda, sourceFile)
Hope it helped. :)
update:
Back with the work around
You can supply your coverage data location as a pure arg (no option) and point the root to your sources.
gcovr .../path/To/GCDA -r .../path/to/src/ [rest desired flags]
This will solve your problem for sure.
Worked for me in covering my projects.
Gcovr only generates reports for source files within your project. This is intended to exclude coverage from library headers etc.
The question is, which files are in your project? This is determined by the -r root path.
If you are in /tmp/build and root is . aka /tmp/build and the source file is /tmp/src/prog.c, then that source file is clearly outside of your project. In the verbose output, gcovr will report Filtering coverage data for file /tmp/src/prog.c.
If you are in /tmp/build and root is .. aka /tmp and the source file is /tmp/src/prog.c, then that source file is within the project.
If you are in /tmp/build and root is . aka /tmp/build and the source file is ../src/prog.c, then gcovr seems to do something questionable: It joins the file name with the current directory and checks that. So we actually see /tmp/build/../src/prog.c. As far as gcovr is concerned, that's within your project. It seems this behaviour is necessary to include code that is symlinked into a project.
You can disable this “is the source within the project?” filter by providing your own, better filter. For example, you can ask gcovr to only report coverage for sources under /tmp/src:
gcovr -r . -f /tmp/src
I am trying to add an INSTALLS rule to my qmake .pro file that will create a symlink in the build directory to the config directory in my project. Here's how I've tried to do it using the 'extra' member:
config.path = $$top_builddir/
config.files = $$rootdir/config
config.extra = ln -sf $$config.files $$config.path
INSTALLS += config
where top_builddir and rootdir are of course the paths to the build directory and root project dir, respectively.
The generated Makefile rule is:
install_config: FORCE
#test -d $(INSTALL_ROOT)/home/greg/Desktop/mg_builds/MPI-Debug || mkdir -p $(INSTALL_ROOT)/home/greg/Desktop/mg_builds/MPI-Debug
ln -sf /home/greg/Desktop/mg/config /home/greg/Desktop/mg_builds/MPI-Debug/
-$(INSTALL_DIR) /home/greg/Desktop/mg/config $(INSTALL_ROOT)/home/greg/Desktop/mg_builds/MPI-Debug/
The extra command has been added but there is also the command to cp the directory too which is causing causing the error:
cp: '/home/greg/Desktop/mg/config' and '/home/greg/Desktop/mg_builds/MPI-Debug/config' are the same file
Makefile:580: recipe for target 'install_config' failed
How can I suppress this or tell qmake to make a symlink rather than a copy?
After a little experimenting I found this works quite nicely. You can leave the .files member empty (i.e. .files =) or just omit it entirely and no copy command will be generated in the Makefile. The target directory can be written directly in the extra command. However, a .path is still required for the rule to be generated.
config.path = $$top_builddir/
config.extra = ln -sf $$rootdir/config $$config.path
INSTALLS += config
Makefile:
install_config: FORCE
#test -d $(INSTALL_ROOT)/home/greg/Desktop/mg_builds/MPI-Debug/ || mkdir -p $(INSTALL_ROOT)/home/greg/Desktop/mg_builds/MPI-Debug/
ln -sf /home/greg/Desktop/mg/config /home/greg/Desktop/mg_builds/MPI-Debug/
Using the following command:
tar --exclude="./.*" -czvf /Volumes/Foo/2016-04-14_2051_full.tar.xz ./
Which follows this advice, still gets also hidden files archived:
a .
a ./.Trashes
a ./.fseventsd
a ./data
What can I do to only get the ./data folder archived?
Update: I use a Mac and zsh shell.
I now used the workaround:
XZ_OPT=-9e tar --exclude='./old' --exclude='.*' -cJvf /Volumes/Foo/$(date +%Y%m%dT%H%M)_full.tar.xz * -g incremetal
Hope it helps someone else as well