Vorbis dev - Aug 2004 - various patches from Mandrakelinux package

I was looking at the libvorbis 1.0  SRPM of Mandrakelinux, and it contained
some patches which are not included in vorbis 1.1 svn. I'm attaching these
patches here, because it could maybe be interesting to include these
upstream.

(libvorbis-1.1-aliasing.patch is actually a rediffed patch of Mandrakesoft's
one for 1.0 against 1.1 svn).

The author of these patches is Gwenole Beachesne, gbeauchesne at
mandrakesoft.com.

Frederik


-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvorbis-1.0-lib64.patch
Type: text/x-diff
Size: 1453 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040802/c241c291/libvorbis-1.0-lib64.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvorbis-1.1-aliasing.patch
Type: text/x-diff
Size: 1318 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040802/c241c291/libvorbis-1.1-aliasing.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvorbis-1.0rc3-fix-optflags.patch
Type: text/x-diff
Size: 1494 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040802/c241c291/libvorbis-1.0rc3-fix-optflags.bin

On Monday 02 August 2004 16:10, Frederik Himpe wrote:
> libvorbis-1.1-aliasing.patch
ignore this one for now, it's completely b0rken, I will send a new one
later.

I previously forwarded a similar (lib64) patch from
Gwenole for libao which has not been integrated.  It,
and another patch can be seen here:
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/libao/

Also, libogg has two similar patches here:
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/libogg/

These patches add amd64/nacona support, and make it so
that it doesn't override your CFLAGS.

