I want to backport RT patch from 3.0 to 2.6.35 kernel. Using README file trying to understand how RT patches are organized at https://www.kernel.org/pub/linux/kernel/projects/rt/3.0/. Can you help on the following.
I could see different -rt numbers for different kernel versions in older directotry.
Ex: patch-3.0.3-rt12.patch.bz2, patch-3.0.4-rt13.patch.bz2 ----> my doubht here is (a)rt changes for 3.0.3 is rt12 and the same rt changes for 3.0.4 kernel is rt13 or (b)while the kernel is changing from 3.0.3 to 3.0.4 the rt changes added from rt2 to rt3 without depending on the kernel changes).
In the incr directory I could see rt numbers are changing for the same kernel version.
Ex: patch-3.0.4-rt13-rt14.patch.bz2, patch-3.0.4-rt14-rt15.patch.bz2, patch-3.0.6-rt16-rt17.patch.bz2, patch-3.0.6-rt17-rt18.patch.bz2 ----> what exactly it means.
I could see following content in README for incr directory, can you help to understand?
The incr directory contains patches that will move you from one
version to the next.(here one version to next means rt version or
kernel version?)
It only includes patches moving between stable releases. (i.e 3.0.4, >3.0.6 ....)
The changes between vanilla Linux stable releases will not have an incremental patch.(not sure what it is?)
As per my understanding the kernel release follows as 3.0.rc1, 3.0.rc2,......,3.0.rcn and after all bug fixes it will be released as 3.0 . But I couldn't see any rt patch for 3.0 kernel in the top directory, only patch-3.0.101-rt130.patch.bz2 patch is available.
Related
I have updated a meta-layer for an application based on RPI3B to Yocto sumo release. The reason why I am using now RPI3B+ (instead of RPI3B).
When doing so, I run into a problem that Boost library 1.66.0 (in sumo) is not compatible with the one i used in previous build 1.64.0.
Is there a way to force Yocto in my configuration to start using boost 1.64.0 instead of the 1.66.0 ?
Yocto allows to choose preferred version of recipe with using - PREFERRED_VERSION, add into config file line:
PREFERRED_VERSION_boost = "1.64.0"
Proof:
$ bitbake -s | grep -e Preferred -e ^boost\\s
Recipe Name Latest Version Preferred Version
boost :1.67.0-r0 :1.64.0-r0
I am trying to modernize my module's C++ source code using clang-tidy. A few weeks ago, I downloaded and built clang and clang tools version 3.9 and when I ran it on one of my cpp files I got clang-analyzer-alpha.unix.PthreadLock saying that lock has already been taken.
Later, because of space constraints I removed that version of clang and used version 3.8 and 4.0 available in our 3rd party repos.
In both of these versions, I did not get any warnings regarding this alpha check. How do I enable it in version 4.0 ?
I am already using -checks=* while analyzing/running clang-tidy on my cpp file.
It looks like there's no way to enable those checks without building clang-tidy yourself: https://reviews.llvm.org/D28729#646548.
I want to update the distribution version of glibc and in order to keep the distribution settings, paths, ... I need the original used configure command line options.
Running gcc -v displays under Configured with: the configure command line options.
Is there something similar for glibc?
Unlike GCC, GLIBC doesn't record its configure options anywhere, so the direct answer is no.
However, if you download the source package for your current version of glibc and build it (precise commands vary between distributions), then you'll know how your current version has been configured.
P.S. Upgrading GLIBC incorrectly is one of the easiest ways to render your system unbootable. Make sure you have a suitable system recovery disk, and know how to use it before attempting this upgrade.
I'm trying to get SVN + Apache going on Windows 7 x64 but apparently I need 64-bit versions of mod_dav_svn.so and mod_dav_auth.so.
Are these available somewhere? I'm very much trying to avoid building them myself.
Spec:
SlikSVN x64
SVN 1.7.4
Apache 2.2
Some background
The reason I say "apparently I need these" is from this log error:
httpd.exe: Syntax error on line 492 of foo/httpd.conf: Cannot load
foo/modules/mod_dav_svn.so into server: The specified module could not
be found.
If I use a SVN binary for an x86 architecture, the error is the same, but the last sentence reads
The specified procedure could not be found
which indicates an architecture problem, I think. Can someone help out?
OK, actually these modules were not the cause of the problem. As detailed here, the message is misleading and there are actually dependencies missing from those two files.
Over the last 24 hours, I read somewhere that after Subversion 1.5, the program uses DLLs. Unfortunately, most of the directions out there are not yet updated to reflect this, so here's what I did, just for the next guy.
Download and install a x64 Apache build from ApacheHaus
Download a Subversion mod build from the same place
Grab mod_dav_svn and mod_dav_auth from /modules in the Subversion mod, put into /modules in the Apache
Grab all the DLLs from Haus mod /bin and put into the Apache /bin
(Re)start and cross fingers.
Apparently, to help with this sort of problem, DependencyWalker is a good tool.
On to the next challenge!
Install x64 Subversion server:
CollabNet Subversion Edge 2.3.0 (for Windows 64 bit) or WANDisco UberSVN. Is it too hard to find?
So, I've just downloaded the LLVM Clang (2.6) binaries. Mac OS X 10.6 comes with Clang 1.0.Do you know how to integrate a later version of Clang with the Xcode 3.2.x IDE?
Just overwriting files seems a little bit risky.
First off – you're referring to clang 1.0 based on LLVM 2.6. There is no clang 2.6, only a clang 1.0 based on LLVM 2.6. The clang issued with LLVM 2.6 is the same as the one with Xcode 3.2. (see Wikipedia: "On October 23, 2009 Clang 1.0 was released along with LLVM 2.6 for the first time"; I also know this from personal experience).
Secondly – you can integrate any version of clang, even one you build from clang's SVN. To do so, I have a .xcconfig file (a plain text file with the .xcconfig suffix) with two settings included:
GCC_VERSION = com.apple.compilers.llvm.clang.1_0
CC = /Users/jpo/Development/oss/llvm/Debug/bin/clang
Then, I add the xcconfig file to my project (because it contains some other warnings I like to turn on, such as the ones Peter Hosey recommends). Then, in the bottom right of the build settings tab for my project I tell it to be 'Based on' the name of my xcconfig file.
This all works out great, because then you can just keep the files from clang SVN in a directory on your drive, and build it, and your Xcode projects will use always use your latest built version since it always will be at that path. Of course, building clang itself is a time-consuming process, but its still really, really, cool to be using bleeding-edge technology.
So, dont overwrite! Rename them to their respective version (e.g. clang-1.0), then create a symbolic link to the one you want. If something goes wrong, you can switch it to the original version.
/Developer/usr/bin .. in case you dont know where the bins are.