multimedia/libva fails in configure stage, missing file?
madpilot at FreeBSD.org
Mon Jan 5 09:42:05 UTC 2015
On 01/05/15 05:37, Thomas Mueller wrote:
> from Guido Falsi:
>> Mine was just an idea. The cause could be something else. I don't know
>> much about the automake internals. It simply dies with return code one.
>> You should try to diagnose that.
> I don't know how to diagnose automake's failing, except to try on another FreeBSD, NetBSD or Linux system.
> I see some ports that previously didn't list automake or autoconf as dependency now do, such as mutt.
As I suggested you should check the files present in
/usr/local/share/aclocal using "pkg which". There could be stale files
there causing the failure.
Unluckily I could not reproduce the problem here, and it's not appearing
in poudriere or the build cluster. It looks like it's a local problem on
your system, so it needs to be fixed there. You can try another system,
and if you find a way to reproduce the problem report that to me, but if
it just works on another system you will need to find what broke on your
My suspect is there is some old or stale file around on your machine
which causes automake to fail. Finding that isn't easy I know. It has
little debugging help.
Since in the while I updated libva, can you post the output of the
failure with recent libva? I could try to get some more insight with that.
There are ways to get some more output from the tools but they require
to manually run them with appropriate options. you could try running
automake with the -v option by hand in the port's WRKSRC (inside the
software decompressed distribution) and see if that gives some hint
where the failure is.
> It also looks like, if I have a useful system, I really should back it up, the whole OS + packages/ports, to another partition.
This is a completely different subject. I think it is overkill.
Anyway filesystem snapshot could be a better approach, if the filesystem
you're using supports those.
> That would protect not only against a massive portupgrade/portmaster removing and failing to rebuild a port but also against messing the base system with an update that turns out to be buggy.
portmaster has a "-b" option to keep backups of packages before removing
them which you could investigate.
You can also downgrade your ports tree to a known working release using
Another more elaborate option is building your own binary packages with
poudriere and using pkg to upgrade the system from a successful run with
Also using the official binary packages is a viable option you should
consider if you want to avoid this kind of scenario.
These just from the top of my head.
Guido Falsi <madpilot at FreeBSD.org>
More information about the freebsd-ports