Rick Bolen (GM) wrote:
> Gustin Johnson wrote:
>>> linux-libc-dev and libc6-dev are fighting over installing
>> I have build-essential installed on a number of Debian and Ubuntu
>> machines as well as my 64Studio machine. No problems with any of them.
>> My first guess is that there is a 3rd party repository or package that
>> is causing you some grief.
>> You can try to force the install by manually installing the .deb:
>> sudo dpkg -i --force-all
> I did this for libc6-dev and linux-libc* and this ended the log jam.
>>> I typically follow the "building-a-kernel-the-debian-way" articles, but
>>> they only add a few other packages. I just don't know if build-essential
>>> will straighten-outadd required symlinks etc.
>> "kernel-package" is the easiest way to build a kernel (or a header or
>> source) .deb.
> kernel-package in now installed, and linux-source-2.6.29,
> build-essential, et al.
> 1) Do I need apply the patches that came with linux-source, or they
> "pre-applied" and there only if needing to "unroll"?
> 2) What ".config" file do I use to build the stock 64Studio rt-kernel?
Just copy the /boot/config-[snip] for the default kernel to the
directory were you compile the new kernel.
If you build another kernel version you should run "$ make oldconfig"
after doing the copy, this is an easy way to configure a new kernel with
a configuration, that is outdated, because of new functions. If you only
want to compile the default kernel, you only need to copy the
configuration from /boot, you don't need to change any thing. If you
like to change something, e.g. to optimize to your CPU, you need to run
"$ make menuconfig".
As an example take a look at
> 3) How do I stop make-kpkg from asking me all those ".config" questions?
> My strategy to address this original problem is to build a new kernel
> (and header files) per the recommendation here:
Okay, there seems to be a problem because of the used assembler or any
configuration for this assembler.
Yesterday I wrote "Resp. to build a kernel the needed packages might be:
bin86 build-essential bzip2 fakeroot gcc kernel-package make
"bin86" is the used assembler.
I installed the headers for the latest kernel I build for my 64 Studio
root@64studio:/usr/src/kernel_packages# dpkg -i
root@64studio:/usr/src/linux-headers-184.108.40.206-rt19/include# ls -l
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 acpi
lrwxrwxrwx 1 root root 10 2010-01-05 13:32 asm -> asm-x86_64
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 asm-generic
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 asm-x86
drwxr-xr-x 472 root root 28672 2010-01-05 13:32 config
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 crypto
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 drm
-rw-r--r-- 1 root root 253 2009-11-10 01:32 Kbuild
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 keys
drwxr-xr-x 34 root root 40960 2010-01-05 13:32 linux
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 math-emu
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 media
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 mtd
drwxr-xr-x 13 root root 4096 2010-01-05 13:32 net
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 pcmcia
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 rdma
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 rxrpc
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 scsi
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 sound
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 trace
drwxr-xr-x 2 root root 4096 2010-01-05 13:32 video
drwxr-xr-x 3 root root 4096 2010-01-05 13:32 xen
That's funny, indeed asm -> asm-x86_64 is a dead link for the amd64
version of 64 Studio. It might be, that deleting asm will force the
makefile to use the path to asm-generic or asm-x86 instead, or whatever
this looks for your 32bit version of 64 Studio 3.0-beta3.
root@64studio:/usr/src/linux-headers-220.127.116.11-rt19/include# dpkg -r
I don't need the headers
> Basically they get around this Makefile_32.cpu bug by generating new
> headers from source. If this works, then it seems the 64Studio distro
> could do it and replace the current header file downloads with corrected
> I could go the patch route, but I don't understand how to apply the
> patch. Do I,
> 1) cut and paste text sections out of the bug listing and save them to
> xxx.patch files or something?
Yes, correct, e.g. by giving it the name "patch_name".
> 2) Is there more than one patch (separated by the ######## line)?
It will change different files, see the diff lines, but you can copy it
to one textfile and run it as one patch, you also can keep the
"#####"-signs. There might be one problem, sometimes text gets wrapped
on websides and emails by an automatic word wrap. Try to run it as it is
posted in the original bug-report and if needed try to understand error
messages and remove line breaks.
> The suggestion is to:
> $ cd /usr/share/kernel-package/ruleset/arches
> $ sudo patch -p0 < patch_name
> $ sudo patch -p1 < patch_name
> I dont have a "/usr/share/kernel-package/ruleset/arches" dir... and I
> don't know what "patch_name" refers to.
The path: For my 64 Studio it's provided by the package "kernel-package"
version 11.001 (hardy)
Because of "patch_name" see above, it's a dummy, a wildcard for any name
you like to give the patch.
> ANy advice?
64studio-users mailing list