I have a 64-bit 3.9 kernel. Actually I applied a patch and rebuilt the entire kernel on a different (32-bit) Ubuntu machine then I brought the *.deb files over and used the "dpkg -i" procedure to install the patched up kernel to my Ubuntu 12.04. It's a minor patch, doesn't change much and everything works except...
I did a "apt-get install module-assistant build-essentials linux-headers-$(uname -r)". I can see the usr/include/src/linux-headers-3.9.0-custom. It's all there.
My Makefile says
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
But I inevitably get:
usr/include/src/linux-headers-3.9.0-custom/scripts/recordmcount: 1: usr/include/src/linux-headers-3.9.0-custom/scripts/recordmcount: Syntax error: word unexpected (expecting ")")
when I try to do the build. This same source code builds sucessfully when I attempt it on my Ubuntu 32-bit 3.2 Kernel system.
This was an issue of cross-compiling. I used a 32-bit Ubuntu system to build a 64-bit kernel and it's been nothing but headaches. Apparently the scripts etc still get built as 32-bit. (They'd have to since my 32-bit system needed to use them to build the kernel.) But then if bring that /usr/src/linux-headers-x.x.x dir over to my 64-bit system I can't use it to build any kernel modules because its /scripts dir is 32-bit.
I rebuilt recordmcount on the 64-bit machine and that worked. But then there was another script that was incompatible with 64-bits, that wasn't as easy to build without rebuilding the entire kernel.
Anyway, if you cross compile you don't get a /usr/src/linux-header-x.x.x/scripts dir that's usable on your target system.
Related
I've installed BuildRoot, to set a SoftetherVPN.
Well, my problem is that I necessary need to install GCC, in a 32-bit ARM Architecture, (obviously I've downloaded the 32 bit version).
I looked all over the internet, because of many problems:
My first idea was to install GCC using command sudo apt-get or sudo yum, but I can only find it in Debian Linux (Buildroot kernel, and its toolchain are very reduced).
At this point I tried to cross-compiling GCC but with no results, because it produced in shell output Library errors. And I also tried to paste those missing libraries yet achieve very little.
You could download some GCC cross-compiler. For example, if your PC is running some Debian-like Linux distribution -perhaps Ubuntu- you might install some gcc-7-arm-linux-gnueabi or similar (gcc-7-arm-linux-gnueabihf ...) package.
The SDK for your board is likely to provide some cross-GCC & cross-binutils.
You could build some cross binutils then some GCC cross-compiler from their source code (this is a bit more tricky).
Your cross-compiler would compile (for ARM) on your Linux-running PC, not on your ARM circuit board.
I currently try to build a Debian package for the armhf (ARMv7) architecture, but I want the build script to recognize the architecture itself. The problem is, that I can not find the architecture, that APT uses to retrieve the package from a repository.
In my case, APT uses armhf, when it retrieves packages.
When I run uname -m, I get armv7 as a result. A grep -rn armhf /etc does not show any appearance of armhf, relevant for APT to choose from.
So, where can I get (Debian 9 (Stretch) or Armbian next) a reliable source for that information from the system that is independent of the architecture (my script should run also on i686, amd64, armel & arm64)?
The answer is
dpkg --print-architecture
This gives you the architecture Debian is selecting for packages. I'm not sure what happens on multi-architecture systems (i686 and amd64), but this can be separated quite easily.
When I try to add it to sources as per debian install instructions I get this error. I'm guessing this means that there are no arm packages for it.
Failed to fetch https://dist.crystal-lang.org/apt/dists/crystal/InRelease Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file)
I'm guessing I probably need to install it from source. How would I go about doing that with an arm cpu? When I check it out and run make I get the error:
You need to have a crystal executable in your path! Makefile:113:
recipe for target '.build/crystal' failed make: *** [.build/crystal]
Error 1
Any suggestions would be greatly appreciated.
EDIT: There's now a semi-official repository for crystal on raspbian, check it out here: http://public.portalier.com/raspbian
Crystal doesn't build Debian packages for ARM, and you're correct in that you'll need to build from source.
However, the Crystal compiler is written in Crystal. This presents the obvious problem of how to get a compiler to build the compiler. The answer is cross-compilation: building an arm binary on a x86 desktop computer and copying it across.
Here's a quick step-by-step based on my memory of last time I cross-compiled:
Install Crystal on a x86 desktop PC, and check it works.
Install all required libraries on the desktop and Raspberry Pi. You'll need the same LLVM version on the Raspberry Pi and desktop. This is probably the hardest and longest step. You can install llvm 3.9 from debian testing for ARM, see this stackoverflow post for how to install only LLVM from debian testing.
Check out the sources from git on both computers, and run make deps.
Cross-compile the compiler by running this command in the root of the git repository:
./bin/crystal build src/compiler/crystal.cr --cross-compile --target arm-unknown-linux-gnueabihf --release -s -D without_openssl -D without_zlib
This command will create a crystal.o file in your current directory, and also output a linker command (cc crystal.o -o crystal ...).
Copy crystal.o to the raspberry pi, and run the linker command. Be sure to edit the absolute path to llvm_ext.o so that it points to the Crystal checkout on your Raspberry Pi, not the checkout on your desktop. Also make sure that all references to llvm-config in the command are for the correct LLVM version. For example, changing /usr/local/bin/llvm-config to llvm-config-3.9 on Raspbian.
Run the crystal executable in your current directory (./crystal -v) and make sure it works.
Ensure to set CRYSTAL_PATH environment variable is set to lib:/path/to/crystal/source/checkout/src so that the compiler can find the standard library when compiling applications.
I am trying to compile a small utility called tcpslice. It's the typical GNU C application. When I run ./configure, here is the output:
checking build system type... Invalid configuration `x86_64-pc-linux-gnuoldld': machine `x86_64-pc' not recognized
configure: error: /bin/sh ./config.sub x86_64-pc-linux-gnuoldld failed
It appears to not support compilation as a 64-bit Linux application. So I have a few questions:
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
I noticed a 64-bit RHEL6 machine on my network has this utility installed and running with an identical version number (1.2a3). Could I somehow download the source that was used to build it? I can get access the to RHN if necessary.
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Yes. -m32 is the option.
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
You will have to make some code changes to make a purely 32 bit application work on 64 bit. Here's a link that talks about porting code from 32 bit to 64 bit.
I am sorry, I do not know the answer for your 3rd question.
Hope the little information provided by me helps in some way.
You've misinterpreted what the configure script is telling you. The solution has nothing to do with CPU bitness.
The error comes down to a too-old version of config.guess, which the package creator generated with libtoolize. To fix it, you will need to have libtool installed, then say:
$ libtoolize --force
You'll find that configure now runs, because libtoolize overwrote the tarball version of config.guess with one appropriate to your system.
You may run into another problem, a "missing" bpf.h file. Just edit tcpslice.c and change this line:
#include <net/bpf.h>
to:
#include <pcap-bpf.h>
With those two changes, I got tcpslice to build on my 64-bit CentOS 5 box.
install following packages :
$apt-get install ia32-libs.
for rhel its different :
look at the answer to this question :
CentOS 64 bit bad ELF interpreter
I have applications which successfully compile with the -m32 switch (in DMD and/or GCC) to produce:
appname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.15, not stripped
The source packages I have created work fine, on both 32 bit and 64 bit Ubuntu to build the appropriate binary .debs.
I would like to produce the i386 .deb on the same 64 bit machine i use to produce the 64 bit .deb.
Is this possible, and where should I look for instructions?
The answer depends on the complexity of your build. When the normal 64 bit userland tools suffice for a build, simply specify the architecture via -a
debuild -ai386
However, there are often cases where this doesn't work, and in these cases you'll need pbuilder. pbuilder builds a clean Debian/Ubuntu system in a chroot-ed environment. man pbuilder is a good introduction. To get started, you'll need:
sudo pbuilder --create --architecture i386
sudo pbuilder --build mypackage.dsc
It starts with calling debuild with the -ai386 option, which will
change the architecture that the package is built for.
Of course you have to ensure that the package contains the i386 build of the application.
You don't do anything thing different from building a 64bit .deb. Except that you include a 32bit build of your application.
The control file specifies the architecture, so be sure you select the correct one.