I'm trying to build a custom kernel image for my PhidgetSBC but I'm getting a failure during the build:
bluez 4.96 Extracting
bluez 4.96 Patching package/bluez
for file in config.guess config.sub; do for i in $(find
/home/kerubu/buildroot_phidgetsbc/new/buildroot-phidgetsbc_1.0.4.20111028/output/build/bluez-4.96
-name $file); do cp package/gnuconfig/$file $i; done; done
Patching libtool
Applying buildroot-libtool.patch using plaintext: patching file
ltmain.sh
Hunk #1 FAILED at 273.
Hunk #2 succeeded at 5412 (offset 3005 lines).
Hunk #3 FAILED at 2551.
Hunk #4 FAILED at 2895.
Hunk #5 succeeded at 8058 with fuzz 1 (offset 2446 lines).
Hunk #6 FAILED at 5937.
4 out of 6 hunks FAILED -- saving rejects to file ltmain.sh.rej
Patch failed! Please fix buildroot-libtool.patch!
make: *
[/home/kerubu/buildroot_phidgetsbc/new/buildroot-phidgetsbc_1.0.4.20111028/output/build/bluez-4.96/.stamp_patched]
Error 1
I'm not sure how to proceed from here. Does anyone have any advice?
Yeah, you use an old version of Buildroot in which we only had a patch against libtool 1.5, but your version of Bluez probably uses libtool 2.2. As a quick workaround, you can try to add the following line to the bluez .mk file :
BLUEZ_LIBTOOL_PATCH = NO
which will tell Buildroot to not apply the libtool patch.
However, the libtool handling has been improved since quite some time in Buildroot, so it's a bit of shame to not take advantage of the newer Buildroot releases.
It looks like the patch and 'ltmain.sh' are not in sync. There's a couple ways this can happen. One is that 'autoreconf -f' has been invoked and the ltmain.sh that is copied down is not compatible with the patch. If you can at least remove the -f argument from autoreconf, it shouldn't rewrite it.
Related
anybody here?
I have been working on using afl-qemu mode fuzzing IoT binaries. But I got a "Fork server handshake failed" problem when started to run the binary. I have read the previous related session but none of those fix my problem.
The information of the binary is here:
./bin/busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
Through my tests, only the version of qemu bigger than 4.1.0 can cope with the '-L' parameter successfully. So I upgrade the qemu version through editing the build_qemu_support.sh. What needs to be mention is that I comment out a few lines of code in order to deal with the error that occurred running.
#patch -p1 <../patches/elfload.diff || exit 1
#patch -p1 <../patches/cpu-exec.diff || exit 1
#patch -p1 <../patches/syscall.diff || exit 1
After setting the QEMU_LD_PREFIX and AFL_PATH, I tried the suggestion like 'afl-showmap -m none -o fuzz_out/out.txt -Q ./bin/busybox cat' and it turned out to be fine.
root#ubuntu:squashfs-root# afl-showmap -m none -o fuzz_out/out.txt -Q ./bin/busybox cat
afl-showmap 2.52b by <lcamtuf#google.com>
[*] Executing './bin/busybox'...
-- Program output begins --
But when I tried command 'afl-fuzz -m none -i fuzz_in/ -o fuzz_out/ -Q ./bin/busybox cat ##' , it reported the error shown below.
root#ubuntu:squashfs-root# afl-fuzz -m none -i fuzz_in/ -o fuzz_out/ -Q ./bin/busybox cat ##
afl-fuzz 2.52b by <lcamtuf#google.com>
[+] You have 4 CPU cores and 2 runnable tasks (utilization: 50%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[*] Checking core_pattern...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'fuzz_in/'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:testcase'...
[*] Spinning up the fork server...
[-] Hmm, looks like the target binary terminated before we could complete a
handshake with the injected code. Perhaps there is a horrible bug in the
fuzzer. Poke <lcamtuf#coredump.cx> for troubleshooting tips.
[-] PROGRAM ABORT : Fork server handshake failed
Location : init_forkserver(), afl-fuzz.c:2253
Could anybody tell me where is the problem? Is there anything to do with my upgrade of qemu? Thanks so much!!
You've tried to upgrade the version of QEMU that afl-qemu uses. Because afl-qemu makes modifications to QEMU's source, this is not a trivial thing to do. In particular, these commands that you commented out:
#patch -p1 <../patches/elfload.diff || exit 1
#patch -p1 <../patches/cpu-exec.diff || exit 1
#patch -p1 <../patches/syscall.diff || exit 1
are all commands that say "make the precise modifications to the QEMU source code that the .diff files specify". Commenting out the patch commands means that the modifications aren't made. It is then not surprising that the resulting QEMU binary doesn't interact with the afl-qemu framework in the way that it should.
If you need to make afl-qemu work with a newer QEMU, you will have to look inside all the patch files and identify what the equivalent changes on the newer QEMU version would be. That is going to be tricky unless you're familiar (or willing to take the time to become familiar) with the internals of QEMU and afl-qemu. (You might look around to see if anybody else has already done this.)
If the only reason you tried this upgrade was to try to avoid the QEMU bug with its '-L' option in earlier QEMU versions, it will probably be easier if you instead use the standard afl-qemu, and change what the directory you are pointing '-L' at to be simpler so that the older QEMU can work with it. In particular, don't point it at an entire chroot, but instead point it only at a directory structure with guest shared libraries, and where there aren't any symbolic links between directories. (It is the symbolic link structure in particular that is what causes the hang in the older QEMU.)
I have a problem by compiling a driver (WLAN-dongle Edimax ac600).
I´m using an Archlinux on my raspberry-pi and want to install my dongle for 5Ghz. During comiling the driver I get this message. I tried to install the linux-headers without success. (in other threads it will be a solution)
Here is my output of make:
[root#raspberry_pi_1 rtl8812AU]# make make ARCH=arm CROSS_COMPILE= -C
/lib/modules/4.9.43-1-ARCH/build M=/root/rtl8812AU modules make[1]:
*** /lib/modules/4.9.43-1-ARCH/build: No such file or directory. Stop. make: *** [Makefile:1576: modules] Error 2
I found out that my pi has a two-arch...-directories:
4.9.43-1-ARCH/
4.9.51-1-ARCH/
Only the second one has the build directory...
How can I fix the problem?!
thanks a lot,
a Linux noob...
[Reputation is too low to post comment]
Use uname -r to make sure which version of the kernel you use.
If it's 4.9.43 : you have newer version of the kernel and this confuse your installer. You should reboot on the 51 one
If it's 4.9.51 : You messed up your installation step and are trying to compile for an old target. You should review the compilation process and change every mention of the 4.9.43 to 4.9.51 since it's the version you use.
If you upgrade your kernel, you may have to rebuild the thing again (You may like to have script in the future ;) ) with the new kernel version.
I clone latest git tree from linux source. I am running all in Virtual box(first memory was 4096 MB because of seg-fault I increase to 8096 MB then also same error). Right now VM has 3.19.0 installed
>clone latest git tree
>make localmodconfig
>make -j1
>sudo make mosules_install
All install work fine.
but with depmod it's giving me below error
DEPMOD 4.3.0-11785-gca4ba96
depmod: WARNING: found 2 modules in dependency cycles!
depmod: WARNING: /lib/modules/4.3.0-11785-gca4ba96/kernel/drivers/staging/lustre/lnet/lnet/lnet.ko in dependency cycle!
depmod: WARNING: /lib/modules/4.3.0-11785-gca4ba96/kernel/drivers/staging/lustre/lustre/libcfs/libcfs.ko in dependency cycle!
./scripts/depmod.sh: line 57: 23221 Killed "$DEPMOD" "$#" "$KERNELRELEASE" $SYMBOL_PREFIX
make: *** [_modinst_post] Error 137
Earlier I got seg fault same line, this times it's killed because I tried depmod -a VERSION(4.3.0.....)
Also when I tried manually depmod -a VERSION(4.3.0.....) it's didn't gave me any error it's work fine.
go to libcfs/libcfs/module.c and remove a switch-case piece for IOC_LIBCFS_PING_TEST - it's an obsolete codepiece, and it will work like a charm
It is a known issue that hasn't been fixed yet, see lkml:
https://lkml.org/lkml/2015/11/7/229
To fix / work around it, disable the building of Lustre file system driver modules.
I had the same problem. Commenting out the line of "$DEPMOD" "$#" "$KERNELRELEASE" $SYMBOL_PREFIX in file scripts/depmod.sh solved it.
For example, the following assembler statement should translate to the opcode 0x0000000b
custom0 0,0,0,0
With an older version of riscv-gnu-toolchain (built on Jun 4th) no -march= option was needed to assemble this. However, with todays git head of riscv-tools I get:
$ /opt/riscv_new/bin/riscv64-unknown-elf-as -m32 test.s
test.s: Assembler messages:
test.s:1: Error: unrecognized opcode `custom0 0,0,0,0'
From reading the source code I'd guess passing the arch Xcustom to the tools should fix that, but:
$ /opt/riscv_new/bin/riscv64-unknown-elf-as -m32 -march=RV32IMXcustom test.s
test.s: Assembler messages:
test.s:1: Error: unrecognized opcode `custom0 0,0,0,0'
(At the moment the PicoRV32 test firmware does not build with the latest riscv-gnu-toolchain because of this.)
Edit: The last version of riscv-tools that work for me is commit 84a47e0b4e from Aug 20. With that version the custom0 opcode is recognized with and without the -march= option.
Sorry this took so long to find -- I don't read stackoverflow. For future reference, if you submit a github issue/PR or email me directly, I'll deal with these sorts of things.
A fix should be here, do you mind verifying it?
https://github.com/riscv/riscv-gnu-toolchain/pull/97
Sorry for introducing the regression!
I also faced this issue, in yesterdays update of the gnu toolchain if you look into the opcodes.custom file in the risv-opcodes folder, all the custom opcodes are commented, you need to uncomment those that you need and recompile the toolchain
I had the inspiration to start messing around with Erlang and I am having problems installing it... I am using Linux Mint 16 (petra). I installed the dependencies, and then downloaded otp_src_17.1.tar.gz and ran 'tar -zxf otp_src_17.1.tar.gz' I then ran ./configure which gave me some errors that made it impossible to run make.
These are the errors I'm getting (actually what I did was I did ./configure > configure.txt to get all the lines it prints as it configures, and it conveniently still printed to the console everything that has errors - neat)
configure: WARNING: No odbc library found skipping odbc
configure: WARNING: "ODBC library - header check failed"
configure: WARNING: "ODBC library - link check failed"
rm: remove write-protected regular file './CONF_INFO'?
configure: WARNING: No GLU headers found, wx will NOT be usable
/home/core/Desktop/otp_src_17.1/lib/wx/./configure: line 5195: wx-config: command not found
/home/core/Desktop/otp_src_17.1/lib/wx/./configure: line 5893: ./CONF_INFO: Permission denied
configure: WARNING:
wxWidgets must be installed on your system.
Please check that wx-config is in path, the directory
where wxWidgets libraries are installed (returned by
'wx-config --libs' or 'wx-config --static --libs' command)
is in LD_LIBRARY_PATH or equivalent variable and
wxWidgets version is 2.8.4 or above.
rm: remove write-protected regular file 'doc/CONF_INFO'?
/home/core/Desktop/otp_src_17.1/erts/configure: line 6466: doc/CONF_INFO: Permission denied
configure: WARNING: No 'xsltproc' command found: the documentation cannot be built
/home/core/Desktop/otp_src_17.1/erts/configure: line 6513: doc/CONF_INFO: Permission denied
configure: WARNING: No 'fop' command found: going to generate placeholder PDF files
configure: error: No curses library functions found
configure: error: /bin/bash '/home/core/Desktop/otp_src_17.1/erts/configure' failed for erts
The thing is - I know that I have the ncurses library, as evidenced by the fact that when I do "sudo apt-get install ncurses-base ncurses-bin" it says:
Reading package lists... Done
Building dependency tree
Reading state information... Done
ncurses-base is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
When I run "locate ncurses" it gives me the following:
/lib/i386-linux-gnu/libncurses.so.5
/lib/i386-linux-gnu/libncurses.so.5.9
/lib/x86_64-linux-gnu/libncurses.so.5
/lib/x86_64-linux-gnu/libncurses.so.5.9
/lib/x86_64-linux-gnu/libncursesw.so.5
/lib/x86_64-linux-gnu/libncursesw.so.5.9
/usr/bin/ncurses5-config
/usr/bin/ncursesw5-config
/usr/lib/vlc/plugins/gui/libncurses_plugin.so
/usr/share/doc/libncurses5
/usr/share/doc/libncursesw5
/usr/share/doc/ncurses-base
/usr/share/doc/ncurses-bin
/usr/share/doc/ncurses-base/changelog.Debian.gz
/usr/share/doc/ncurses-base/copyright
/usr/share/doc/ncurses-bin/FAQ
/usr/share/doc/ncurses-bin/changelog.Debian.gz
/usr/share/doc/ncurses-bin/copyright
/usr/share/lintian/overrides/ncurses-base
/usr/share/man/man1/ncurses5-config.1.gz
/usr/share/man/man1/ncursesw5-config.1.gz
/var/cache/apt/archives/libncurses5_5.9+20130608-1ubuntu1_i386.deb
/var/lib/dpkg/info/libncurses5:amd64.list
/var/lib/dpkg/info/libncurses5:amd64.md5sums
/var/lib/dpkg/info/libncurses5:amd64.postinst
/var/lib/dpkg/info/libncurses5:amd64.postrm
/var/lib/dpkg/info/libncurses5:amd64.shlibs
/var/lib/dpkg/info/libncurses5:amd64.symbols
/var/lib/dpkg/info/libncurses5:i386.list
/var/lib/dpkg/info/libncurses5:i386.md5sums
/var/lib/dpkg/info/libncurses5:i386.postinst
/var/lib/dpkg/info/libncurses5:i386.postrm
/var/lib/dpkg/info/libncurses5:i386.shlibs
/var/lib/dpkg/info/libncurses5:i386.symbols
/var/lib/dpkg/info/libncursesw5:amd64.list
/var/lib/dpkg/info/libncursesw5:amd64.md5sums
/var/lib/dpkg/info/libncursesw5:amd64.postinst
/var/lib/dpkg/info/libncursesw5:amd64.postrm
/var/lib/dpkg/info/libncursesw5:amd64.shlibs
/var/lib/dpkg/info/libncursesw5:amd64.symbols
/var/lib/dpkg/info/ncurses-base.conffiles
/var/lib/dpkg/info/ncurses-base.list
/var/lib/dpkg/info/ncurses-base.md5sums
/var/lib/dpkg/info/ncurses-bin.list
/var/lib/dpkg/info/ncurses-bin.md5sums
I am at a loss as to where to proceed. Thanks for any help
I believe you need to install ncurses-dev
'sudo yum install ncurses-devel.x86_64' prior to running ./configure worked just fine for me. Fedora 21 x64, btw.
After I extracted the tar, the documentation was in '/opt_src_{version}/HOWTO/INSTALL.md. The contents of which states:
Required Utilities
These are the tools you need in order to unpack and build Erlang/OTP.
WARNING: Please have a look at the [Known platform issues][] chapter
before you start.
Unpacking
GNU unzip, or a modern uncompress.
A TAR program that understands the GNU TAR format for long filenames.
Building
GNU make
Compiler -- GNU C Compiler, gcc or the C compiler frontend for LLVM, clang.
Perl 5
GNU m4 -- If HiPE (native code) support is enabled. HiPE can be
disabled using --disable-hipe
ncurses, termcap, or termlib -- The development headers and
libraries are needed, often known as ncurses-devel. Use
--without-termcap to build without any of these libraries. Note that
in this case only the old shell (without any line editing) can be used.
sed -- Stream Editor for basic text transformation.
ncurses just happened to be the only required package I didn't have installed on this development VM. So your mileage may vary.
This was the output of 'locate ncurses' after I installed the ncurses lib:
/usr/lib64/libncurses++.so.5
/usr/lib64/libncurses++.so.5.9
/usr/lib64/libncurses++w.so.5
/usr/lib64/libncurses++w.so.5.9
/usr/lib64/libncurses.so.5
/usr/lib64/libncurses.so.5.9
/usr/lib64/libncursesw.so.5
/usr/lib64/libncursesw.so.5.9
/usr/share/doc/ncurses
/usr/share/doc/ncurses-base
/usr/share/doc/ncurses/ANNOUNCE
/usr/share/doc/ncurses/AUTHORS
/usr/share/doc/ncurses/NEWS.bz2
/usr/share/doc/ncurses/README
/usr/share/doc/ncurses/TO-DO
/usr/share/doc/ncurses-base/README
/usr/share/licenses/ncurses-base
/usr/share/licenses/ncurses-base/COPYING
So I'd say the OP had a corrupt / bad ncurses install. I'm just posting this here because this was the #1 Google result I got when I was too lazy to RTFD.
One alternative is using the option "--without-termcap"
otp_src_18.0/configure file says:
--without-termcap do not use any termcap libraries
(ncurses,curses,termcap,termlib)
./configure --prefix=/home/username/erlang/18.0 --without-termcap
Set your PATH variable as shown below.
export PATH=$PATH=/home/username/erlang/18.0/bin
Not sure about implications though. :)
Hope this helps someone.