On Sat, 2008-02-09 at 12:46 +0200, Ville Skyttä wrote:
> On Saturday 09 February 2008, Paulo Cavalcanti wrote:
>
> > Yes. xine-lib-1.1.10.1 has a broken installation.
> > Its plugins are installed in %{_libdir}/xine/plugins/1.1.10
> > and not in 1.1.10.1 subdir as it should.
>
> Incorrect. 1.1.10 is intentional, it's an upstream change between 1.1.10 and
> 1.1.10.1 which they neglected to mention in release notes (the "patch"
> version (the 4th digit) is not included in the version number in the plugin
> dir name).
>
> If you need it, the path to the plugin dir should be retrieved through one of:
>
> pkg-config libxine --variable=plugindir
> xine-config --plugindir
>
>
> But looking at the gxine error messages, something else seems to be wrong:
>
> > *** 'xine-config --version' returned 1.1.10, but XINE (10.-238096384.0)
> > *** was found!
>
> I have no idea where "10.-238096384.0" comes from; briefly looking at the
> configure script it is a result of:
>
> printf("%d.%d.%d", XINE_MAJOR_VERSION, XINE_MINOR_VERSION, XINE_SUB_VERSION);
>
> ...but in xine.h from 1.1.10.1-1.fc9:
>
> #define XINE_MAJOR_VERSION 1
> #define XINE_MINOR_VERSION 1
> #define XINE_SUB_VERSION 10
>
> ...and on my F-8 x86_64 box (I have no Rawhide box to test with ATM) after
> installing the devel xine-lib-devel:
>
> $ cat t.c
> #include <xine.h>
> #include <stdio.h>
>
> int main()
> {
> printf("%d.%d.%d\n", XINE_MAJOR_VERSION, XINE_MINOR_VERSION,
> XINE_SUB_VERSION);
> }
> $ gcc t.c
> $ ./a.out
> 1.1.10
>
I believe I noticed similar issue when I was compiling gxine against
xine-lib-devel-1.1.9.1 but didn't paid much attention to it, as
xine-lib-devel-1.1.10 fixed it (on F-8).
I tried it with now again on F8 with xine-lib-devel-1.1.10, with
success. After upgrading to xine-lib-devel-1.1.10.1 this error pops out
(it's on F8 i386 with the F8 package from koji):
checking for XINE-LIB version >= 1.0.1...
*** 'xine-config --version' returned -1717986918.1072798105.-1717986918,
but XINE (1072798105.858993459.1076114227)
*** was found! If xine-config was correct, then it is best
*** to remove the old version of XINE. You may also be able to fix the
error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If xine-config was wrong, set the environment variable XINE_CONFIG
*** to point to the correct copy of xine-config, and remove the file
config.cache
*** before re-running configure
no
configure: error: *** Please install xine-lib (devel) first ***
It's even stranger that the one in rawhide. The only change I did was
upgrade xine-lib* to 1.1.10.1-1.fc8... But I really don't understand,
where the numbers come from, since running xine-config --version by hand
returns 1.1.10.1.
Going through configure of gxine show possible root of the problem:
xine_config_major_version=`$XINE_CONFIG $xine_config_args --version | \
sed 's/\([0-9]*\).\([0-9]*\).\([0-9]*\)/\1/'`
xine_config_minor_version=`$XINE_CONFIG $xine_config_args
--version | \
sed 's/\([0-9]*\).\([0-9]*\).\([0-9]*\)/\2/'`
xine_config_sub_version=`$XINE_CONFIG $xine_config_args --version
| \
sed 's/\([0-9]*\).\([0-9]*\).\([0-9]*\)/\3/'`
Looking at the output of xine-config --version | sed 's/\([0-9]*
\).\([0-9]*\).\([0-9]*\)/\1/' shows some buggy behaviour. The output is
1.1, as well as for 2, and for 3 I get 10.1. Looks like the sed
expression is intended to work only with the MAJOR.MINOR.SUB version
string. If I add another .\([0-9]*\) to the expression than the output
is correct.
Any idea how to workaround this so that it works both with x.y.z and
x.y.z.w like version strings?
Martin
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
