Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kodi: updates for Dec 2017 #2182

Merged
merged 9 commits into from
Dec 1, 2017
Merged

kodi: updates for Dec 2017 #2182

merged 9 commits into from
Dec 1, 2017

Conversation

MilhouseVH
Copy link
Contributor

No description provided.

…xz or alsa

ffmpeg[x] will auto-detect lzma (from xz, built by vfs.libarchive) and alsa,
however these packages are built after ffmpeg so that when ffmpeg is rebuilt
these libraries are now found, resulting in a different binary than when clean.

Solution: don't auto-detect.
@Ray-future Ray-future merged commit f022491 into LibreELEC:master Dec 1, 2017
@vpeter4
Copy link
Contributor

vpeter4 commented Apr 12, 2019

@MilhouseVH : Do you know what was the reason for packages/compress/xz/patches/xz-01-init-uninitialized-variables.patch ? I'm doing some cleanup and see no reason for this patch.

@5schatten
Copy link
Contributor

5schatten commented Apr 12, 2019

@vpeter4 maybe it's something like this https://github.com/LibreELEC/LibreELEC.tv/pull/3401/files#diff-df15a36b5ec5c1d300ea4cfbacccea32

Looks like some targets init vars in different ways and so you'll run into problems.

@MilhouseVH
Copy link
Contributor Author

@vpeter unfortunately my mind is a blank on this, but the patch description is "uninitialized variables build error" so I'm guessing it resulted in a build failure of some kind. It may no longer be required due to compiler changes, or because of the updated xz package. I'll try a clean build without it and see what happens.

@vpeter4
Copy link
Contributor

vpeter4 commented Apr 12, 2019

@5schatten: For nano response variable really can can be uninitilized but seems it doesn't trigger any error or warning for Generic. Variable cause is always set.
But in case of xz both variables are set in function called. For Generic I don't see any error. But maybe some arm compiler is doing something different and see that inside function called variable is not set (which can really happen from what I see).
So all good here. Ignoring this package.

@MilhouseVH
Copy link
Contributor Author

Clean builds of RPi/RPi2/Generic all completed successfully, I've no idea why I added that xz patch. Feel free to remove it in your other PR if you like - I'll also test build that PR for RPi/RPi2/Generic overnight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants