Bug #525
Build fails on CentOS due to missing m4 directory and AM_PROG_AR
| Status: | In Progress | Start date: | 15 Jun 2016 | ||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assignee: |  Hammel | % Done: | 50% | ||
| Category: | - | ||||
| Target version: | PiBox - 0.12.0 | ||||
| Severity: | 03 - Medium |
Description
The m4 directory just needs to exist. Not sure if git will show it if the directory doesn't contain something, which means I may need to check in the files generated in m4 by autoconf.
The AM_PROG_AR variable is not in the version of automake on CentOS 6.x. The fix may be to use an m4 ifdef
Associated revisions
RM #525: Remove unused AM_PROG_AR from configure.ac that was causing problems on CentOS 6.x.
Fix cross.sh to work correctly with sysroot.
Add m4 directory because build fails without it on CentOS 6.x.
RM #525: Don't remove m4 directory on distclean.
RM #525: Fix cross compilation for both Fedora and CentOS 6.7.
RM #525: Another cross fix - Fedora doesn't support --sysroot correctly for linking, apparently, but CentOS does.
History
#1
Updated by Hammel about 1 year ago
Fixing these gets passed these errors, but then I get this:
libtool: link: arm-unknown-linux-gnueabi-gcc -shared .libs/libpibox_la-pibox.o .libs/libpibox_la-log.o .libs/libpibox_la-utils.o .libs/libpibox_la-rpi.o .libs/libpibox_la-parson.o .libs/libpibox_la-pmsg.o -L/home/mjhammel/src/ximba/raspberrypi2/bld/buildroot-2015.02/output/staging/usr/lib -L/home/mjhammel/src/ximba/raspberrypi2/bld/buildroot-2015.02/output/staging/lib -L/home/mjhammel/src/ximba/raspberrypi2/bld/buildroot-2015.02/output/staging/arm-unknown-linux-gnueabi/sysroot/ -Wl,-soname -Wl,libpibox.so.0 -o .libs/libpibox.so.0.0.11 /opt/rpiTC/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.8.5/../../../../arm-unknown-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 /opt/rpiTC/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.8.5/../../../../arm-unknown-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6 /opt/rpiTC/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.8.5/../../../../arm-unknown-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a /opt/rpiTC/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.8.5/../../../../arm-unknown-linux-gnueabi/bin/ld: cannot find /usr/lib/libc_nonshared.a /opt/rpiTC/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.8.5/../../../../arm-unknown-linux-gnueabi/bin/ld: cannot find /lib/ld-linux-armhf.so.3 collect2: error: ld returned 1 exit status make[1]: *** [libpibox.la] Error 1 make[1]: Leaving directory `/home/mjhammel/src/ximba/libpibox/src/src' make: *** [install-recursive] Error 1
It's looking in the wrong location for these libs. I don't know why. I need to verify the cross.sh works for libpibox on Fedora. I'm pretty sure it does. Which makes this error very suspicious.
#2
Updated by Hammel about 1 year ago
- Status changed from New to In Progress
- Assignee set to Hammel
- Target version set to 0.11.0
- % Done changed from 0 to 40
First, libpibox failed due to problems with a missing m4 directory and the referent to AM_PROG_AR. To test fixes I needed to use cross.sh, but this was broken too. The latter took longer to fix than the former but I finally found a common solution for libpibox that works on both CentOS and Fedora (ubuntu be damned - I didn't test there).
Then the same problem arose for pnc (pibox-network-config). The same fixes for the former were applied and to cross.sh. But in this case the cross doesn't work correctly on Fedora. So I have to test for which platform I'm on and set the LDFLAGS slightly differently on the two platforms. But now that fix is in and the rootfs build re-run. Waiting to see if we get further this time...
#3
Updated by Hammel 12 months ago
- % Done changed from 40 to 50
The fedora build completed, including the meta build for packages. This worked on an RPi 2.
All package updates are checked in. All RPi 2 specific changes are committed and pushed to the mjhammel/rpi2 branch.
Currently updating that branch with fixes required for RPi 2 to fully run on hardware. Then those will be tested on CentOS.