Error while building rootfs for Linux kernel - linux-kernel

I am trying to build my root file system by referring to
http://emreboy.wordpress.com/2012/12/20/building-a-root-file-system-using-busybox/comment-page-1/
The change I did was (arm-linux-gnueabi- in place of arm-linux-)
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install
It fails on this step(partial error log). Please advise
CC util-linux/volume_id/volume_id.o
CC util-linux/volume_id/xfs.o
AR util-linux/volume_id/lib.a
LINK busybox_unstripped
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
arm-linux-gnueabi-gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -static -o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment -Wl,--start-group applets/built-in.o archival/lib.a archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
debianutils/lib.a(mktemp.o): In function `mktemp_main':
mktemp.c:(.text.mktemp_main+0x70): warning: the use of `tempnam' is dangerous, better use `mkstemp'
networking/lib.a(nslookup.o): In function `print_host':
nslookup.c:(.text.print_host+0x24): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(ipcalc.o): In function `ipcalc_main':
ipcalc.c:(.text.ipcalc_main+0x15c): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
libbb/lib.a(inet_common.o): In function `INET_resolve':
inet_common.c:(.text.INET_resolve+0x32): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x546): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(netstat.o): In function `ip_port_str':
netstat.c:(.text.ip_port_str+0x28): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(inetd.o): In function `reread_config_file':
inetd.c:(.text.reread_config_file+0x4e4): warning: Using 'getrpcbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
networking/lib.a(inetd.o): In function `unregister_rpc':
inetd.c:(.text.unregister_rpc+0xc): undefined reference to `pmap_unset'
networking/lib.a(inetd.o): In function `register_rpc':
inetd.c:(.text.register_rpc+0x30): undefined reference to `pmap_unset'
inetd.c:(.text.register_rpc+0x46): undefined reference to `pmap_set'
networking/lib.a(inetd.o): In function `prepare_socket_fd':
inetd.c:(.text.prepare_socket_fd+0x52): undefined reference to `bindresvport'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1

With the help from vinay hunachyal the answer is as follows
use latest stable busybox code
use the same tool chain (arm-none-linux-gnueabi-gcc) for all the steps (not as the one actually given on the blog)

Related

Error when cross compiling shared so which depends on another so

I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html

How do I statically link zstd library to my dynamic library?

