[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: xine-lib in rawhide not buildable 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
> 
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]