Problem building latest 4.1.* builds
Added by Nihil Baxter over 9 years ago
Next build problem with newest 4.1.* builds:
In file included from src/tvhlog.h:31:0, from src/tvheadend.h:43, from src/uuid.c:20: src/atomic.h: In function ‘atomic_add_u64’: src/atomic.h:48:23: error: ‘atomic_lock’ undeclared (first use in this function) src/atomic.h:48:23: note: each undeclared identifier is reported only once for each function it appears in src/atomic.h: In function ‘atomic_dec_u64’: src/atomic.h:63:23: error: ‘atomic_lock’ undeclared (first use in this function) src/atomic.h: In function ‘atomic_pre_add_u64’: src/atomic.h:78:23: error: ‘atomic_lock’ undeclared (first use in this function) Makefile:428: recipe for target '/home/hts/build/tvheadend/build.linux/src/uuid.o' failed
Anyone could help? Thx
Replies (39)
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
Building fine here.
What platform? Anything else in the rest of the build output - from what I can see, atomic_lock is defined in main.c, and defined as an external variable in atomic.h, so it should be fine according to my idiot programming skills...
RE: Problem building latest 4.1.* builds - Added by Nihil Baxter over 9 years ago
Building on raspberry pi 2, till build 4.1.18 all was fine...
RE: Problem building latest 4.1.* builds - Added by Nihil Baxter over 9 years ago
No one knows whats wrong with latest builds? Maybe i have to stay at earlier builds
Its a shame that no one else builds these great software for rpi, just a noob like me ;-)
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
I also have this problem on my RaspberryPi after update from git from 14 days ago.
It looks like there is a problem with atomic64:
When running configure output show:
Checking support/features
checking for cc execinfo.h ... ok
checking for cc -mmmx ... fail
checking for cc -msse2 ... fail
checking for cc getloadavg ... ok
checking for cc atomic64 ... fail
checking for cc lockowner ... ok
checking for cc qsort_r ... ok
checking for cc stime ... ok
checking for cc recvmmsg ... ok
checking for cc sendmmsg ... fail
checking for cc libiconv ... fail
checking for cc libdvben50221 ... ok
checking for py module gzip ... ok
checking for gzip ... ok
checking for bzip2 ... ok
checking for pkg openssl ... ok (detected 1.0.1e)
checking for cc linux/dvb/version.h ... ok
checking for pkg zlib ... ok (detected 1.2.7)
checking for pkg liburiparser ... ok (detected 0.7.5)
checking for pkg avahi-client ... ok (detected 0.6.31)
checking for cc sys/inotify.h ... ok
fetching dvb-scan files ... ok
checking for pkg dbus-1 ... ok (detected 1.6.8)
therefore atomic64 is not supported, but in 'make' it tries to compile atomic64 function.
I also have no skills in writing software, maybe this will help to correct the building process on RaspberryPi arm platforms.
RE: Problem building latest 4.1.* builds - Added by danny skjodt over 9 years ago
Im having same problem trying to build for another arm device atm.
checking for cc atomic64 ... fail
But :
In file included from src/tvhlog.h:31:0,
from src/tvhlog.c:19:
src/atomic.h: In function 'atomic_add_u64':
src/atomic.h:48:23: error: 'atomic_lock' undeclared (first use in this function)
pthread_mutex_lock(&atomic_lock);
RE: Problem building latest 4.1.* builds - Added by Nihil Baxter over 9 years ago
I deleted some lines in atomic.h and build process runs bit longer but breaks at another point. Unfortunately i dont know how to prevent make from compiling atomic64 stuff. Hopefully someone could help...
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
Can you look in build.linux and see what's in build.h, please - specifically, the values of #define ENABLE_ATOMIC64 and #define CONFIG_ATOMIC64.
I'm no guru, but my suspicion is that Pis are ARMv7, which is a 32-bit instruction set - so, unless there's some emulation, uint64 and similar are likely to fail (by my idiot understanding, anyway).
What I can't work out yet is that there IS fallback code in atomic.h, and that was working fine previously with atomic_add_u64(). I can't see why adding atomic_dec_u64 (which was the change which broke things) would then cause atomic_add_u64() to fail. Head-scratch. It probably needs someone who actually understands these things...
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
Hi Prof Yaffle,
unfortunatly there is no ATOMIC64 value in build.h. When writing those values into build.h or add --disable-atomic64 to the configure command the error occurs. I also try to use an older atomic.h from git without success.
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
Nope, I've worked through the code and can't see why it's failing. I'd suggest you raise a new issue and point back to this thread.
From what I can see:
uuid.c: #include "tvheadend.h"
tvheadend.h: #include "tvhlog.h"
and extern pthread_mutex_t atomic_lock
tvhlog.h: #include "atomic.h"
and then atomic.h relies on #if ENABLE_ATOMIC64
(which will be false in build.h because of the detection of 64-bit on a 32-bit platform will fail) and then calls pthread_mutex_lock(&atomic_lock)
instead - which is where the error occurs because atomic_lock
is undefined here. However, main.c defines it pthread_mutex_t atomic_lock
- so it's almost like the extern
definition isn't being honoured.
I still don't understand why it would work before but not now: the new atomic_dec_u64()
is virtually identical to the previous atomic_add_u64()
- and it's atomic_add_u64()
that's failing anyway.
Two thoughts:
1. If you checkout a previously-working version of the code, can you still build it? Specifically, anything prior to commit:83166081, which is when atomic.h was last really touched?
2. Has anything else updated on your system recently - kernel, GCC or similar - that could explain this?
(slightly-informed guessing on my part, but guessing nevertheless).
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
Okay, so no ENABLE_ATOMIC64 is the same as it being undefined, which is what I'd expect.
That means the code fails over to the #else in atomic.h, which is where this error then shows up.
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
RaspberryPi kernel is updated to 3.18.14, brings:
"kernel: Bump to 3.18.14
kernel: vcsm: Add ioctl for custom cache flushing
firmware: arm_loader: Add new vpu+qpu multi execute api
firmware: arm_loader: Set the SPI clock in DT to core_freq"
[[https://github.com/raspberrypi/firmware/commit/70b05985cf2b2b893bc6e55b12794f32857a78dd]]
As I have to figure out how to get an older checkout, I can not say now, if older verion will work, but I will try that.
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
OK, I have to go back to
git checkout 496f14d
and TVHeadend runs. Seems there are some things broken for arm platform.
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
If commit:496f14d works, then that's after the last change to atomic.h - which means I was looking in the wrong place - which explains why I couldn't see what was wrong...
Can you do a binary split to see which commit broke things? You know that current master fails, and you know that commit:496f14d works, so that's only 50-odd commits in between. atomic.h was altered with commit:10e02ffd if that's somewhere to start... the same commit introduced the reference to atomic.h in tvhlog.h. That's almost certainly what broke things.
Try checking out commit:4fdf0c57 and see if that works - and then commit:10e02ffd to see if that then breaks.
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
Sorry, missed to mention that first going back to commit:1459c2c thats first befor atomic_dec_u64 showed up in commit:c74d73c according to "git log --online", thats work for atomic64 compilation but another error for exitjs show later in compilation. Therefore i go back to commit:496f14d, one before commit:c5a177d.
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
The logic still holds: if you can work out which specific commit broke it then it'll make a lot easier to get it fixed.
If you're not aware how (apologies if you are!), a binary split works roughly like this:
- Check out a known-good version ('A') and build successfully.
- Check out a known bad one ('B') and watch it fail.
- Take the one in between ('C'), and try that - if it works, you know the fault appeared between B and C and if it fails the fault is between C and A, so split in half again as appropriate.
... keep going until you find where it breaks.
git-bisect might help.
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
I do some tests for compiling, going back to find a working version.
You can find that in the attached file.
Looks like there are two different failures in compiling. atomic64 is introduced in commit:8805360, but in that version an error exitjs.c occures.
That will not show up in commit:812d3ab
As I not verry familiar with 'git bisect' and how to use it, the output from that is at the end of that file.
tvhe_log.txt (7.88 KB) tvhe_log.txt |
RE: Problem building latest 4.1.* builds - Added by blue note over 9 years ago
Chef Denker wrote:
I do some tests for compiling, going back to find a working version.
You can find that in the attached file.
Looks like there are two different failures in compiling. atomic64 is introduced in commit:8805360, but in that version an error exitjs.c occures.
That will not show up in commit:812d3abAs I not verry familiar with 'git bisect' and how to use it, the output from that is at the end of that file.
Thanks for doing this, I've just run into this error myself.
If we want the latest that still compiles, how do we pull that version?
thx
RE: Problem building latest 4.1.* builds - Added by Prof Yaffle over 9 years ago
perexg has just changed where atomic_lock is defined - it should get picked up properly now (commit:d455fcf7). Please try to build and see what happens.
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
Works fine now.
No errors when compiling from master tree.
Thank you!
RE: Problem building latest 4.1.* builds - Added by Nihil Baxter over 9 years ago
How did you manage that? Now i stuck with next error:
In file included from /usr/include/arm-linux-gnueabihf/sys/ucontext.h:25:0, from /usr/include/signal.h:359, from src/main.c:26: /usr/include/signal.h:55:0: error: unterminated #ifdef /usr/include/signal.h:23:0: error: unterminated #ifndef In file included from src/main.c:26:0: /usr/include/signal.h:371:8: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int’ /usr/include/signal.h:371:8: error: stray ‘@’ in program /usr/include/signal.h:375:2: error: invalid preprocessing directive #ifdeh /usr/include/signal.h:378:1: error: expected identifier or ‘(’ before ‘/’ token /usr/include/signal.h:378:1: error: missing terminating " character /usr/include/signal.h:379:1: error: stray ‘`’ in program /usr/include/signal.h:381:57: error: stray ‘\17’ in program /usr/include/signal.h:381:57: error: stray ‘`’ in program /usr/include/signal.h:383:1: error: expected identifier or ‘(’ before ‘/’ token /usr/include/signal.h:389:1: error: unknown type name ‘exterk’ /usr/include/signal.h:389:1: error: stray ‘\32’ in program /usr/include/signal.h:389:43: error: unknown type name ‘_sighandlerOt’ /usr/include/signal.h:392:24: error: missing binary operator before token "!" /usr/include/signal.h:55:0: error: unterminated #ifdef /usr/include/signal.h:23:0: error: unterminated #ifndef In file included from /usr/include/errno.h:36:0, from src/main.c:27: /usr/include/arm-linux-gnueabihf/bits/errno.h:47:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘extern’ src/main.c: In function ‘doexit’: src/main.c:200:5: error: implicit declaration of function ‘pthread_kill’ [-Werror=implicit-function-declaration] src/main.c: In function ‘main’: src/main.c:1057:3: error: implicit declaration of function ‘pthread_sigmask’ [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors Makefile:441: recipe for target '/home/hts/build/tvheadend/build.linux/src/main.o' failed make[2]: *** [/home/hts/build/tvheadend/build.linux/src/main.o] Error 1 make[2]: Leaving directory '/home/hts/build/tvheadend' debian/rules:11: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/home/hts/build/tvheadend' debian/rules:5: recipe for target 'build' failed make: *** [build] Error 2
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
I dont build TVHeadend using "make install"
First I clean my tvheadend-Folder
"make clean" or "make districlean"
than do a git update
"git checkout master" or "git pull"
compilation
"./configure --disable..."
followed by
"make"
If make runs without failure, simple start tvheadend by using
"build.linux/tvheadend".
Thats all.
RE: Problem building latest 4.1.* builds - Added by Nihil Baxter over 9 years ago
OK, i tried that, but got same error. What did you --disable in configure?
Normally i use only autobuild script, which did its job well.
Seems it is somewhere system related, something with include function (/usr/include/signal), but i changed nothing on my system.
On my other machine (bananapro) autobuilding runs fine now.....
RE: Problem building latest 4.1.* builds - Added by Anonymous over 9 years ago
I still have the same issue with nightly builds on the PI, started from version 4.1.18
Updating e7b5e7f..afb044d Fast-forward src/plumbing/transcoding.c | 8 ++++++-- src/tvhlog.h | 2 +- support/css.py | 5 +++-- 3 files changed, 10 insertions(+), 5 deletions(-) Checking support/features checking for cc execinfo.h ... ok checking for cc -mmmx ... fail checking for cc -msse2 ... fail checking for cc getloadavg ... ok checking for cc atomic64 ... fail checking for cc lockowner ... ok checking for cc qsort_r ... ok checking for cc stime ... ok checking for cc recvmmsg ... ok checking for cc sendmmsg ... ok checking for cc libiconv ... fail checking for cc libdvben50221 ... ok checking for py module gzip ... ok checking for gzip ... ok checking for bzip2 ... ok checking for pkg openssl ... ok (detected 1.0.1e) checking for cc linux/dvb/version.h ... ok checking for cc libhdhomerun/hdhomerun.h ... fail checking for pkg zlib ... ok (detected 1.2.7) checking for pkg liburiparser ... ok (detected 0.7.5) checking for pkg avahi-client ... ok (detected 0.6.31) checking for cc sys/inotify.h ... ok fetching dvb-scan files ... ok checking for pkg dbus-1 ... ok (detected 1.6.8) Compiler: Using C compiler: cc Using LD flags: -ldvben50221 -ldvbapi -lucsi Build for arch: armv6l Binaries: Using PYTHON: python Using GZIP: gzip Using BZIP2: bzip2 Options: cwc yes capmt yes constcw yes linuxdvb yes satip_server yes satip_client yes hdhomerun_client no hdhomerun_static no iptv yes tsfile yes dvbscan yes timeshift yes trace yes imagecache yes avahi yes zlib yes libav yes libffmpeg_static yes libffmpeg_static_x264 yes inotify yes epoll yes uriparser yes ccache no tvhcsa yes bundle no dvbcsa no dvben50221 yes kqueue no dbus_1 yes android no tsdebug no gtimer_check no execinfo yes getloadavg yes lockowner yes qsort_r yes stime yes recvmmsg yes sendmmsg yes libdvben50221 yes py_gzip yes bin_gzip yes bin_bzip2 yes ssl yes linuxdvbapi yes upnp yes inotify_h yes linuxdvb_ca yes mpegts yes mpegts_dvb yes Packages: openssl 1.0.1e zlib 1.2.7 liburiparser 0.7.5 avahi-client 0.6.31 dbus-1 1.6.8 Installation paths: Prefix: /usr/local Binaries: ${prefix}/bin Libraries: ${prefix}/lib Data files: ${prefix}/share Man pages: ${datadir}/man Final Binary: /home/pi/tvheadend/build.linux/tvheadend Tvheadend Data Directory: /usr/local/share/tvheadend make -f Makefile.webui all make[1]: Entering directory '/home/pi/tvheadend' make -f Makefile.webui WEBUI=std compile-std make[2]: Entering directory '/home/pi/tvheadend' WEBUI std finished make[2]: Leaving directory '/home/pi/tvheadend' make -f Makefile.webui WEBUI=debug compile-debug make[2]: Entering directory '/home/pi/tvheadend' WEBUI debug finished make[2]: Leaving directory '/home/pi/tvheadend' make[1]: Leaving directory '/home/pi/tvheadend' CC src/version.o CC src/uuid.o Makefile:441: recipe for target '/home/pi/tvheadend/build.linux/src/uuid.o' failed make -f Makefile.webui all make[1]: Entering directory '/home/pi/tvheadend' make -f Makefile.webui WEBUI=std compile-std make[2]: Entering directory '/home/pi/tvheadend' WEBUI std finished make[2]: Leaving directory '/home/pi/tvheadend' make -f Makefile.webui WEBUI=debug compile-debug make[2]: Entering directory '/home/pi/tvheadend' WEBUI debug finished make[2]: Leaving directory '/home/pi/tvheadend' make[1]: Leaving directory '/home/pi/tvheadend' CC src/uuid.o Makefile:441: recipe for target '/home/pi/tvheadend/build.linux/src/uuid.o' failed
RE: Problem building latest 4.1.* builds - Added by Chef Denker over 9 years ago
I disable some protocols I did not need:
"/configure --arch=ARCH --enable-libffmpeg_static --disable-hdhomerun_client --disable-iptv --disable-satip_client --disable-satip_server && make"
@Fresh Mike
did you "make clean" or "make distclean" in the first place.
RE: Problem building latest 4.1.* builds - Added by Anonymous over 9 years ago
aah, yepp that did the trick Thanks!