I know that ld.so belongs to glibc, and I want to modify the source code of it and build it alone. But building entire glibc is too much heavy, and the makefiles are so complicated that I just don't know where to start digging out. Any tips?
I want to modify the source code of it and build it alone
If you did ./configure; make in the source directory (i.e. you are not using a separate build directory), then:
make -C elf
will rebuild ld.so. If you build in a separate directory, e.g. in /tmp/build while your source is in $HOME/glibc-src, then:
cd /tmp/build; make -C $HOME/glibc-src/elf objdir=`pwd`
If you have a reasonably powerful machine, make -j16 ... may work even better.
Related
I am cross-compiling 3.4.0 kernel for an embedded device. Then I would like to install compat-wireless drivers which require /lib/modules/3.4/build directory and sub-files. Could anyone explain how can I build that directory so that when I do INSTALL_MOD_PATH=newmodules make modules_install it would load /lib/modules/$(uname -r)/build directory as well? I would appreciate for a clear explanation.
I am using debian distro. I know I can install the kernel headers by apt-get install linux-headers-$(uname -r), but I doubt it would be a good idea since the kernel sources might not be identical.
Typically /lib/modules/$(uname -r)/build is a soft-link to the directory where performed the build. So the way to do this is to simply do a
make modules_install INSTALL_MOD_PATH=/some/root/
in the build directory of the kernel where /some/root is where you want your cross compile pieces to end up. This will create a link to your kernel build path in /some/root/lib/modules/$(uname -r) ... verify that.
Now when you build the compat_wireless drivers specify the kernel build directory in the Makefile as /some/root using the KLIB_BUILD variable (read the Makefile)
make modules KLIB_BUILD=/some/root/lib/modules/$(uname -r)/build
this should do the trick for you.
EDIT A
In answer to your comment below:
Keep "newmodules" outside the kernel directory it's a bad idea to put it in the kernel directory. so mkdir newmodules somewhere like /home/foo or /tmp or something. This is one of the reasons your build link is screwed up
ALSO .../build is a soft link /to/kernel/build/location it will only copy over as a soft-link. You also need to copy over the actual kernel source / kernel build directory to your microSD, using the same relative location. For example,
Let's say your kernel source is in:
/usr/src/linux-3.5.0/
Your kernel build directory is:
/usr/src/linux-3.5.0-build/
Your newmodules (after following 1.) is in:
/tmp/newmodules/
So under /tmp/newmodules/ you see the modules installed in a tree like:
lib/modules/$(uname -r)/
when you do an ls -al in this directory, you'll see that build is a soft link to:
build -> /usr/src/linux-3.5.0-build/
Now let's say your microSD is mounted under /mnt/microSD
then you need to do the following
mkdir -p /mnt/microSD/usr/src
cp -a /usr/src/linux-3.5.0 /usr/src/linux-3.5.0-build /mnt/microSD/usr/src
cp -a /tmp/newmodules/lib /mnt/microSD/lib
Now you have all the content you need to bring over to your embedded environment. I take it you are doing the compat_wireless build on your target system rather than cross compiling it?
NOTE
If your kernel build is the same as the kernel source then just copy over the kernel source and ignore the linux-3.5.0-build in copy instructions above
This is old, but some people will need this information.
I have spent many hours to figure out where build folder comes from, and why it is just a link when I compile my own kernel. Finally figured it out;
Linux kernel usually just links the build and source folders to the source folder.
But!
Arch linux (probably some other distros too); has a manual script for deleting those links, and adding (filtered) files to build folder.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
I've extracted that script to work standalone (in a kernel source tree) here: https://gist.github.com/furkanmustafa/9e73feb64b0b18942047fd7b7e2fd53e
I'm trying to build a toolchain from scratch for ARM Integrator target machine. I started by building binutils and it is OK.
Now I have to generate kernel headers and I don't know how to do this in the right way.
Any help will be useful.
I searched a lot for this, in order to cross compile gcc.
This example involves the source of linux-3.9.
#cd to the top directory of the kernel source
cd linux-3.9
make mrproper
make ARCH=arm integrator_defconfig
make ARCH=arm headers_check
make ARCH=arm INSTALL_HDR_PATH=$SOMEWHERE headers_install
variable $SOMEWHERE is where you want it extracted.
What if you want something else than integrator? How to find out? Assuming your are still at the top directory of the kernel's source tree, here are the other _defconfig you could use:
ls /arch/arm/configs/*
Idem for other architectures.
Note: If you build a cross toolchain with newlib instead of glibc, you do not need kernel headers. Which library should you use? It depends of your needs. newlib is aimed at embedded solutions.
Sources:
http://pmc.polytechnique.fr/pagesperso/dc/arm-en.html
http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html
http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=2
I have a certain shared object library in a special directory which I
make sure special directory is in $LD_LIBRARY_PATH
make sure this directory has read and execute permisions for all
make sure appropriate library directory is in ld.so.conf and that root has done a ldconfig
(verify by checking for library using ldconfig -p as normaluser.
make sure it is has no soname problems (i.e. create a few symlinks if necessary)
Now, say I compile a program that needs that special library, a program packaged in a typical Open Source manner which ./configure && make, etc) and it says -lspecialibrary cannot be found, an error which a lack of any of the above checks would also probably throw.
A workaround I have done is to symlink the library to /usr/local/lib64 and suddenly the library has ben found. Also when compiling a relatively simple package, I manually add -L/path/to/spec/lib and that also has worked. But I regard those two methods as hacks, so I was looking for any clues as to why my list of checks aren't good enough to find a library.
(I particularly find the $LD_LIBRARY_PATH of shallow use. In fact I can exclude certain libraries from it, and they will still be found in a compilation process).
$LD_LIBRARY_PATH and ldconfig are only used to locate libraries when running programs that need libraries, i.e. they are used by the loader not the compiler. Your program depends on libspeciallibrary.so. When running your program $LD_LIBRARY_PATH and ldconfig are consulted to find libspeciallibary.so.
These methods are not used by your compiler to find libraries. For your compiler, the -L option is the right way to go. Since your package uses the autotools, you should set the $LDFLAGS environment variable:
LDFLAGS=-L/path/to/lib ./configure && make
This is also documented in the configure help:
./configure --help
I have a c++ project (g++/raw Makefile) designed for linux, I used to statically link everything which worked fine for ages. Now I want to build binaries both statically and dynamically linked. The following command is used in my Makefile to build the dynamic library (say libtest):
$(CXX) -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0.0 $(LIBTEST_OBJS)
The output is libtest.so.1.0.0 which has the so name libtest.so.1
I found at least a symbolic link libtest.so --> libtest.so.1.0.0 is required to link my client program that actually use the above generated libtest.so.1.0.0 library.
Here my question is if I want to build my software, what is the standard way of managing the above symbolic link? Clearly I don't want this extra stuff in my source directory, but it is required to build my client binary, shall I create it as a temp link for building the client then just remove it when done? or shall I create a directory to host the generate .so library and its links and leave everything there until I do "make install" to install them into other specified directories? Will be cool to now what is the standard way of doing this.
Or maybe the way how I generate libraries is incorrect? shall I just generate libtest.so (as actual library, not a link) to link my executable, then rename the library and create those links when doing ``make install''?
any input will be appreciated. :)
Certainly don't generate libtest.so as an actual link. Typically installing the shared library development files installs the .h files and creates a symbolic link libtest.so as part of some install script you have to write.
If you're not installing the development files, but only using the library in your build process of your binary, you just create the symbolik link from your makefile.
There's not that much of a standard here, some prefer to build artifacts to a separate build directory,
some don't care if it's built in the source directory. I'd build to a separate directory though, and keep the source directory clean of any .o/.so/executable files.
You might find useful information here
My suggestion is to use libtool which handles situations like this.
How can I store GNU make & configure files elsewhere? I have a project I am working on that I get compiled using:
./configure --prefix=/usr && make && su -c 'make install'
The thing is I don't want to pollute the current folder, which is a svn/git/hg/whatever sandbox with files generated by that command. I want to put those files in a separate location. I don't know if it's similar, but when I compile the linux kernel from source, I can specify where to put the ouput by passing the 'O' option to 'make', something like this:
make O=/home/user/linux-output
The Makefile must support this feature.
I think the autoconf generated makefiles all support the following use:
mkdir ../build
cd ../build
../configure --prefix=/usr
make
make install
(It's certainly recommended for gcc builds).
As Kristof already pointed out, GNU autotools inherently support out out-of-tree builds at the configure level.
So you can have the Makefile and built binaries out of the source tree trivially.
To get all the auto-generated artefacts out of the source tree requires much more work however.
We have a script that copies changes from a source tree into a working_copy, carefully preserving the configure script etc in the working_copy, which allows the original source tree to be pristine. However it's very inefficient, so I wouldn't recommend it.
I would recommend a normal out-of-tree build, and then explicitly excluding the remaining auto-generated files in the source tree.