PS - this is the second time I had to send this
because since the stupid mailing list software doesn't
set the Reply-to and you have to change it manually I
accidentally put vorbis@xiph.org the first time :o(

--- Frederik Himpe <fhimpe@telenet.be> wrote:
> I was looking at the libvorbis 1.0  SRPM of
> Mandrakelinux, and it contained
> some patches which are not included in vorbis 1.1
> svn. I'm attaching these
> patches here, because it could maybe be interesting
> to include these
> upstream.
>
> (libvorbis-1.1-aliasing.patch is actually a rediffed
> patch of Mandrakesoft's
> one for 1.0 against 1.1 svn).
>
> The author of these patches is Gwenole Beachesne,
> gbeauchesne at
> mandrakesoft.com.
>
> Frederik
>
>
> > --- libvorbis-1.0/vorbis.m4.lib64	2002-07-09
> 09:08:57.000000000 -0400
> +++ libvorbis-1.0/vorbis.m4	2002-07-25
> 13:56:52.000000000 -0400
> @@ -15,12 +15,37 @@ AC_ARG_WITH(vorbis-libraries,[
> --with-v
>  AC_ARG_WITH(vorbis-includes,[
> --with-vorbis-includes=DIR   Directory where
> libvorbis header files are installed (optional)],
> vorbis_includes="$withval", vorbis_includes="")
>  AC_ARG_ENABLE(vorbistest, [  --disable-vorbistest
>     Do not try to compile and run a test Vorbis
> program],, enable_vorbistest=yes)
>
> +  case $host in
> +  *-*-linux*)
> +    # Test if the compiler is 64bit
> +    echo 'int i;' > conftest.$ac_ext
> +    vorbis_cv_cc_64bit_output=no
> +    if AC_TRY_EVAL(ac_compile); then
> +      case `/usr/bin/file conftest.$ac_objext` in
> +      *"ELF 64"*)
> +       vorbis_cv_cc_64bit_output=yes
> +        ;;
> +      esac
> +    fi
> +    rm -rf conftest*
> +    ;;
> +  esac
> +
> +  case $host_cpu:$vorbis_cv_cc_64bit_output in
> +  powerpc64:yes | s390x:yes | sparc64:yes |
> x86_64:yes)
> +    vorbis_libname="lib64"
> +    ;;
> +  *:*)
> +    vorbis_libname="lib"
> +    ;;
> +  esac
> +
>    if test "x$vorbis_libraries" != "x" ; then
>      VORBIS_LIBS="-L$vorbis_libraries"
>    elif test "x$vorbis_prefix" != "x" ; then
> -    VORBIS_LIBS="-L$vorbis_prefix/lib"
> +    VORBIS_LIBS="-L$vorbis_prefix/$vorbis_libname"
>    elif test "x$prefix" != "xNONE"; then
> -    VORBIS_LIBS="-L$prefix/lib"
> +    VORBIS_LIBS="-L$prefix/$vorbis_libname"
>    fi
>
>    VORBIS_LIBS="$VORBIS_LIBS -lvorbis -lm"
> > --- vorbis/lib/scales.h.orig	2004-08-02
> 15:45:04.362854132 +0200
> +++ vorbis/lib/scales.h	2004-08-02
> 15:50:21.122133795 +0200
> @@ -25,21 +25,47 @@
>  #define VORBIS_IEEE_FLOAT32 1
>  #ifdef VORBIS_IEEE_FLOAT32
>
> -static float unitnorm(float x){
> +static inline float unitnorm(float x){
> +#if 1
> +  union ieee754_float v;
> +  v.f = x;
> +  v.ieee.exponent = IEEE754_FLOAT_BIAS;
> +  v.ieee.mantissa = 0;
> +  return v.f;
> +#else
>    ogg_uint32_t *ix=(ogg_uint32_t *)&x;
>    *ix=(*ix&0x80000000UL)|(0x3f800000UL);
>    return(x);
> +#endif
>  }
>
> -static float FABS(float *x){
> +static inline float FABS(float *x){
> +/* [gb] why would people want this semantics? */
> +static inline float FABS(float *x){ /* UNUSED */
> +#if 1
> +  union ieee754_float v;
> +  v.f = *x;
> +  v.ieee.negative = 0;
> +  return (*x = v.f);
> +#else
>    ogg_uint32_t *ix=(ogg_uint32_t *)x;
>    *ix&=0x7fffffffUL;
>    return(*x);
> +#endif
>  }
>
>  /* Segher was off (too high) by ~ .3 decibel.
> Center the conversion correctly. */
> -static float todB(const float *x){
> +static inline float todB(const float *x){
> +#if 1
> +  union { float f; ogg_int32_t i; } v;
> +  v.f = fabs(*x);
> +  calc = v.i;
> +  calc *= 7.17711438e-7f;
> +  calc += -764.6161886f;
> +  return calc;
> +#else
>    return (float)((*(ogg_int32_t *)x)&0x7fffffff) *
> 7.17711438e-7f -764.6161886f;
> +#endif
>  }
>
>  #define todB_nn(x) todB(x)
> > --- ./configure.in.gege	Fri Jan 11 18:44:20 2002
> +++ ./configure.in	Fri Jan 11 18:46:12 2002
> @@ -75,10 +75,10 @@
>
>  	case $host in
>  	*86-*-linux*)
> -		DEBUG="-g -Wall -W -D_REENTRANT
> -D__NO_MATH_INLINES -fsigned-char"
> -		CFLAGS="-O20 -ffast-math -mno-ieee-fp
> -D_REENTRANT -fsigned-char"
> +#		DEBUG="-g -Wall -W -D_REENTRANT
> -D__NO_MATH_INLINES -fsigned-char"
> +		CFLAGS="$CFLAGS -ffast-math -mno-ieee-fp
> -D_REENTRANT -fsigned-char"
>  #              	PROFILE="-Wall -W -pg -g -O20
> -ffast-math -D_REENTRANT -fsigned-char -fno-inline
> -static"
> -		PROFILE="-Wall -W -pg -g -O20 -ffast-math
> -mno-ieee-fp -D_REENTRANT -fsigned-char -fno-inline"
> +#		PROFILE="-Wall -W -pg -g -O20 -ffast-math
> -mno-ieee-fp -D_REENTRANT -fsigned-char -fno-inline"
>
>  		# glibc < 2.1.3 has a serious FP bug in the math
> inline header
>  		# that will cripple Vorbis.  Look to see if the
> magic FP stack
> @@ -120,9 +120,9 @@
>    		PROFILE=${PROFILE}" -D__NO_MATH_INLINES"
>    		fi;;
>  	*-*-linux*)
> -		DEBUG="-g -Wall -W -D_REENTRANT
> -D__NO_MATH_INLINES -fsigned-char"
> -		CFLAGS="-O20 -ffast-math -D_REENTRANT
> -fsigned-char"
> -		PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
> -fsigned-char";;
> +#		DEBUG="-g -Wall -W -D_REENTRANT
> -D__NO_MATH_INLINES -fsigned-char"
> +		CFLAGS="$CFLAGS -ffast-math -D_REENTRANT
> -fsigned-char";;
> +#		PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
> -fsigned-char";;
>  	sparc-sun-*)
>  		DEBUG="-g -Wall -W -D__NO_MATH_INLINES
> -fsigned-char -mv8"
>  		CFLAGS="-O20 -ffast-math -D__NO_MATH_INLINES
> -fsigned-char -mv8"
> > _______________________________________________
> Vorbis-dev mailing list
> Vorbis-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/vorbis-dev
>



_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com

<200408021700.51505.fhimpe@telenet.be>
Message-ID: <200408021758.45888.fhimpe@telenet.be>

On Monday 02 August 2004 17:00, Frederik Himpe wrote:
> On Monday 02 August 2004 16:10, Frederik Himpe wrote:
> > libvorbis-1.1-aliasing.patch
>
> ignore this one for now, it's completely b0rken, I will send a new one
> later. _______________________________________________
Here is the fixed one, which does compile.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvorbis-1.1-aliasing.patch
Type: text/x-diff
Size: 1332 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040802/c5c09b44/libvorbis-1.1-aliasing.bin

<200408021700.51505.fhimpe@telenet.be>
<200408021758.45888.fhimpe@telenet.be>
Message-ID: <200408031337.47283.msmith@xiph.org>

On Tuesday 03 August 2004 01:58, Frederik Himpe wrote:
> On Monday 02 August 2004 17:00, Frederik Himpe wrote:
> > On Monday 02 August 2004 16:10, Frederik Himpe wrote:
> > > libvorbis-1.1-aliasing.patch
> >
> > ignore this one for now, it's completely b0rken, I will send a new
one
> > later. _______________________________________________
>
> Here is the fixed one, which does compile.
Uses the ieee754.h header unconditionally. Is this header present everywhere?
Needs (at least) testing on linux (I assume you've done this :-) and windows
(which you probably haven't).

I'd guess it'd be easier to import the definitions from that header
directly
into the file, if it isn't a header you can rely on existing everywhere.

Why is the patch needed? From the filename, I'm guessing it's something
to do
with aliasing rules. Was this actually causing problems in practice? Does
this version still compile to efficient code (the whole reason for those
functions was to be very fast) with (at least) gcc and msvc?

Mike

<200408022024.12771.lourens@rainbowdesert.net>
Message-ID: <20040803034100.GB31658@xiph.org>

On Mon, Aug 02, 2004 at 08:24:10PM +0200, Lourens Veen wrote:
> This appears to be the case since June 5th, 2004. Did something go
> wrong with the upgrade to Mailman 2.1.4?
No, we changed the policy deliberately. Sorry to those who appreciated
our lists as a small island of reply-to mangling.

-r

<200408021758.45888.fhimpe@telenet.be>
<200408031337.47283.msmith@xiph.org>
Message-ID: <200408030922.09098.fhimpe@telenet.be>

On Tuesday 03 August 2004 05:37, Michael Smith wrote:
> > > On Monday 02 August 2004 16:10, Frederik Himpe wrote:
> > > > libvorbis-1.1-aliasing.patch
> Uses the ieee754.h header unconditionally. Is this header present
> everywhere? Needs (at least) testing on linux (I assume you've done
this
> :-) and windows (which you probably haven't).
>
> I'd guess it'd be easier to import the definitions from that header
> directly into the file, if it isn't a header you can rely on existing
> everywhere.
>
> Why is the patch needed? From the filename, I'm guessing it's
something to
> do with aliasing rules. Was this actually causing problems in practice?
> Does this version still compile to efficient code (the whole reason for
> those functions was to be very fast) with (at least) gcc and msvc?
I am CC-ing Gwenole Beauchesne, the author of this patch, who will certainly
be able to answer these questions. I have only ported his patch to current
1.1 svn. I presume that this patch maybe makes it safe to use
-fstrict-aliasing.

Frederik

--- Ralph Giles <giles@xiph.org> wrote:
> On Mon, Aug 02, 2004 at 08:24:10PM +0200, Lourens
> Veen wrote:
>
> > This appears to be the case since June 5th, 2004.
> Did something go
> > wrong with the upgrade to Mailman 2.1.4?
>
> No, we changed the policy deliberately. Sorry to
> those who appreciated
> our lists as a small island of reply-to mangling.
Not setting the Reply-to is what'll turn a list into a
small island.  People will reply just to senders and
the list as a whole won't get the benefit, it'll cause
you to miss stuff.  For those that want the mailing
list to work the way it should, it's just more work to
use.  The change in "policy" makes absolutely no
sense, and I've seen it ruin other mailing lists before.



__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

<200408021700.51505.fhimpe@telenet.be>
<200408021758.45888.fhimpe@telenet.be>
<200408031337.47283.msmith@xiph.org>
Message-ID: <Pine.LNX.4.61.0408032155380.586@hani.compact.bogus>

On Tue, 3 Aug 2004, Michael Smith wrote:
>> Here is the fixed one, which does compile.
>
> Uses the ieee754.h header unconditionally. Is this header present
> everywhere?
It's part of glibc (at least >= 2.2.5), but it's not available with
every
libc variant.  dietlibc in particularly doesn't have it.

<200408021700.51505.fhimpe@telenet.be>
<200408021758.45888.fhimpe@telenet.be>
<200408031337.47283.msmith@xiph.org>
Message-ID: <5ADC15B0-E6A6-11D8-A013-000A95A4DC02@kernel.crashing.org>
> Why is the patch needed? From the filename, I'm guessing it's
> something to do
> with aliasing rules. Was this actually causing problems in practice?
> Does
> this version still compile to efficient code (the whole reason for
> those
> functions was to be very fast) with (at least) gcc and msvc?
Don't know if it _was_ causing problems, but it certainly has
the potential to do so, esp. with newer versions of GCC.

This patch won't work with MSVC though, as it relies on
implementation-dependent behaviour in GCC (union elements
are allowed to alias always); there is _no_ portable way
to access an object as a different type, in C.


Segher