2008/2/9 Martin Sourada <martin.sourada@xxxxxxxxx>:
Maybe counting the number of dots in xine-config --version ?
I believe I noticed similar issue when I was compiling gxine against
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
>
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):*** 'xine-config --version' returned -1717986918.1072798105.-1717986918,
checking for XINE-LIB version >= 1.0.1...
but XINE (1072798105.858993459.1076114227)*** was found! If xine-config was correct, then it is bestIt's even stranger that the one in rawhide. The only change I did was
*** 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 ***
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?
Maybe counting the number of dots in xine-config --version ?
--
Paulo Roma Cavalcanti
LCG - UFRJ
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
