I want to compile upstream kernel with my own .config file.
I copied this file to the root directory.
I run 'make oldconfig' but seems that no consideration on that file because the compiler ask me questions about the configuration and I want that all the configuration will take from the my .config file:
"Compile also drivers which will not load (COMPILE_TEST) [N/y/?] (NEW)"
The makefile (not compiler) is asking you those questions, because following options (as CONFIG_COMPILE_TEST) is not present in your .config file (since you moved your old config from older kernel to newer one). Thus, every new config option which is available in kernel, you need to set if you want it or not. If you don't want to use those new features, just in loop write n and enter. If you want to keep default value, just press enter until you check every new config option.
Related
To compile Linux kernel, I created a default .config file using make defconfig. Since I didn't want to browse thousands of options through a menu-driven interface (make menuconfig), I set CONFIG_KALLSYMS=n manually, and then triggered the build (make -j8). I noticed the build system overwrote my changes and set CONFIG_KALLSYMS=y again. I suspect there might be other options present in the configuration which rely on CONFIG_KALLSYMS. How can I create a consistent .config file without using any menu-driven interface?
It might be burdensome to browse thousands of options through a menu-driven interface (make menuconfig). When you only want to change a couple of options and don't remember where they are in the menu hierarchy, you can use search to find any specific option. Just press / (slash) and type the full or partial name of the option. The result of the search will show where the options are located in the menu hierarchy, and what are the dependencies. Save and exit after you are done with the changes, and you should have a consistent .config file.
After you create a .config using make defconfig, to change just a few config options after that "make menuconfig" is the best way to do this. It also tells you about the dependencies and doesn't allow you to make a change unless the dependencies are met.
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
I have not found it in:
~/.config/Trolltech
~/.qt
~/.config/Nokia
where I should search for it?
It will depend on your system where exactly to find it. You could try running locate qtrc. Note that the locations this is going to find aren't necessarily the ones where you should make changes -- on my system, I only have a system-wide qtrc in /etc. For local changes, you should add a new one in your home directory. Again the particular location within your home directory will depend on your installation (in particular whether you're using Qt3 or Qt4).
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.
I am short of disk space while trying to compare different releases of Android (each of them takes about 6-7G after building).
I thought there is an option for make (similar to make clean) that it will delete all the intermediate .obj files and leaves the target(s) alone. But I couldn't remember what it is; or is there an option like that?!
A makefile will do whatever it's written to do. The clean target is a convention for makefiles, not a feature of Make. A makefile need not have a clean rule; if there is a clean rule, and if it is written well it will clean out the files you wanted cleaned out, if it is written badly there's no limit to how badly it can mess things up.
If you are writing (or editing) a makefile, you can put in a rule for removing object files. If you are using a makefile written by someone else, either it has such a rule or it doesn't.
Maybe the .INTERMEDIATE directive will help. From the GNU Make documentation (10.4 Chains of Implicit Rules):
The second difference is that if make' _does_ create B in order to
update something else, it deletes B later on after it is no longer
needed. Therefore, an intermediate file which did not exist before
make' also does not exist after make'.make' reports the deletion
to you by printing a `rm -f' command showing which file it is
deleting.
Ordinarily, a file cannot be intermediate if it is mentioned in the
makefile as a target or prerequisite. However, you can explicitly
mark a file as intermediate by listing it as a prerequisite of the
special target `.INTERMEDIATE'. This takes effect even if the file is
mentioned explicitly in some other way.