Build problem with 16.1 toolchain

[prl]

Initially I had no difficulty building enigma2 with the 16.1 toolchain, but I just tried a build today after not having done one for a while and lib/base/e2avahi.cpp caused a bunch of undefined references when the loader ran:

Code: Select all

avahi_age
avahi_client_errno
avahi_client_free
avahi_client_get_host_name
avahi_client_get_state
avahi_client_new
avahi_entry_group_add_service
avahi_entry_group_commit
avahi_entry_group_free
avahi_entry_group_new
avahi_service_browser_free
avahi_service_browser_get_client
avahi_service_browser_new
avahi_service_resolver_free
avahi_service_resolver_get_client
avahi_service_resolver_new
avahi_strerror

Anyone got any ideas?

[peteru]

What version of the toolchain are you using?

I may need to build an updated release.

[prl]

What version of the toolchain are you using?
...

beyonwizt4-x86_64-mips32el-toolchain-16.1.20161011.sh

If a new toolchain is needed, remember that my setup lacks some CPU capabilities:

Code: Select all

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     P7550  @ 2.26GHz
stepping	: 10
microcode	: 0x60b
cpu MHz		: 2255.197
cache size	: 3072 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl pni monitor ssse3 sse4_1 lahf_lm
bogomips	: 4510.39
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

[prl]

To make sure that the updates since I last did a build hadn't somehow got the make state out of kilter, i did a

make distclean

and then configure & make. Got the same loader errors.

[peteru]

What do you mean when you say "loader errors"?

The messages you posted are a bit out of context. I assume you don't mean linker errors, although if you do, it would be important to see the arguments to the linker.

[peteru]

I uploaded the latest SDK and posted an announcement, in case it helps with this.

[prl]

What do you mean when you say "loader errors"?

The messages you posted are a bit out of context. I assume you don't mean linker errors, although if you do, it would be important to see the arguments to the linker.

Yes, linker (ld) errors.

The make script doesn't print the arguments to the run of the linker.

Here's an abbreviated view of the errors I see:

Code: Select all

  CXXLD    enigma2
../lib/base/libenigma_base.a(e2avahi.o): In function `avahi_set_timer(AvahiTimeout*, timeval const*)':
/home/prl/easy-ui-4/lib/base/e2avahi.cpp:346: undefined reference to `avahi_age'
...
../lib/base/libenigma_base.a(e2avahi.o): In function `e2avahi_close()':
/home/prl/easy-ui-4/lib/base/e2avahi.cpp:406: undefined reference to `avahi_client_free'
../lib/base/libenigma_base.a(e2avahi.o): In function `e2avahi_resolve_cancel(char const*, void (*)(void*, int, char const*, char const*, char const*, unsigned short), void*)':
/home/prl/easy-ui-4/lib/base/e2avahi.cpp:440: undefined reference to `avahi_service_browser_free'
collect2: error: ld returned 1 exit status
make[3]: *** [enigma2] Error 1

I don't think that omits anything useful. All the other messages are simply for different source code lines in e2avahi.cpp and the various different missing labels.

I'll give the newer version of the toolchain a go, and see if that helps. I'm also going to be looking at IanSav's rework of Setup.py, so it may be a day or so before I have results on the new toolchain to report on.

[peteru]

Sounds like a missing or old Avahi library. You'll definitely need to run autoconf/configure again. You may also want to run make with arguments that will show the commands being executed. I can't quite recall what it is, maybe "Q=" or "V=1"

[peteru]

It's "make V=1"

[prl]

Still using the 16.1.20161011 toolchain, but I tried doing an autogen/configure and the configure gave an error of:

Code: Select all

checking for GSTREAMER... no
configure: error: Package requirements (gstreamer-1.0 gstreamer-pbutils-1.0) were not met:

No package 'gstreamer-1.0' found
No package 'gstreamer-pbutils-1.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GSTREAMER_CFLAGS
and GSTREAMER_LIBS to avoid the need to call pkg-config.

That doesn't look encouraging, either.

Perhaps I should try the new toolchain.

[prl]

I've upgraded my Ubuntu installation from the fairly ancient 14.x to 16.04, in the hope that that would improve things.

It didn't. The make with either the 16.1.20161011and 16.1.20170311 toolkits dies earlier in the make process, with

Code: Select all

make[4]: Entering directory '/media/sf_Beyonwiz/T3/enigma2/easy-ui-4/lib'
make[4]: *** No rule to make target '/usr/share/swig2.0/swig.swg', needed by 'python/enigma_python.cpp'.  Stop.
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/media/sf_Beyonwiz/T3/enigma2/easy-ui-4/lib'
Makefile:2517: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/media/sf_Beyonwiz/T3/enigma2/easy-ui-4/lib'
Makefile:1066: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/media/sf_Beyonwiz/T3/enigma2/easy-ui-4/lib'
Makefile:597: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/media/sf_Beyonwiz/T3/enigma2/easy-ui-4'
Makefile:435: recipe for target 'all' failed
make: *** [all] Error 2

That log is from a make with the 16.1.20170311 toolkit. The target file complained about, /usr/share/swig2.0/swig.swg doesn't exist (and neither does its directory /usr/share/swig2.0). The installed swig in the Ubuntu distro is 3.0.8, and /usr/share/swig3.0/swig.swg does exist. Adding V=1 to the build doesn't give any further useful information about the error.

Is there any make target that cleans more thoroughly than "make distclean"?

Is it likely to work if I create a symlink called swig2.0 that points to the swig3.0 directory?

[prl]

OK, I've been able to get around the dependency problem by changing all the occurrences of /usr/share/swig2.0 in lib/.deps/python/enigma_python.Pcpp to /usr/share/swig3.0 and building with the 20170311 toolchain (or at least, I've generated an enigma2, I haven't tried it out yet).

I haven't worked out why lib/.deps/python/enigma_python.Pcpp isn't removed by a "make distclean", nor how to get it cleaned (maintainer-clean, perhaps).

Anyway, if I remove lib/.deps/python/enigma_python.Pcpp by hand, the 20170311 toolchain rebuilds it correctly with swig3.0 dependencies.

[peteru]

If you are doing out-of-tree builds (and you should be), then just blow away the build directory and run configure again.

If you are building in your source tree, get git to give you a clean tree by deleting things and then doing either git checkout or git reset.

[prl]

If you are doing out-of-tree builds (and you should be), ...

Is there a configure option for that?

[peteru]

If you are doing out-of-tree builds (and you should be), ...

Is there a configure option for that?

Sort of. It's how you run configure. For example:

Code: Select all

mkdir enigma2
cd enigma2
../easy-ui-4/configure <options>

That builds everything in an enigma2 directory, parallel to the source code directory. You still need to use autotools to create configure in the source dir.

[prl]

OK, thanks. I'll change to doing it like that. It's a lot cleaner.