With openSUSE 11.4 32bit I was using a copy of Handbrake I’d built from source. Now I’ve updated to 12.1 64bit the binaries don’t work, which doesn’t surprise me. So I re-compiled. And found the build fails.
The first point of failure was related to dbus. The build process was looking for dbus files in /usr/include/dbus and the dbus-*-devel packages put those files in /usr/include/dbus-1.0/dbus. I solved that by making a symlink
mike@continuity:/usr/include$ ls -ld dbus*
lrwxrwxrwx 1 root root 13 Jan 7 12:18 dbus -> dbus-1.0/dbus
drwxr-xr-x 3 root root 4096 Dec 15 21:41 dbus-1.0
The problem I can’t get past is the build fails with
g++: error: ./contrib/lib/liba52.a: No such file or directory
g++: error: ./contrib/lib/libass.a: No such file or directory
g++: error: ./contrib/lib/libdca.a: No such file or directory
g++: error: ./contrib/lib/libdvdnav.a: No such file or directory
g++: error: ./contrib/lib/libdvdread.a: No such file or directory
g++: error: ./contrib/lib/libfaac.a: No such file or directory
g++: error: ./contrib/lib/libfaad.a: No such file or directory
g++: error: ./contrib/lib/libfontconfig.a: No such file or directory
g++: error: ./contrib/lib/libfreetype.a: No such file or directory
g++: error: ./contrib/lib/libmkv.a: No such file or directory
g++: error: ./contrib/lib/libmpeg2.a: No such file or directory
g++: error: ./contrib/lib/libmp3lame.a: No such file or directory
g++: error: ./contrib/lib/libmp4v2.a: No such file or directory
g++: error: ./contrib/lib/libogg.a: No such file or directory
g++: error: ./contrib/lib/libsamplerate.a: No such file or directory
g++: error: ./contrib/lib/libtheora.a: No such file or directory
g++: error: ./contrib/lib/libvorbis.a: No such file or directory
g++: error: ./contrib/lib/libvorbisenc.a: No such file or directory
g++: error: ./contrib/lib/libxml2.a: No such file or directory
g++: error: ./contrib/lib/libbluray.a: No such file or directory
make: *** [HandBrakeCLI] Error 1
All those .a files do exist, but they are in ./contrib/lib64, not ./contrib/lib.
I tried building the .src.rpm from packman, it fails for what I think is essential the same problem, although the error message is different
If I look in the rpm build directory, all the .a files for those libraries are in contrib/lib64
Can anyone explain what why the build process is failing to find these libraries and how to fix it?
I’m aware there are pre-built rpms from packman, I still want to know how to make it build from source. I suspect the problem may not be Handbrake specific.
On 1/7/2012 9:06 AM, mikewillis wrote:
>
> With openSUSE 11.4 32bit I was using a copy of Handbrake I’d built from
> source. Now I’ve updated to 12.1 64bit the binaries don’t work, which
> doesn’t surprise me. So I re-compiled. And found the build fails.
>
> The first point of failure was related to dbus. The build process was
> looking for dbus files in /usr/include/dbus and the dbus-*-devel
> packages put those files in /usr/include/dbus-1.0/dbus. I solved that by
> making a symlink
>
Why do you compile it if its available to download via packman?
–
Windows, supports nearly all software, hardware, and viruses.
Remember the Rauhtage.
But the packman src.rpm doesn’t build either. I got the packman src.rpm hoping that it would build and then I could look at the spec file to try and figure out what it was doing that I wasn’t. But since the .src.rpm doesn’t build…
I’ve tinkered with PKG_CONFIG_PATH and LDFLAGS but to no avail.
Because sometimes I like try and build stuff from source just to see if I can. If it doesn’t work, I like to try and figure out why and learn something from the experience.
Because one of the environments in which I use Linux is one where I’m not always logged in to the same machine but have the same home directory on all of them mounted from a file server. So if I can build something from source I can put it in the my home directory and then use it on any machine.
I have no idea what the project configuration actually means though.
I think the problem here is that I don’t really understand this stuff. More often than not I can get stuff to build from source, but when I can’t get it to work I usually have zero idea why.
I’d say there are differences in the linking, since the Packman build log indicates that it’s putting lib52.a in to contrib/lib where as my build puts it in to contrib/lib64 and then subsequently looks for it in contrib/lib. I’ve no idea why that happens though.
I see that on the Packman build libtool is using the argument “-rpath /home/abuild/rpmbuild/BUILD/HandBrake-0.9.5/build/contrib/lib” and on my build it’s using the argument “-rpath /tmp/hb-trunk/build/contrib//lib64”. So that seems relevant to the problem, but I don’t know how exactly or what to do about it. I’ve found lots of discussions about rpath values and 64bit but don’t understand any of it sufficiently to know if it’s relevant.
I tried building an SVN checkout of Handbrake just for the heck of it. It fails in exactly the same way.
I’ve the same problem here. After putzing around with the pacman spec, ./configure, & lib64 paths, I finally just gave up… Compile/make for HB from svn works just fine on Ubuntu. If you figure it out, please post back - I’d be interested to hear what 12.1 does that breaks a mature app’s build script !! Good luck.
malcolmlewis;2427900 Wrote:
>
> I almost never use rpmbuild (which isn’t supported anyway)
>
In what context is rpmbuild not supported?
AFAIK if a bug is reported from a package built from it, then it would
probably be classified 'wontfix'.
[QUOTE=mikewillis]
malcolmlewis;2427900 Wrote:
>
> Maybe check the project configuration and the build log on PMBS to see
> if there are differences in the linking.
> 'Project Config for Multimedia - Packman Build Service'
> (http://pmbs.links2linux.org/project/prjconf?project=Multimedia)
> http://tinyurl.com/6wqbk7u
>
I have no idea what the project configuration actually means though.
I think the problem here is that I don't really understand this stuff.
More often than not I can get stuff to build from source, but when I
can't get it to work I usually have zero idea why.
I'd say there are differences in the linking, since the Packman build
log indicates that it's putting lib52.a in to contrib/lib where as my
build puts it in to contrib/lib64 and then subsequently looks for it in
contrib/lib. I've no idea why that happens though.
I see that on the Packman build libtool is using the argument "-rpath
/home/abuild/rpmbuild/BUILD/HandBrake-0.9.5/build/contrib/lib" and on my
build it's using the argument "-rpath
/tmp/hb-trunk/build/contrib//lib64". So that seems relevant to the
problem, but I don't know how exactly or what to do about it. I've found
lots of discussions about rpath values and 64bit but don't understand
any of it sufficiently to know if it's relevant.
I tried building an SVN checkout of Handbrake just for the heck of it.
It fails in exactly the same way.
[/quote]
Did you try exporting the SUSE AS NEEDED environment variable before
building?
--
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.1 (x86_64) Kernel 3.1.0-1.2-desktop
up 2 days 3:57, 4 users, load average: 0.01, 0.08, 0.12
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
Too bad on the knee-jerk “why compile if you can DL”, and the “arrival of OBS/PMBS and the cli utility o/c” perspective. I cannot fathom as why that response would address a failure to build. It is grand that there is a compile-cloud as an alternative, it does not however resolve a failed local build.
Unless I missed a step, configure/make remain the primary means to BYOA (build your own app), a key tenant to FOSS/linux. If I find some time later this week, I’ll try and poke at it again.
$ export CPPFLAGS="$(pkg-config --libs --cflags dbus-glib-1)";
$ ./configure --prefix=/where/you/want/to/install/to --launch-jobs=2 --launch && cd build/contrib/ && cp -rv lib64/* lib/ && cd .. && make && make install
Change the 2 to however many cores you have and that is how you build Handbrake from source on 64bit 12.1.
The 0.9.5 source won’t build on 12.1 because of changes that have been made to libnotify. The svn version deals with those changes though (line 5050 in gtk/src/callbacks.c if you’re sufficiently interested).
