Discussion:
[PATCH] configure: fix detection of mp4.h
Johannes Weißl
2011-04-18 00:48:38 UTC
Permalink
mp4.h is just assumed to be there if mp4v2/mp4v2.h could not be found.
This could be a fix for Gentoo Bug 323975 [1].

[1] http://bugs.gentoo.org/show_bug.cgi?id=323975
---
configure | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index dee8b01..1ecad56 100755
--- a/configure
+++ b/configure
@@ -284,8 +284,13 @@ check_roar()

check_mp4()
{
- check_header mp4v2/mp4v2.h
- USE_MPEG4IP=$?
+ USE_MPEG4IP=1
+ if check_header mp4v2/mp4v2.h
+ then
+ USE_MPEG4IP=0
+ else
+ check_header mp4.h || return $?
+ fi
check_header neaacdec.h &&
check_library MP4 "" "-lmp4v2 -lfaad -lm"
return $?
--
1.7.4.4
Gregory Petrosyan
2011-04-18 08:47:48 UTC
Permalink
Post by Johannes Weißl
mp4.h is just assumed to be there if mp4v2/mp4v2.h could not be found.
This could be a fix for Gentoo Bug 323975 [1].
[1] http://bugs.gentoo.org/show_bug.cgi?id=323975
There are, in fact, 2 bugs reported there:

1) Configuring cmus with CONFIG_MP4=y, and not having <neaacdec.h>. This
results in configure failure; this is not a bug at all.

2) Compiling cmus with config_mp4() that finished successfully: compilation
failed due to <mp4.h> being absent. This one I don't understand: on what
system 'check_library MP4 "" "-lmp4v2 -lfaad -lm"' works, but '#include
<mp4.h>' does not? Seems a bit weird — can you please explain how this is
possible?

Gregory
Johannes Weißl
2011-04-18 09:27:08 UTC
Permalink
Hello Gregory,
Post by Gregory Petrosyan
Post by Johannes Weißl
mp4.h is just assumed to be there if mp4v2/mp4v2.h could not be found.
This could be a fix for Gentoo Bug 323975 [1].
[1] http://bugs.gentoo.org/show_bug.cgi?id=323975
1) Configuring cmus with CONFIG_MP4=y, and not having <neaacdec.h>. This
results in configure failure; this is not a bug at all.
Yes, this is a problem with the ebuild. It would probably be better to
just specify CONFIG_MP4=a (for all others too), so the build doesn't
fail because of one dependency problem. I already wrote the maintainer.
Post by Gregory Petrosyan
2) Compiling cmus with config_mp4() that finished successfully: compilation
failed due to <mp4.h> being absent. This one I don't understand: on what
system 'check_library MP4 "" "-lmp4v2 -lfaad -lm"' works, but '#include
<mp4.h>' does not? Seems a bit weird — can you please explain how this is
possible?
Well, not really. Either the system is a bit broken (header deleted?),
or the detection of <mp4v2/mp4v2.h> fails for some reason (too bad our
build system makes it nearly impossible to debug this :-)).
In either case, configure should detect this oddness instead of make
failing.


Johannes
Gregory Petrosyan
2011-04-18 09:54:33 UTC
Permalink
Post by Johannes Weißl
Post by Gregory Petrosyan
Post by Johannes Weißl
mp4.h is just assumed to be there if mp4v2/mp4v2.h could not be found.
This could be a fix for Gentoo Bug 323975 [1].
[1] http://bugs.gentoo.org/show_bug.cgi?id=323975
1) Configuring cmus with CONFIG_MP4=y, and not having <neaacdec.h>. This
results in configure failure; this is not a bug at all.
Yes, this is a problem with the ebuild. It would probably be better to
just specify CONFIG_MP4=a (for all others too), so the build doesn't
fail because of one dependency problem. I already wrote the maintainer.
Thanks!
Post by Johannes Weißl
Post by Gregory Petrosyan
2) Compiling cmus with config_mp4() that finished successfully: compilation
failed due to <mp4.h> being absent. This one I don't understand: on what
system 'check_library MP4 "" "-lmp4v2 -lfaad -lm"' works, but '#include
<mp4.h>' does not? Seems a bit weird — can you please explain how this is
possible?
Well, not really. Either the system is a bit broken (header deleted?),
or the detection of <mp4v2/mp4v2.h> fails for some reason (too bad our
build system makes it nearly impossible to debug this :-)).
In either case, configure should detect this oddness instead of make
failing.
Yeah, your patch is sound, I'll definitely merge it. I just doubt it will fix
that exact issue — guess we'll see!

Gregory

Loading...