I am trying to statically link zstd library(I have libzstd.a or libzstd.so) to my shared library libtest.so. The idea is that when deploying libtest.so in our application, we don't have to depend on libzstd.a or libzstd.so any more, so we have to statically link the zstd library.
I tried these:
cc -fPIC -Wl,-soname=libtest.so -static-libgcc -shared -o libtest.so myobjects.o -ldl -lc -L/path/to/libzstd -l:libzstd.a
cc -fPIC -Wl,-soname=libtest.so -static-libgcc -shared -o libtest.so myobjects.o -ldl -lc -Wl,-Bstatic -L/path/to/libzstd -l:libzstd.a
cc -fPIC -Wl,-soname=libtest.so -static-libgcc -shared -o libtest.so myobjects.o -ldl -lc /path/to/libzstd/libzstd.a
But they're all giving me this error:
/bin/ld: /path/to/libzstd/libzstd.a(zstd_common.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object;
recompile with -fPIC
/path/to/libzstd/libzstd.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libtest.so] Error 1
What are the problem here? Thank you!
All object files that are linked into a shared library must be compiled
as Position Independent Code (compiler option -fPIC).
The linker error:
/bin/ld: /path/to/libzstd/libzstd.a(zstd_common.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object;
recompile with -fPIC
is telling you that the linkage of the shared library libtest.so needs the object file zstd_common.o from the
archive libzstd.a, but that object file was not compiled with -fPIC.
So you must rebuild libzstd.a from source, this time compiling the object
files that it contains with -fPIC.

Fortran compile shared object which includes netcdf static library

I am trying to create a shared object in fortran, that uses the netcdf static library.
The ultimate aim is to use this shared object in R, but I think the problem starts with my makefile, so I am just focusing on this here:
In my makefile i use the following flags
'F90 = ifort
FFLAGS = -O3 -fPIC -r8 # double-precision now run in Fortran , -fpic
for creating shared object file
LDFLAGS = -lnetcdff -lnetcdf -shared #-shared, for creating a shared
object file'
I think I managed to link everything allright, (you see all my object files below in the error message), but in the next step, when creating the shared object, there is a netcdf-library specific error message:
'ifort -O3 -fPIC -r8 -o HX.so HX.o HANDLE_ERR.o GET_CLM.o INTEGRATE.o
CLIMATE.o STATE.o PARAMETERS.o CONTROL.o HYDRO.o DYNAMICS.o CARBON.o
RINGS.o INIT.o SET_PARAMS.o -lnetcdff -lnetcdf -shared
ld: /usr/local/Cluster-Apps/netcdf/4.1.3/lib/libnetcdff.a(netcdf4.o):
relocation R_X86_64_32 against `.bss' can not be used when making a
shared object; recompile with -fPIC
/usr/local/Cluster-Apps/netcdf/4.1.3/lib/libnetcdff.a: could not read
symbols: Bad value
make: *** [HX.so] Error 1'
I find 'similar' problems, but as I am not familiar with the terminology and this is my very first try in generating a shared object, I cannot follow their instructions for my problem.
You need to install the dynamic (.so) version of NetCDF, be it from your repository or by compiling it yourself. As tim18 say in the comments, it also needs to be compiled with -fPIC, and the .so version will be.

how can I fix ld not ignoring bad system libraries in favor of my local libraries?

I'm trying to build the newest gcc on my redhat box. I've downloaded and built the latest gmp, mpfr and mpc, per requirements and installed them in my local libraries. From the config.log file I have the following given below. Clearly the system version of mpfr is broken, and I want the configure to ignore it. I have set LIBRARY_PATH and LD_LIBRARY_PATH to point to my local installation /u/victor/lib. Since I'm running a configure script, it's not reasonable for me to try to change command line options for gcc. How do I fix this?
gcc -o conftest -g -O2 conftest.c -L/u/victor/lib -L/u/victor/lib -L/u/victor/lib -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: warning: libmpfr.so.1, needed by /u/victor/lib/libmpc.so, may conflict with libmpfr.so.4
/usr/bin/ld: __gmpfr_cache_const_euler: TLS definition in /u/victor/lib/libmpfr.so section .tdata mismatches non-TLS definition in /usr/lib64/libmpfr.so.1 section .data
What's even more confusing, is that when I compile conftest.c and then
gcc -o conftest conftest.o -lmpc -lmpfr -lgmp
with export LD_LIBRARY_PATH=/u/victor/lib it gives the errors below. I've check libmfpr.so with nm and the three "undefined" symbols are there.
/u/victor/lib/libmpc.so: undefined reference to `mpfr_min_prec'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_set_zero'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_get_z_2exp'

Android NDK Cannot load library: reloc_library[1306]

Im developing an android app thats loading two shared libraries. One is external, its called libpcan.so . Usually its build to libpcan.so.0.6, this somehow cant be used by my android, i so changed the gcc flags compiling it from:
arm-linux-androideabi-gcc src/libpcan.c -fPIC -shared -O2 -Wall -Wl,-soname,-libpcan.so.0 -lc -I. -I../driver -DNO_RT -o -libpcan.so.0.6
ln -sf libpcan.so.0.6 libpcan.so
to
arm-linux-androideabi-gcc src/libpcan.c -fPIC -shared -O2 -Wall -lc -I. -I../driver -DNO_RT -o -libpcan.so
This .so has the same size as the so.0.6 so i assume it worked fine.
My own c-code is getting compiled with
arm-linux-androideabi -shared src/receivetest.c src/common.c -I. -I../lib -I../driver -L../lib -L/lib -L/usr/lib -L/usr/local/lib -o libreceivetest.so
I load both of these files, so the libpcan.so and the libreceivetest.so to my app
static {
System.loadLibrary("pcan");
System.loadLibrary("receivetest");
}
When I'm trying to launch that app i get the error message:
07-14 11:12:43.812: E/AndroidRuntime(753): java.lang.ExceptionInInitializerError
07-14 11:12:43.812: E/AndroidRuntime(753): Caused by: java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1306]: 36 cannot locate 'CAN_Open'...
My receivetest is using that function, but since it declared in the libpcan.so and im also loading that library, i don't know where that error could come from.
I'd just guess its an error in my clags, since I'm new to building .so files via using gcc in the shell i don't really understand all the flags im using.
It's quite long since i solved this. But I haven't ever marked this question as solved.
Thanks to jww for reminding me.
As I've said in the comment to my question, the link to the function CAN_Open was missing due to a missing parameter at compiling the .so-file. The function CAN_Open is a part of the libpcan.so and by skipping the link to that file the CAN_Open function just never made it into the receivetest.so .

Resources