Project

General

Profile

Actions

Bug #525

open

Build fails on CentOS due to missing m4 directory and AM_PROG_AR

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

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Start date:
15 Jun 2016
Due date:
% Done:

50%

Estimated time:
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

Actions #1

Updated by Hammel over 6 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.

Actions #2

Updated by Hammel over 6 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...

Actions #3

Updated by Hammel over 6 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.

Actions #4

Updated by Hammel about 6 years ago

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

Actions #5

Updated by Hammel about 6 years ago

  • Target version changed from 0.11.0 to 0.12.0
Actions

Also available in: Atom PDF