Posts by shiznix

  • Build failure for 8.90.004 Generic x64 - broken toolchain?

    Gentoo Linux

    Is LE not distro agnostic?

    I thought that was the whole idea behind building it's own toolchain?

    EDIT: Disabling the use of 'Gold' linker in 'distributions/LibreELEC/options' allows sysutils/open-vm-tools to build

    I'm unable to disable 'Gold' for the entire image build as some packages fail to build without it enabled.

    Not really sure why but I'm suspecting it has a lot to do with my host system using the standard GNU BFD linker and LE defaulting to use GOLD.

    As the build process seemingly steps out of it's toolchain randomly, I'm guessing the build doesn't like switching back and forth to use different linkers.

    Using standard BFD linker because it's the default for Gentoo but also because of 10238 – Gold linker does not resolve symbols using indirect dependencies

  • Build failure for 8.90.004 Generic x64 - broken toolchain?

    Thanks CvH.

    The next failure is packages/sysutils/open-vm-tools:

    Any ideas?

  • Build failure for 8.90.004 Generic x64 - broken toolchain?

    Success finally! :)

    Although libgcrypt is a package that is installed into the LE image, it's not part of the toolchain and qemu was erroneously enabling libgcrypt support because it detected it as being present on the host system doing the build.

    Editing packages/tools/qemu/package.mk to '--disable-gcrypt' allows qemu to build.

    Also, it helps a great deal to use 'V=1' on the build command line when debugging build failures like this:

    Code
    PROJECT=Generic ARCH=x86_64 make V=1 image

  • Build failure for 8.90.004 Generic x64 - broken toolchain?

    Following Compile [LibreELEC.wiki] instructions, LibreELE-8.90.004 fails to build:

    Code
    PROJECT=Generic ARCH=x86_64 make image
    Code
    ...
  LINK    tests/qemu-iotests/socket_scm_helper
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find -lgcrypt
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find -lgpg-error
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find -lgpg-error
collect2: error: ld returned 1 exit status
make[1]: *** [/home/rick/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/qemu-2.12.0/rules.mak:121: tests/qemu-iotests/socket_scm_helper] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/rick/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/qemu-2.12.0/.x86_64-pc-linux-gnu'
make: *** [Makefile:12: image] Error 2

    In trying to debug I couldn't help but notice LE's build process constantly jumps in and out of it's toolchain randomly.

    For example, sometimes it uses the system's GCC (7.3.0) and sometimes it uses the toolchain's GCC (8.2.0).

    Sometimes it builds with the toolchain GCC, then within the same package build uses the system LD (?!).

    Any ideas or do the build scripts need a re-write?

    Note that I don't even want to build the image, just update the kernel enough to support laptop's mouse on current hardware but have been pointed down this dead-end road :(

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Unsure if it's some library path munging on libgcrypt's build, or if the problem lies with qemu.

    Or if the problem is that sometimes the build system uses the system GCC (7.3.0), and sometimes it uses the LE toolchain GCC (8.2.0).

    Deleting the qemu dependency gets the build moving forward again so maybe it's not really necessary but instead simply an optional dep used for testing?

    EDIT: Qemu not optional, but it's the only broken package that's stopping the image being built.

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Well OK, if the recommended/supported way is the entire toolchain and project must be built just to upgrade the kernel, then that's fine.

    Unfortunately the image can't be built :(

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Quote from chewitt

    I wouldn't waste time trying to bump the kernel in an 8.2.5 image; it's not simple so easier to start with the 004 alpha release (which is stable) and work from there. Just edit projects/Generic/linux/linux.x86_64.conf and enable whatever extra kernel driver module is required before building the image (or build an image, edit the kernel, rebuild and only the kernel will be rebuilt).

    No dice unfortunately :(

    The notepad's Alps trackpad hardware still fails using the new 004 alpha 4.18 kernel.

    Digging deeper and it looks like the following needs to be enabled in LE's kernel to make it work:

    CONFIG_I2C_HID=m

    CONFIG_HID_ALPS=m

    CONFIG_MFD_INTEL_LPSS_ACPI=y

    CONFIG_MFD_INTEL_LPSS_PCI=y


    So I repeated the same steps of rebuilding the kernel with those options and recreating the squashfs image with kernel modules included.

    But as mentioned before the new KERNEL and SYSTEM squashfs image fail to boot with "Unable to mount root fs on unknown-block(1,0)".

    Is there some step I'm missing?

    Cheers :)

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Excellent! Have upgraded to 004 alpha with no problems.

    Simply upgrading to the new 004 alpha release (which uses 4.18 kernel), might be enough on it's own to get the Alps trackpad working.

    AFAICT the Alps trackpad hardware has problems in older kernels with the way it interacts with the 'i8042' controller and 'i2c-hid'.

    Fingers crossed, will be able to test later this week.

    For the wifi hardware:

    08:00.0 Network controller: Broadcom Limited BCM43224 802.11a/b/g/n (rev 01)

    en:users:drivers:brcm80211 [Linux Wireless]
    Hardware is only supported by 'brcmsmac' kernel module, which doesn't support AP mode :(

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Thanks Chewitt for the super prompt reply and apologies for my lag.

    Please disregard my previous message, my comparison was mistakenly based on two separate sets of hardware.

    It's either a limitation of the hardware or the Linux drivers for Broadcom that don't allow the wifi card to become a hotspot.

    Anyway, while it's a nice to have scenario it's not something that I'm willing to chase up at this time.

    What's become more pressing is getting the laptop's mouse trackpad to work in LE.

    It's an Alps trackpad, known to not work in old Linux kernels (LE uses 4.11 kernel).

    Upgrading kernels is easy but I've not been able to do it in LE as it seems to be too deeply tangled with build scripts that require the entire project to be (re-)built.

    Updated kernel to 4.18 using master checkout of http://LibreELEC.tv/projects/Generic/linux/linux.x86_64.conf, inserted it's kernel modules into the squashfs image but Syslinux oopses the kernel on boot complaining it's "Unable to mount root fs on unknown-block(1,0)".

    So I'm probably missing some important step somewhere, but may have to wait until a new version of LE is released with a current kernel before it can be used.

    Cheers :)

  • Enabling 'tethered' wireless access point doesn't work in LibreELEC but DOES work in OpenELEC?

    Hi,

    I recently upgraded from OpenELEC (OE) to LibreELEC (LE) because scraper addons had stopped working in OE.

    On the same hardware however, LE is unable to create a wifi tethered hotspot whereas this 'just works' on OE.

    Error from ~/.kodi/temp/kodi.log when attempting to create hotspot:

    01:01:48.837 T:140483840939776 ERROR: ## LibreELEC Addon ## connman::set_technologies ## ERROR: (DBusException('Not supported',))

    01:01:48.837 T:140483840939776 ERROR: Traceback (most recent call last):

    File "/home/chewitt/LibreELEC.82-images/build.LibreELEC-Generic.x86_64-8.2.5/LibreELEC-settings-0768930/.install_pkg/usr/share/kod

    i/addons/service.libreelec.settings/resources/lib/modules/connman.py", line 965, in set_technologie

    File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 145, in __call__

    File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking

    DBusException: net.connman.Error.NotSupported: Not supported


    Any ideas?

    Thanks :)