Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/236Compile warnings in seeking_example.c2017-04-08T10:58:44ZtiCompile warnings in seeking_example.c```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALL...```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1
-DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1
-DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -DHAVE_FLOORF=1 -I. -I.
-I../include -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H -c seeking_example.c
cc: Warning: seeking_example.c, line 194: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 167: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 146: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,val,-1,pcmlength,bigassbuffer);
--------------------^
/bin/ksh ../libtool --mode=link cc -O -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H
-all-static -o seeking_example seeking_example.o ../lib/libvorbisfile.la
../lib/libvorbis.la -lm -logg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/234divide by 0 in psy.c2017-04-08T10:59:08Zroconnordivide by 0 in psy.c```
In bark_noise_hybridmp we have around line 640
if (fixed <= 0) return;
for (i = 0, fi = 0.f; i < (fixed + 1) / 2; i++, fi += 1.f) {
hi = i + fixed / 2;
lo = hi - fixed;
tN = N[hi] + N[-lo];
tX = X[hi] - X[-lo];
tX...```
In bark_noise_hybridmp we have around line 640
if (fixed <= 0) return;
for (i = 0, fi = 0.f; i < (fixed + 1) / 2; i++, fi += 1.f) {
hi = i + fixed / 2;
lo = hi - fixed;
tN = N[hi] + N[-lo];
tX = X[hi] - X[-lo];
tXX = XX[hi] + XX[-lo];
tY = Y[hi] + Y[-lo];
tXY = XY[hi] - XY[-lo];
A = tY * tXX - tX * tXY;
B = tN * tXY - tX * tY;
D = tN * tXX - tX * tX;
R = (A + fi * B) / D;
if (R > 0.f && R - offset < noise[i]) noise[i] = R - offset;
If fixed is 2, D can be 0, and a divide by 0 exception can be thrown.
I guess tXX has to be 0 as well.
There are probably other places where divide by 0's can occur. This happens to
be the first I have found.
Dividing by 0 is almost always an indication of a bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/233Improved DJGPP support2017-04-08T10:58:44ZxaviergonzImproved DJGPP support```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGP...```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGPP */
typedef short ogg_int16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
libvorbis, libvorbisenc, libvorbisfile:
Open up the file /lib/os.h, and near the end, right before the last
#endif, add the following code:
#ifdef DJGPP
# define rint(x) (floor((x)+0.5f))
#endif
Now with proper makefiles, the sources can be compiled properly under DJGPP. (I
tested it and it works under DJGPP once compiled that way)
Thanks for your time
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/232access violations and divides by 0 when usint ov_time_tell() with a not seeka...2017-04-08T10:59:27Zxaviergonzaccess violations and divides by 0 when usint ov_time_tell() with a not seekable stream```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;...```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
As you may easily notice, when the vf is *not* seekable, link = -1, and
therefore in the return, it tries to access vf->vi[-1].rate (access violation),
with the side effect of being that 0, so it also performs a divide by 0
operation and since the result value is a double, it returns a NAN -INF. So it
is clearly a bug, therefore I propose the following change:
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
else
return((double)vf->pcm_offset/vf->vi->rate);
}
which basicaly moves the return in the old function inside so it is only called
if the vf is seekable and adds a new return for non seekable files which
returns the current sample / current section rate, which is, that is, the
current second. Probably it doesn't work properly if the current section is
using a different rate than an old (possible) one, but it is always nicer than
an access violation and a divide by 0 and also a more accurate result than NAN -
INF :)
Thanks
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/230vorbis shared library not built on beos2017-04-08T10:58:44Zshattyvorbis shared library not built on beos```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefin...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libvorbis_la_LDFLAGS = -version-info @V_LIB_CURRENT@:@V_LIB_REVISION@:@V_LIB_AGE@
new version:
libvorbis_la_LDFLAGS = -no-undefined -version-info
@V_LIB_CURRENT@:@V_LIB_REVISION@:@V_LIB_AGE@
With this patch the library builds and works fine. (Tested with vorbis-tools.)
This patch informs libtool that this particular library has no undefined symbols
and so it can be built without problems on beos. (or any other platform without
the ability to compile/use libs with undefined symbols.)
An additional note: libvorbisenc and libvorbisfile both have undefined symbols
and can not be built as shared libraries on beos. They must be linked
statically. They are made as static libraries in the current version and they
work fine if linked to statically.
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/225Various qsort(3) callers pass incomplete comparison functions2017-04-08T10:58:44ZdevetzisVarious qsort(3) callers pass incomplete comparison functions```
Platform: SunOS x 5.9 Generic sun4u sparc SUNW,Ultra-5_10
Library: libvorbis-1.0 (vorbis1_0_public_release)
Arch: sparc-sun-solaris2.9
When calling qsort(3), the comparison function MUST return either -1, 1 or 0.
The following files...```
Platform: SunOS x 5.9 Generic sun4u sparc SUNW,Ultra-5_10
Library: libvorbis-1.0 (vorbis1_0_public_release)
Arch: sparc-sun-solaris2.9
When calling qsort(3), the comparison function MUST return either -1, 1 or 0.
The following files have "optimised" functions that do not return 0 for
equal-valued arguments:
lib/lsp.c
lib/psy.c
lib/sharedbook.c
vq/vqgen.c
The result under Solaris 9 (possibly other versions) is that qsort will call the
function with out-of-bounds arguments when encountering equal-valued
comparisons. oggenc, for example, SEGVs in psy.c[apsort] immediately upon
invocation.
The attached patch tweaks all potentially offending comparison functions, and
Works-For-Me.
/taso
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/224sort32a() in sharedbook.c2017-04-08T10:58:44Zmpxplaysort32a() in sharedbook.c```
It seems the sort32a() routine in sharedbook.c
gives back -1 if a==b . (I think so it should be 0 then)
Is this good?
Some stupid qsort() function (like Watcom's) can freeze with it.
Perhaps you should use the icomp() from the floor...```
It seems the sort32a() routine in sharedbook.c
gives back -1 if a==b . (I think so it should be 0 then)
Is this good?
Some stupid qsort() function (like Watcom's) can freeze with it.
Perhaps you should use the icomp() from the floor1.c
instead of this sort32a() ...
regards
Attila
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/221vorbis.m4 check fails with segfault2017-04-08T10:58:44Zdlehnvorbis.m4 check fails with segfault```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_...```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
(gdb) bt
#0 0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
#1 0x4002ce9b in vorbis_analysis_init () from /usr/lib/libvorbis.so.0
#2 0x080486c6 in main () at t.c:17
The following fixes the segfault but perhaps better return value checking should
be used since this is mainly just a link test vs a functional test:
diff -u -r1.2 vorbis.m4
--- vorbis.m4 13 Jul 2002 02:16:53 -0000 1.2
+++ vorbis.m4 29 Jul 2002 14:36:43 -0000
@@ -54,6 +54,7 @@
#include <stdlib.h>
#include <string.h>
#include <vorbis/codec.h>
+#include <vorbis/vorbisenc.h>
int main ()
{
@@ -62,7 +63,7 @@
vorbis_info vi;
vorbis_info_init (&vi);
- vorbis_encode_init (&vi, 2, 44100, -1, 128, -1);
+ vorbis_encode_init (&vi, 2, 44100, -1, 128000, -1);
vorbis_analysis_init (&vd, &vi);
vorbis_block_init (&vd, &vb);
/* this function was added in 1.0rc3, so this is what we're testing for */
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/220encoder_example segfaults on SunOS 4.x2017-04-08T10:58:44Ztiencoder_example segfaults on SunOS 4.x```
Running the encoder example causes a segfault in libvorbis-1.0 on SunOS 4.1.3.
The gdb back trace is as follows:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GDB is free software ...```
Running the encoder example causes a segfault in libvorbis-1.0 on SunOS 4.1.3.
The gdb back trace is as follows:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (sparc-sun-sunos4.1.3_U1),
Copyright 1995 Free Software Foundation, Inc...
Core was generated by `encoder_example'.
Program terminated with signal 11, Segmentation fault.
#0 0x16ea8 in inspect_error (x0=16, x1=46, y0=653, y1=-1, mask=0x1a4808,
mdct=0x1a4a08, info=0x11e790) at floor1.c:543
543 int base=dy/adx;
(gdb) bt
#0 0x16ea8 in inspect_error (x0=16, x1=46, y0=653, y1=-1, mask=0x1a4808,
mdct=0x1a4a08, info=0x11e790) at floor1.c:543
#1 0x1740c in floor1_fit (vb=0xf7fff708, look=0x1a7a38, logmdct=0x1a4a08,
logmask=0x1a4808) at floor1.c:667
#2 0x1af2c in mapping0_forward (vb=0xf7fff708) at mapping0.c:423
#3 0x7fd0 in vorbis_analysis (vb=0xf7fff708, op=0x0) at analysis.c:47
#4 0x2598 in main () at encoder_example.c:216
(gdb)
libogg and libvorbis are both compiled with gcc 2.95.2. The compiler flags
are the default settings after running configure.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/216libvorbis-1.0 encoder_example seg faults2017-04-08T10:58:44Ztilibvorbis-1.0 encoder_example seg faults```
This is for libvorbis-1.0
I don't know if this is an endian or alignment issue (which may affect more
platforms than just HP-UX, but running the encode_example causes a seg fault.
Here is a gdb backtrace:
$ ./encoder_example < ~/aud...```
This is for libvorbis-1.0
I don't know if this is an endian or alignment issue (which may affect more
platforms than just HP-UX, but running the encode_example causes a seg fault.
Here is a gdb backtrace:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa1.1-hp-hpux9.01"...
Core was generated by `encoder_exampl'.
Program terminated with signal 11, Segmentation fault.
#0 mdct_forward (init=0x4016ffa8, in=0x7b033cc0, out=0x7b033968) at mdct.c:298
298 x2[2] = MULT_NORM(r1 * T[1] + r0 * T[0]);
(gdb) bt
#0 mdct_forward (init=0x4016ffa8, in=0x7b033cc0, out=0x7b033968) at mdct.c:298
#1 0x13760 in _ve_amp (ve=0x7fffffed, gi=0x7b033cc0, data=0xd,
bands=0x4016ffc0, filters=0x40170668, pos=0) at envelope.c:121
#2 0x13c64 in _ve_envelope_search (v=0x7b033628) at envelope.c:243
#3 0xa544 in vorbis_analysis_blockout (v=0x7b033628, vb=0x7b033698)
at block.c:504
#4 0x6f14 in main () at encoder_example.c:237
(gdb)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/215cryptic compile failure when libogg is too old2017-04-08T10:58:44Znoacryptic compile failure when libogg is too old```
I think this should have it's bugzilla entry, since it is a real problem for
inexperienced users.
Problem: If a user tries to compile libvorbis 1.0 with libogg < 1.0 using the
good old './configure; make' formula the compile fails ...```
I think this should have it's bugzilla entry, since it is a real problem for
inexperienced users.
Problem: If a user tries to compile libvorbis 1.0 with libogg < 1.0 using the
good old './configure; make' formula the compile fails with the cryptic
../lib/.libs/libvorbis.a(mapping0.o): In function `mapping0_forward':
mapping0.o(.text+0xd91): undefined reference to `oggpack_writealign'
This can be fixed by uncommenting the line
dnl AC_CHECK_LIB(ogg, oggpack_writealign, , AC_MSG_ERROR(Ogg >= 1.0 required !))
in configure.in
```Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/vorbis/-/issues/206Cymbals problem (upto -q8)2017-04-08T10:58:44Zhellraiser270Cymbals problem (upto -q8)```
Hi!
I found a song (Iced Earth - Melancholy) that has some cymbals in its intro
which don't sound as "rich", "clear" (I can't express it better) as the
original. I used the oggenc dated 20020629. Some users said it doesn't have
en...```
Hi!
I found a song (Iced Earth - Melancholy) that has some cymbals in its intro
which don't sound as "rich", "clear" (I can't express it better) as the
original. I used the oggenc dated 20020629. Some users said it doesn't have
enough lower frequencies.
I could detect the difference up to -q8!!! I didn't think that there could be a
problem with such samples.
More info here: http://www.hydrogenaudio.org/forums/showthread.php?
s=&threadid=2464
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/204os.h patch for Borland C2017-04-08T10:58:44Zdaveos.h patch for Borland C```
Small changes necessary for compiling with BCC in Windows.
``````
Small changes necessary for compiling with BCC in Windows.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/201Setting a very low maximum bitrate causes audio loss.2017-04-08T10:58:44ZStan SeibertSetting a very low maximum bitrate causes audio loss.```
Using oggenc and libvorbis from CVS (2002-06-18), files encoded with a maximum
bitrate of 8 kbps are missing the first 30+ seconds of audio. Encoding with
-M 16 results in files that are missing small gaps of audio every so often....```
Using oggenc and libvorbis from CVS (2002-06-18), files encoded with a maximum
bitrate of 8 kbps are missing the first 30+ seconds of audio. Encoding with
-M 16 results in files that are missing small gaps of audio every so often.
The granulepos values are still in sync with the original, so it looks like
the encoder is not outputting certain packets.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/199Dont free time_param[0]2017-04-08T10:59:08ZrisarisaDont free time_param[0]```
I compiled encoder_example.c and tested.
and found memory leak.
in vorbisenc.c
static int vorbis_encode_toplevel_setup(vorbis_info *vi,int small,int large,int
ch,long rate){
...
ci->time_param[0]=calloc(1,sizeof(_time_dummy));...```
I compiled encoder_example.c and tested.
and found memory leak.
in vorbisenc.c
static int vorbis_encode_toplevel_setup(vorbis_info *vi,int small,int large,int
ch,long rate){
...
ci->time_param[0]=calloc(1,sizeof(_time_dummy));
...
}
This heap memory is not called free().
because, in time0.c
static void time0_free_info(vorbis_info_time *i){
}
so,I added one line.
static void time0_free_info(vorbis_info_time *i){
free(i);
}
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/194bm->avg_binacc is not initialized with zeros, resulting in too large ogg fil...2017-04-08T10:58:44Zal.faberbm->avg_binacc is not initialized with zeros, resulting in too large ogg files when encodign with fixed bitrate settings```
Within the bitrate.c file, the array bm->avg_binacc is allocated (with
ogg_malloc) but is not initialized. A malloc does not have to initialize
the allocated memory chunk with zero's (it might be compiler dependent
though). The be...```
Within the bitrate.c file, the array bm->avg_binacc is allocated (with
ogg_malloc) but is not initialized. A malloc does not have to initialize
the allocated memory chunk with zero's (it might be compiler dependent
though). The behaviour that's observed is that resulting file will be way too
large when trying to encode with a fixed bitrate (bitrate is increasing
(drifting) during the encoding process. The solution is to add a the following
line just after the ogg_malloc:
(void)memset( bm->avg_binacc, 0,bins*sizeof(*bm->avg_binacc) );
But this problem might be at more places in the code and are very hard to
track down. So it might be well worth to redirect the ogg_malloc function to a
calloc function (which is guarenteed to initialize the allocated memory chunk
with zero's)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/191libvorbis built with Sun Forte 6.1 compiler produces bogus output2017-04-08T10:58:44Zatomik_katlibvorbis built with Sun Forte 6.1 compiler produces bogus output```
This is an error in the libvorbis module when compiled under Sun's Forte 6.1 C
compiler suite.
Once compiled, a trace of the ogg123 program shows that ogg123 opens the audio
device and assigns a file descriptor, but all that os ev...```
This is an error in the libvorbis module when compiled under Sun's Forte 6.1 C
compiler suite.
Once compiled, a trace of the ogg123 program shows that ogg123 opens the audio
device and assigns a file descriptor, but all that os ever written to that
desciptor is a series of nulls.
libvorbis compiled under GCC 3.03 works fine.
I have not traced the bug any farther, but can provide the authors with object
files and compiled binaries for testing.
Geoff
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/190Problem sample for q &lt;2017-04-08T10:59:08ZmaikmertenProblem sample for q <```
Hello,
I found a problem sample for RC3 lossy coupling modes.
http://metalbanner.virtualave.net/answer.wav
Just listen for the metallic sound jumping quickly from one side of the
stereo-image to the other. With -q <= 4.99 it sound...```
Hello,
I found a problem sample for RC3 lossy coupling modes.
http://metalbanner.virtualave.net/answer.wav
Just listen for the metallic sound jumping quickly from one side of the
stereo-image to the other. With -q <= 4.99 it sounds "rough"/"unclean" and is
moved to the center.
bye and thanks,
Maik Merten
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/189cc1 segmentation fault on compile2017-04-08T10:58:44Zjupitercc1 segmentation fault on compile```
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
``````
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/187gcc 2.95.3 chokes on -mno-ieee-fp2017-04-08T10:58:44Zdoctorkaedinggcc 2.95.3 chokes on -mno-ieee-fp```
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
``````
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
```Monty MontgomeryMonty Montgomery