On Wed, Jul 27, 2005 at 10:34:07AM -0400, Wayne Steenburg wrote:
O
then if I do an 'up2date --dry-run mythtv-suite' I end up with:
Unresolvable chain of dependencies:
mythtv-suite-0.18.1-55.at http://mythtv-suite-0.18.1-55.at requires
mythplugins = 0.18.1
If I look in http://atrpms.net/dist/el4/mythplugins/ everything seems to
be
x86_64 which sadly isn't my architecture!
Am I looking in the wrong place?
No, mythplugins requires transcode and transcode only builds for el4-x86_64
Axel, is this a change from how this was previously done?
No, previously transcode would not build anymore for any distro due to
libquicktime/ffmpeg, so the mythplugins were built w/o
transcode. After transcode would build for 12/14 distributions I
switched it on again.
I have all the mythplugins for el4 i386 compiled without transcode
support. I don't mind not being able to rip a dvd or transcode a
recording, but not having mythmusic, mythdvd, mythgame, etc, would
kind of suck.
Yes, the fact that these are bundled in one tar files now makes it
rather hard. Before 0.18 these were separate and a failing mythdvd
would not affect the rest.
A workaround would be to introduce more switches to the specfile, but
perhaps finidng the reason transcode fails would be easier ...
I'm currently helping a friend redo his mythbox using CentOS 4 and
I'll need to bring over some loose rpms from apt's cache to help him
finish.
Are your build logs publicly available?
No, unfortunately not. They should become so, and I hope to find time
in the next eaons to redo the whole website/repo creation thing (that
last a couple of eaons by themselves ...).
I'm no expert, but I'd be happy to take a look at them. I found
transcode for el4 i386 at one of those other repos so I know it
can compile. But will it run properly... :)
The builds end with
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -DMOD_PATH=\/usr/lib/transcode\
-I.. -I../src -I../libtc -I/usr/include -I../libac3 -I../avilib -I/usr/include
-I/usr/include -I/usr/include -I/usr/include/libxml2 -I../libvo -I/usr/include
-I/usr/include -I/usr/include -DUSE_XIO -I../libxio -Wall -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables -MT import_im.lo -MD -MP -MF .deps/import_im.Tpo
-c import_im.c -o import_im.o /dev/null 21
/bin/sh ../libtool --mode=link gcc -Wall -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables -o import_im.la -rpath /usr/lib/transcode
-module -avoid-version import_im.lo -lMagick -lz -lm -lm -lm -lz -ldl
libtool: link: cannot find the library `/usr/lib/libxml2.la'
make[3]: *** [import_im.la] Error 1
The reason is that Red Hat manically kills *.la files, but this seems
to only work if all *.la files are removed. When a project still gets
to ship its *.la files the dependencies are checked through the la
files and fail. I suspect ImageMagick.
Try to rebuild, it should stop at the same spot. If not, you'll have
found the fix :)
--
Axel.Thimm at ATrpms.net
pgp98PyRot6Jq.pgp
Description: PGP signature
___
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users
