Bug #525
closed
Build fails on CentOS due to missing m4 directory and AM_PROG_AR
100%
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
Updated by Hammel almost 9 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.
Updated by Hammel almost 9 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...
Updated by Hammel almost 9 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.
Updated by Hammel over 8 years ago
The core and all apps build on CentOS now, except for omxplayer. It fails and I don't know why yet.
Updated by Hammel almost 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
Not an issue now that the dev platform builds in Docker and, eventually, all apps will be there too. Currently all apps build just fine on Debian 11.
Closing issue.