I'm cross-compiling kernel modules and some libraries on x86 for ppc.
Is it possible to create ld.so.cache and modules.dep on my host system?
P.S I'm using ELDK tools.
modules.dep should be generated when the modules are built. It's also a text file so is readable on either architecture.
I'm pretty sure it'd be hard to generate ld.so.cache on anything but the system target system. It's a binary file that built up given the specific libraries available on your rootfs and configuration in /etc/ld.so.conf.
depmod can run just fine against foreign architecture modules. Assuming you've built your kernel and deployed your modules (eg 3rd party modules) to your system-root:
/sbin/depmod -ae -F /path/to/System.map -b /path/to/system/root <kernel-version-name>
Haven't found a solution for ldconfig, yet.
Related
the last week I have been trying to set-up a compiler which can compile to netbsd with mips architecture.
I cannot find anything on the internet how to do this. All documents refer to compiling the kernel to the architecture but not programs.
How can this be so hard....
host is netbsd amd64 machine
Set the compiler appropriately. Point it at the version of gcc in your TOOLDIR. In this case, something like mips--netbsd-gcc. Definitely make sure TOOLDIR is on your path, so the driver can find the proper assembler, proper loader, and proper libraries.
Take a look at the Makefile in any of src/bin/* as an example, and read through the system mk include files referenced (in src/share/mk)
Generally speaking, the goal is to have a working cross-compiler and a filesystem root for the target, all installed on your development machine. The target root is needed since you need all sorts of libraries to build userland applications. Those libraries need to be compiled for the target, not for the host.
Assuming you build everything from source, it goes as follows:
Choose a prefix for the toolchain (say /opt/mips) and another prefix for the root filesystem of the target (say /opt/target). All of those are on your development machine, not on the target!
Configure, build and install the cross-compiler for your target. This goes into the toolchain prefix.
Configure, build and install the kernel for your target, into the target root prefix. This should install the necessary kernel development headers needed later. If you can install such headers without compiling the kernel, more power to you, of course.
Configure, build and install the C library (say glibc) for your target, into the target root.
Configure, build and install whatever other libraries your userland application needs - into the target root.
Finally, configure, build and install the userland application. Once installed into the target root, you can copy it over to the target into the same prefix (say /opt/target as suggested before).
Generally to install into a different prefix - one that overlaps stuff on your build host (like /usr) - you'd need to do some tricks to fool make install into seeing the target prefix instead of your own. A simple approach would be to have a chroot environment on your build host, where you can bind-mount the prefix (say /usr) read-only, with a writable (mount_union) overlay on top of it.
When you build stuff for the target, you need to pass proper arguments to configure, of course.
I compiled various Linux kernel from git repositories. There are times when I copied the kernel to other system and need the kernel header to compile external module.
I tried to run "make headers_install" but it only generated a include/ folder. When I tried to point external module to that folder, it complains it cannot find Makefile.
What is the proper way to package kernel-header for deployment?
Thanks.
Create kernel packages instead, that's "make deb-pkg" for dpkg based distros and "make rpm-pkg" for RPM based ones. These create multiple packages, one of those is a package usable for external modules building. That should be linux-headers-* for the Debian packages and a "devel" package for he RPM versions.
In some ways this is just an expansion of the previous answer. If you look at the file scripts/package/builddeb in the kernel sources you will find script code which selects the files needed for building external modules from a kernel build and puts them into /usr/src/linux-headers-$version. I can find that script code in my local kernel version by searching for the string "# Build kernel header package" in the builddeb file. If you want to do things by hand you could execute that script code manually.
I am trying to compile a driver that we have from source and I am working through the issues with a new target environment. One of the slightly disturbing things I see is the following warning:
WARNING: Symbol version dump /usr/src/linux-2.6.38/Module.symvers
is missing; modules will have no dependencies and modversions.
I spent a fair amount of time looking on the web and this is shown in output frequently when other questions are asked, but I didn't see any commentary about whether or not this is an issue.
In any case, how would I tell linux/ubuntu to generate Module.symvers?
Module.symvers is generated when the kernel itself is compiled and ought to be provided to the user as part of the kernel build environment package, however that may look on Ubuntu (possibly broken there?) Fedora and openSUSE for example ship one or more “kernel-devel” (and/or similarly-named) packages that ship this build environment and make the file reachable through /lib/modules/<version>/build/Module.symvers. When using a self-compiled kernel, substitue /lib/modules/version/build for the appropriate path to the build directory (where all the .o files are).
I am trying to cross-compile a Linux kernel for an ARM-target (Freescale i.Mx28) on a Windows host. I know that this approach is not the best one compared to using a Linux host, but unfortunately it's not up to me to decide that.
The restrictions are:
The kernel has to be the one provided by Freescale (L2.6.35_MX28_SDK_10.12)
It must be build using Sourcery Toolchain and CodeBench
The whole thing must be done on Windows
I got that far, that I worked around the missing case sensitivity on Windows so that I can extract the kernel sources using Cygwin. But now I got problems with the kernel Makefile. I think there are some issues with the Windows paths as I get the error message *** multiple target patterns. Stop., which comes from the : in paths and other errors concerning the dependency check when configuring:
HOSTCC scripts/basic/fixdep
/usr/bin/sh: scripts/basic/fixdep: cannot execute binary file
make[1]: *** [scripts/basic/fixdep] Error 126
make: *** [scripts_basic] Error 2
Is there a way to port the Makefile without having to rewrite it or is there another way to build the kernel without using the given Makefile? Can I use the sourcery toolchain or IDE to handle the Makefile?
Is there a way to build the kernel within the given restrictions?
To cross compile the kernel, you'll need two compilers: One that is able to build tools that run in your build environment, and one that can create executables for your target.
It seems like you aren't really cross compiling but you have just replaced your compiler. You are now building tools required for the build for ARM and try to run them on Windows.
You can specify which cross compiler to use:
make ARCH=arm CROSS_COMPILE=your-compiler-prefix- ...
You might also have a problem with the filesystem. The filesystem in Windows is case-insensitive and the Kernel build might create files where the case matters. To get support for a case-insensitive filesystem on Windows, you can have a look at Windows Services for UNIX.
Use another toolchain! CodeBench is NOT compatible with building Linux on Windows hosts, not matter what eye candy (lies) they put on their website about using CYGPATH, etc.
I have tried this myself for weeks, and the problem is that CodeBench accepts POSIX paths, but insists outputting Win32 paths that are hard, if not impossible, to control in the Linux Kernel Make procedures.
I'm not saying it is impossible; I'm sure it is possible. But it is not worth the time, no matter what your boss tells you. There are more problems to consider. Another problem is that the tools in the Linux sources ./scripts directory are not directly compatible with the Windows environment and thus, although they might compile they don't run as expected. They need to be patched!
The best chance you have, is by compiling your own cross-compiler with Cygwin. Or find one already cooked for you.
I'm trying to get something of an environment on a usb stick to develop C++ code in. I plan to use other computers, most of the time linux, to work on this from a command line using g++ and make.
The problem is I need to use some libraries, like Lua and OpenGL, which the computers don't have. I cannot add them to the normal directories, I do not have root on these computers. Most of the solutions I've found involve putting things in /usr/lib/ and the like, but I cannot do that. I've also attempted adding options like '-L/media//lib', which is where they are kept, and it didn't work. When compiling, I get the same errors I got when first switching to an OS with the libraries not installed.
Is there somewhere on the computer outside of /usr/ I can put them, or a way to make gcc 'see' them?
You need more than the libraries to be able to compile code utilizing those libraries. (I'm assuming Linux here, things might be slightly different on e.g. OSX,BSDs,Cygwin,Mingw..)
Libraries
For development you need these 3 things when your code uses a library:
The library header files, .h files
The library development files, libXXX.so or libXXX.a typically
The library runtime files , libXXX.so.Y where Y is a version number. These are not needed if you statically link in the library.
You seem to be missing the header files (?) Add them to your usb stick, say under /media/include
Development
Use (e.g.) the compiler flag -I/media/include when compiling source code to refer to a non-standard location of header files.
Use the compiler/linker flag -L/media/lib to refer to non-standard location of libraries.
You might be missing the first step.
Running
For dynamically linked libraries, the system will load those only from default locations, typically /lib/ , /usr/lib/
Learn the ldd tool to help debug this step.
You need to tell the system where to load additional libraries when you're running a program, here's 3 alternatives:
Systemwide: Edit /etc/ld.so.conf and add /media/libs there. Run ldconfig -a afterwards.
Local, to the current shell only. set the LD_LIBRARY_PATH environment variable to refer to /media/lib, run export LD_LIBRARY_PATH=/media/lib
Executable: Hardcode the non-standard library path in the executable. You add this to the linking step when creating your executable: -Wl,-rpath,/media/lib
Etc.
There could be other reasons things are not working out, if so,
show us the output of ls -l /media/libs , and where you put the library header files, the command line you use to compile/link, and the exact errors you get.
Missing the headers and/or development libraries (for dynamic libraries there is usually a symlink from a libXXX.so to a libXXX.so.Y , the linker needs the libXXX.so , it will not look directly at libXXX.so.Y)
using libraries not compatible with your current OS/architecture. (libraries compiled on one linux distro is often not compatible with another distro, or even another minor version of the same distro)
using an usb stick with a FAT32 filesystem, you'll get in trouble with symlinks..