Bug #525

Build fails on CentOS due to missing m4 directory and AM_PROG_AR

Added by Hammel over 5 years ago. Updated about 5 years ago.

Status:In ProgressStart date:15 Jun 2016
Priority:NormalDue date:
Assignee:Hammel% Done:


Target version:PiBox - 0.12.0
Severity:03 - Medium


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

Revision f7ccb09a
Added by Hammel over 5 years ago

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.

Revision 77ce0be2
Added by Hammel over 5 years ago

RM #525: Don't remove m4 directory on distclean.

Revision 28d93606
Added by Hammel over 5 years ago

RM #525: Fix cross compilation for both Fedora and CentOS 6.7.

Revision 25bdaa57
Added by Hammel over 5 years ago

RM #525: Another cross fix - Fedora doesn't support --sysroot correctly for linking, apparently, but CentOS does.


#1 Updated by Hammel over 5 years 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 over 5 years 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 about 5 years 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.

#4 Updated by Hammel about 5 years ago

The core and all apps build on CentOS now, except for omxplayer. It fails and I don't know why yet.

#5 Updated by Hammel about 5 years ago

  • Target version changed from 0.11.0 to 0.12.0

Also available in: Atom PDF