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

[depends] alsa-lib: fix typo in configure.in #10840

Merged
merged 1 commit into from Nov 2, 2016

Conversation

@XECDesign
Copy link
Contributor

commented Nov 1, 2016

Description

Change ${host-os} to ${host_os} in tools/depends/target/alsa-lib's configure.in.

Motivation and Context

Currently, if alsa-lib's configure finds ${host_cpu}-${host_os}-gcc, it will set $CC to ${host_cpu}-${host-os}-gcc. Since the variables are not the same (on the raspberry pi ${host-os} is set to arm-unknown, resulting in $CC being a non-existent arm-arm-unknown-..), configure fails when testing the compiler.

How Has This Been Tested?

On a raspberry pi:

cd tools/depends
./configure --with-platform=raspberry-pi --prefix=${HOME}/opt/kodi
make

Without the patch, configure claims the C compiler is not able to produce binaries. With the patch, the build completes.

Screenshots (if appropriate):

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the Code guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the CONTRIBUTING document
  • I have added tests to cover my change
  • All new and existing tests passed
@XECDesign

This comment has been minimized.

Copy link
Contributor Author

commented Nov 1, 2016

@MartijnKaijser

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

@fritsch any idea why we use this ancient alsa lib?

@fritsch

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

We don't use newer features :-) @wsnipex you'd prefer a bump instead?

@XECDesign

This comment has been minimized.

Copy link
Contributor Author

commented Nov 1, 2016

Is it worthwhile opening a PR of changes required to make builds work like it says on the tin natively on ARM (on a pi3 or a chromebook running Raspbian, in my case)?

There is another change needed to get libssh to build, but it's a little less trivial. The issue is that cmake fails with:

Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)

I worked around the problem by modifying the Makefile to pass the necessary -D flags to cmake, but that's not portable. I haven't looked at exactly why cmake doesn't find and set those itself. It would be nice to have a place to put such changes and get a bit of review or suggestions from kodi devs.

Or should I just open a trac issue for that?

@wsnipex

This comment has been minimized.

Copy link
Member

commented Nov 2, 2016

Can you please explain how you build?
Usually building natively (not cross compiling) doesn't use depends at all. And cross compiling with depends shouldn't hit that bug at all, since we explicitly set compilers and flags.

@XECDesign

This comment has been minimized.

Copy link
Contributor Author

commented Nov 2, 2016

For now, I have only built depends.

The plan is to build kodi and set the appropriate PATH and LD_PRELOAD_PATH in the wrapper. I have been advised that Debian's packaging is frowned upon and not supported by kodi, that it's best to use the bundled dependencies where possible. and that the official kodi PPA is the way to go. Porting packages from the PPA back to something that works on Debian is proving to be challenging and still heavily relies on system libraries without kodi's patches.

I have run into issues with replacing the distro's own packages in order to meet the required dependencies. For example, libbluray jumps from 0.6.2 to 0.9.2. Many raspbian/debian packages are linked against it and I don't know whether it's entirely backwards compatible. libgif goes from 4.1.6 to 5.0.5. dcadec comes from an entirely different source.

That means that with each release, I would need to go over all of the dependencies changes, figure out which are safe to upgrade and what to do with those that aren't. I have no way of knowing if all the libraries are backwards compatible or whether the SOVERSION of each library is set correctly. I worry that this will only become more and more time consuming over time as new dependencies and patches are added and versions are bumped.

The short version is that I would like a kodi package for raspbian that has all the patches, most compatibility, but doesn't replace system packages and is more maintainable in the long term.

@wsnipex

This comment has been minimized.

Copy link
Member

commented Nov 2, 2016

ok, makes sense, specially for debian stable based distros. Thanks for the explanation.
The PR here is ok and pending a successful build test from jenkins, will be merged.
For the libssh issue: can you either post a log showing the issue on the forum, or hop on IRC (freenode, #kodi-dev) and ping me?

jenkins build this please

@wsnipex wsnipex merged commit 4e40368 into xbmc:master Nov 2, 2016
2 of 3 checks passed
2 of 3 checks passed
continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
jenkins4kodi You did a great job. Have a cookie.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.