can anyone help me to resolve kernel dependency ? I have done net-snmp packaging on linux-3.0.2-generic and trying to make it work on below version.
uname –a
Linux manage 2.6.18.8-1 #3 Wed May 28 14:06:14 UTC 2008 i686 unknown
Snmp version : 5.7.2.rc1
/usr/sbin/chroot /var/snmp3/ /usr/local/sbin/snmpd -f –Le
FATAL: kernel too old
file /usr/local/sbin/snmpd
/usr/local/sbin/snmpd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xacef27c048394ffb2cdef4999566e9aa32e5d2dd, not stripped
so... the file wants 2.6.24 and above version
Hw can I resolve this issue and make it to work on 2.6.18 ? Should I make changes in snmpd.c and recompile it ? if yes than how to do this ? If not than what is the solution of it ?
Just recompiling should be sufficient.
The toolchain used to recompile needs to have a version of the kernel headers and C library that will work with this kernel.
Alternatively, you can switch to a newer kernel, which also has the advantage that it is easier to get security fixes.
Related
I have two ELF binaries on my Linux machine. When I run file on them I receive the following:
File#1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.0, not stripped
File#2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
Now as far as I understand it, the for GNU/Linux 2.2.X part stems from the .note.ABI-tag section of the binary and is added by the linker. The resulting value of 2.2.X depends on the version of the C library that is linked to the binary and describes the lowest ABI version that this C library version supports - meaning that File #1 will be supported on machines with a Linux kernel >= 2.2.0 and File #2 on machines with a Linux kernel >= 2.2.5. (Is that correct, or am I already wrong here?)
I would suppose that the differences in the ABI tag would stem from two different C library versions contained in the two binaries. But when I examine the strings of the binaries, both of them contain the string glibc 2.3.2.
How is this possible? It seems unreasonable to me, that a patch of some sort to the GNU C Library which didn't result in a version number change would change the supported ABI version...
The glibc ABI is supposed to be independent of the kernel version it is built for, and the test suite attempts to verify that a newly built glibc conforms to the official ABI.
The minimum kernel version required by a glibc release can be specified at glibc configure time, and this is what ends up in the .note.ABI-tag section. No patching of the glibc sources is needed. I'm not entirely sure whether it is correct that the configured minimum kernel version ends up in dynamically linked binaries (because it should be possible to run the binaries on older kernels with a differently built glibc).
However, for statically linked binaries, this is certainly correct because configuring a higher minimum kernel version will make the program fail to run on older kernels.
I'm planning to build DAHDI for Beagleboneblack
Firstly, I built the kernel for BBB completely by following this tutorial
http://elinux.org/Building_BBB_Kernel,
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- beaglebone_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage dtbs
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- uImage-dtb.am335x-boneblack modules
I used linaro toolchain for armhf (CROSS_COMPILE=arm-linux-gnueabihf-) instead of the instructed one.
And then I start building the DAHDI :
cd dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2
cd linux/ # I build the dahdi only, not their tools
make KSRC=PATH_TO_MY_ABOVE_KERNEL
Unfortunately, process ends with the following error when compiling the dahdi-base.c :
/home/working/dl/dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2/linux/drivers/dahdi/dahdi-base.c:1: error: code model kernel not supported in the 32 bit mode
/home/working/dl/dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2/linux/drivers/dahdi/dahdi-base.c:1: sorry, unimplemented: 64-bit mode not compiled in
I have no idea why, because my linaro toolchain is 32-bit
/home/working/dl/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux/bin/arm-linux-gnueabihf-gcc-4.7.3:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
and my gnu gcc toolchain is 32-bit as well.
/usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
If anybody gets an idea, your help would be appreciated.
Best Regard.
Loi Dang Thanh
I'm making this answer to make sure everyone else who get into my issue can search and solve the problem in the future.
Just add 2 more ARGS to the make command when building DAHDI, and the problem solved pretty well.
make KSRC=PATH_TO_MY_ABOVE_KERNEL ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
A big thanks to Miline who get me out of the stuck.
Best Regards
Loi Dang.
I have a development kit ( Altera Cyclon V, Cortex A9) and I'm trying to run a simple app on it.
I'm using cygwin for cross compiling my code for ARM Linux (using soureforge toolchain for Linux ).
Steps :
build within cygwin : arm-linux-gcc dd.c -s -mcpu=cortex-a9 -s -o ddb
copy ddb to target and chmod a+x
running it gives me "./ddb: No such file or directory" .
probably a mismatch between lib\tools but I'm new to Linux ( coming from QNX ).
Target is running :
root#socfpga:~/altera# cat /proc/version
Linux version 3.9.0 (jdasilva#sj-interactive3) (gcc version 4.7.3 20121106 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.1
1-20121123 - Linaro GCC 2012.11) ) #1 SMP Fri Sep 27 22:55:43 PDT 2013
File data of my app :
ddb: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared
libs), for GNU/Linux 2.6.33, stripped
File data of a sample hello_world that runs on target :
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (use
s shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0x2e8fbebd0bdab5897c0c65fb6b
563f3c34a16eb1, stripped
I can see that different DLL are being used ( 2.6.31 vs 2.6.33 ).
How can I solve this?
I've had that problem before when I tried to copy ARM binaries to an ARM android device.
You solved it, but either way, this is what I found out. The problem was the shared libraries. It is trying to load a library that doesn't exist on the target. The "file not found" error is very misleading.
Related question and answers:
"No such file or directory" but it exists
could be 64<>32bit problem.
See this
I want to copile a simple c program ("Hello world") for my Xtreamer prodigy. which runs a basic linux kernel:
/host # uname -a
Linux Prodigy 2.6.34-VENUS #30 PREEMPT Tue Feb 28 13:48:27 CST 2012 mips GNU/Linux
(it using chipset Realtek 1186)
I saw one executable file on the streamer and i "filed" it on linux and i got:
sh-4.1# file DvdPlayer
DvdPlayer: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped
On my computer I run linux centos. what compiler do I need to use and when can I get it?
Thanks!
What you need is a cross toolchain - gcc has a architecture that enables it to have different code generation backends, mainly to be able to compile for other architectures than the one you're developing on.
Lots of precompiled cross toolchains exist, an overview of ready to use toolchains for MIPS can be found here.
On the other hand, creating your own cross tool chain, finetuned to your needs, isn't that hard either, it's just quite a bit of work. The canonical reference on how to generate a cross toolchain is Dan Kegel's page.
I'm working on a project for a friend on a machine I'm not familiar with and I've run into some errors.
I'm running a program called bibtex2html, which is used to generate an HTML reference page. When I run the program, it gives me a "Cannot execute binary file" error.
From my preliminary research, it seems there are a number of causes to this problem, and I'm not really sure to begin.
What I've done so far:
uname -a ->
Linux baseline 2.6.38-15-generic-pae #60-Ubuntu SMP Tue May 22 11:48:17 UTC 2012 i686 i686 i386 GNU/Linux
file ~/bibtex2html/bibtex2html -> ~/bibtex2html/bibtex2html: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
You did all the research correctly, now you just need to interpret it. It's a 64-bit executable (x86-64), and you're on a 32-bit kernel (i686). You'll need to find or compile a 32-bit version of bibtex2html.