Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2023-10-28T13:04:48Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2349misleading-indentation warning in lib/block.c2023-10-28T13:04:48ZJörn Heusippmisleading-indentation warning in lib/block.c```
lib/block.c: In function 'vorbis_analysis_buffer':
lib/block.c:395:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^~
lib/block.c:395:37:...```
lib/block.c: In function 'vorbis_analysis_buffer':
lib/block.c:395:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^~
lib/block.c:395:37: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^
lib/block.c:396:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
396 | if(b->header1)_ogg_free(b->header1);b->header1=NULL;
| ^~
lib/block.c:396:39: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
396 | if(b->header1)_ogg_free(b->header1);b->header1=NULL;
| ^
lib/block.c:397:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
397 | if(b->header2)_ogg_free(b->header2);b->header2=NULL;
| ^~
lib/block.c:397:39: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
397 | if(b->header2)_ogg_free(b->header2);b->header2=NULL;
| ^
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2350strict-prototypes warning in lib/vorbisfile.c2023-10-28T13:03:55ZJörn Heusippstrict-prototypes warning in lib/vorbisfile.c```
lib/vorbisfile.c:1913:12: warning: function declaration isn't a prototype [-Wstrict-prototypes]
1913 | static int host_is_big_endian() {
| ^~~~~~~~~~~~~~~~~~
``````
lib/vorbisfile.c:1913:12: warning: function declaration isn't a prototype [-Wstrict-prototypes]
1913 | static int host_is_big_endian() {
| ^~~~~~~~~~~~~~~~~~
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2348Darwin configure passes invalid flag -force_cpusubtype_ALL2023-09-16T21:23:08ZFX CoudertDarwin configure passes invalid flag -force_cpusubtype_ALLFlag -force_cpusubtype_ALL is passed by configure (see https://gitlab.xiph.org/xiph/vorbis/-/blob/master/configure.ac#L205) unconditionally. This darwin flag was was only ever valid for PowerPC, and ignored for Intel and now Apple Silico...Flag -force_cpusubtype_ALL is passed by configure (see https://gitlab.xiph.org/xiph/vorbis/-/blob/master/configure.ac#L205) unconditionally. This darwin flag was was only ever valid for PowerPC, and ignored for Intel and now Apple Silicon (ARM). In recent versions, the linker now flatly refuses is (in Xcode 15):
ld: unknown options: -force_cpusubtype_ALL
It should either be selectively passed for PowerPC or, at this stage, removed entirely.https://gitlab.xiph.org/xiph/vorbis/-/issues/2347a potential bug of NPD2022-09-13T10:38:25Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gener...Hi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![1662360760592](https://user-images.githubusercontent.com/87304478/188383134-07ef0506-a2c9-4a29-861a-b132c5c0d7f1.jpg)
Although the code shown is for version 1.3.6 but is still exist in current version
would you can help to check if this bug is true?thank you for your effort and patience!https://gitlab.xiph.org/xiph/vorbis/-/issues/2346About ogg123 can't adjust volumn2022-07-18T03:11:47ZHangAbout ogg123 can't adjust volumnDear All:
I'm really sorry to bother you,I am using vorbis-toos to develop and I want to adjust the volume,but I don't find the relevant usage method。
I don't know ogg123 is or not support adjust the volume with software method(Ps:I ha...Dear All:
I'm really sorry to bother you,I am using vorbis-toos to develop and I want to adjust the volume,but I don't find the relevant usage method。
I don't know ogg123 is or not support adjust the volume with software method(Ps:I have no sound card,only use pcm),Hope everybody helps answer,thanks very much!https://gitlab.xiph.org/xiph/vorbis/-/issues/2345Please give a example of how to use RTP vorbis2022-02-18T07:12:32Zyi xinPlease give a example of how to use RTP vorbishttps://gitlab.xiph.org/xiph/vorbis/-/issues/2344ov_fopen returns undocumented error value2022-01-01T03:49:16ZCarl Banksov_fopen returns undocumented error valueov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open t...ov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open the file. I'd guess that a lot of the code out in the field just tests if return value is -1.https://gitlab.xiph.org/xiph/vorbis/-/issues/2343Accessing elements outside of array boundaries2021-06-06T17:28:26ZdokutokuAccessing elements outside of array boundarieshttps://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of th...https://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of the array in line 347.
```c
if(halfoc>=P_BANDS-2)halfoc=P_BANDS-2;
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2335Four heap buffer overflow(read and write) vuls in function mapping0_forward()...2020-07-16T17:24:00ZJiangxinFour heap buffer overflow(read and write) vuls in function mapping0_forward() of libvorbis-1.3.6, which is caused by lacking of var “channels” check.I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6...I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488324304, sp=sp@entry=140737488324296, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000069fac3 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:370
#8 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#9 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#10 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
(gdb)
```
These vuls are because of lacking of var “channels” check”, and here is the details of these four vuls in mapping0.c:
vul 1: line 370 of mapping0.c
```
366 for(i=0;i<vi->channels;i++){
367 /* the encoder setup assumes that all the modes used by any
368 specific bitrate tweaking use the same floor */
369
370 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
```
vul 2: line 614 of mapping0.c
```
612 /* encode floor, compute masking curve, sep out residue */
613 for(i=0;i<vi->channels;i++){
614 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
615 int *ilogmask=iwork[i];
```
vul 3 and 4: line 666 and 678 of mapping0.c
```
665 for(j=0;j<vi->channels;j++){
666 if(info->chmuxlist[j]==i){//int array[256] oob write, vi->channels need check
667 zerobundle[ch_in_bundle]=0;
668 if(nonzero[j])zerobundle[ch_in_bundle]=1;
669 couple_bundle[ch_in_bundle++]=iwork[j];
670 }
671 }
672
673 classifications=_residue_P[ci->residue_type[resnum]]->
674 class(vb,b->residue[resnum],couple_bundle,zerobundle,ch_in_bundle);
675
676 ch_in_bundle=0;
677 for(j=0;j<vi->channels;j++)
678 if(info->chmuxlist[j]==i)//int array[256] oob write, vi->channels need check
679 couple_bundle[ch_in_bundle++]=iwork[j];
680
681 _residue_P[ci->residue_type[resnum]]->
682 forward(opb,vb,b->residue[resnum],
683 couple_bundle,zerobundle,ch_in_bundle,classifications,i);
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.
recommanded patch : adding on line 238 of mapping0.c
```
230 static int mapping0_forward(vorbis_block *vb){
231 vorbis_dsp_state *vd=vb->vd;
232 vorbis_info *vi=vd->vi;
233 codec_setup_info *ci=vi->codec_setup;
234 private_state *b=vb->vd->backend_state;
235 vorbis_block_internal *vbi=(vorbis_block_internal *)vb->internal;
236 int n=vb->pcmend;
237 int i,j,k;
238 if(vi->channels > MAX_CHANNEL || vi->channels < 0) return -1;//recommanded patch for these vuls
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2342Getting undefined reference to `_impure_ptr' on mingw compilation2020-07-08T14:20:51ZMoritz BenderGetting undefined reference to `_impure_ptr' on mingw compilationI downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.e...I downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: test_sharedbook-sharedbook.o:sharedbook.c:(.rdata$.refptr._impure_ptr[.refptr._impure_ptr]+0x0): undefined reference to `_impure_ptr'
collect2.exe: error: ld returned 1 exit status
```
Compilation did work on my wsl, so I'm not sure what this is about. I managed to get the static library by make -j ing, but I'd still like to know why this part fails and whether there is a way to avoid this.https://gitlab.xiph.org/xiph/vorbis/-/issues/2334Stack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1....2020-07-06T20:52:22ZJiangxinStack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1.3.6, which is caused by lacking of array length check.I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe...I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488322736, sp=sp@entry=140737488322728, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000062cc6d in bark_noise_hybridmp (n=256, b=0x61d000000a80, f=0x61d000007c80, noise=0x619000005a80, offset=140, fixed=-1) at psy.c:608
#8 0x000000000062b3fb in _vp_noisemask (p=0x610000000040, logmdct=0x61d000007c80, logmask=0x619000005a80) at psy.c:705
#9 0x000000000069ff59 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:417
#10 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#11 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#12 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
```
This vul is because of lacking of array len check , and I recommand a patch as follows:
psy.c:
```
602 for (i = 0, x = 0.f;; i++, x += 1.f) {
603
604 lo = b[i] >> 16;
605 if( lo>=0 ) break;
606 hi = b[i] & 0xffff;
607 if(hi>=n || -lo>=n)break;//recommanded patch for this vul
608 tN = N[hi] + N[-lo];
609 tX = X[hi] - X[-lo];
610 tXX = XX[hi] + XX[-lo];
611 tY = Y[hi] + Y[-lo];
612 tXY = XY[hi] - XY[-lo];
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2341Broken MSDN links2020-07-04T02:02:58ZRalph GilesBroken MSDN linksThe api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if ...The api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if the details are still correct. Behaviour may well have changed in the intervening decade.https://gitlab.xiph.org/xiph/vorbis/-/issues/468vorbisenc api docs out of date2020-06-23T17:20:43ZGhost Uservorbisenc api docs out of date```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentat...```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentation at all.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1251Status of integrating autuv work into vorbis?2020-06-23T17:18:12Zj.w.r.degoedeStatus of integrating autuv work into vorbis?Hi,
I'm the Fedora maintainer of the ogg / vorbis / theora stack in Fedora. While cleaning up old bugs I encountered this one:
https://bugzilla.redhat.com/show_bug.cgi?id=204280
This is a request by an end user to include the aotuv rel...Hi,
I'm the Fedora maintainer of the ogg / vorbis / theora stack in Fedora. While cleaning up old bugs I encountered this one:
https://bugzilla.redhat.com/show_bug.cgi?id=204280
This is a request by an end user to include the aotuv release 1 patch in our libvorbis packages. I've noticed that aotuv beta2 was integrated in libvorbis-1.1.x are there any plans to integrate the improvements made by aotuv past beta2?
If not why not? Are the known problems with aotuv release 1? Does it produce 100% compatible ogg files?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/491example code error?2020-06-23T16:36:31ZBill Nottinghamexample code error?```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora...```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora.
The compiler said
1.
seeking_example.c(142): remark #592: variable "pos" is used before
its value is set
seeking_example.c(163): remark #592: variable "pos" is used before
its value is set
seeking_example.c(190): remark #592: variable "pos" is used before
its value is set
I've checked the source code, and I agree with the compiler. This
code would benefit from rework.
Version-Release number of selected component (if applicable):
libvorbis-1_0-8
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1800Use AC_CANONICAL_HOST for detecting cross-compilation environment2020-06-23T16:29:49ZMaarten BosmansUse AC_CANONICAL_HOST for detecting cross-compilation environmentAC_CANONICAL_HOST should be used instead of AC_CANONICAL_TARGET in configure.ac.
This is an issue in vorbis, theora and vorbis-tools.
The last two need a patch similar to https://trac.xiph.org/changeset/13007 and for vorbis/configure.ac...AC_CANONICAL_HOST should be used instead of AC_CANONICAL_TARGET in configure.ac.
This is an issue in vorbis, theora and vorbis-tools.
The last two need a patch similar to https://trac.xiph.org/changeset/13007 and for vorbis/configure.ac AC_CANONICAL_TARGET needs to be replaced by AC_CANONICAL_HOST
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1805Decoding error in libvorbis when compiled on Mac OS X in i386 architecture2020-06-13T02:58:24ZShannon StewmanDecoding error in libvorbis when compiled on Mac OS X in i386 architectureI encountered a subtle and odd error in libvorbis that shows up on Mac OS X when you compile for i386 architecture.
This is for the released library libvorbis 1.3.2.
It doesn't show up when compiling for x86_64 architecture.
The sympt...I encountered a subtle and odd error in libvorbis that shows up on Mac OS X when you compile for i386 architecture.
This is for the released library libvorbis 1.3.2.
It doesn't show up when compiling for x86_64 architecture.
The symptom: ogg123 produces noise when compiled for i386 but plays the file quite normally when compiled for x86_64. After much tinkering, I finally decoded the .ogg to raw with oggdec in both i386 and x86_64 and compared the output with od:
s007% od -t xS -N 32 /tmp/oggdec_i386.out
0000000 c2b5 8000 c4ba 8000 c252 8000 c28b 8000
0000020 c7f0 8000 cb4b 8000 ce95 8000 d114 8000
d0000040
s007% od -t xS -N 32 /tmp/oggdec_x86-64.out
0000000 c2b5 d253 c4ba d4a9 c252 d4b1 c28b d7d3
0000020 c7f0 ddfe cb4b df58 ce95 de6c d114 dc79
0000040
Notice that in the i386 decoding, every other short is nonsense (x8000).
I traced the problem to the float-to-int conversion code defined in lib/os.h. IIRC, Mac OS X relies entirely on the SSE1/2/3 instruction set to perform math, and may not initialize the FPU correctly.
The problem is solved neatly by relying on the SSE2 code (which is used in the x86_64 pathway). ogg123 plays the file correctly, and the decoding matches between the i386 and x86_64 builds. This fix *should* be safe on Mac OS X; all of the Intel machines that Apple ships have the SSE2 instruction set.
I've attached a diff of my changes, which are localized to lib/os.h
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/467Extraneous 'f' parameter in ov_open_callbacks documentation2020-06-13T00:42:20ZmatExtraneous 'f' parameter in ov_open_callbacks documentation```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-pas...```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-paste error from the ov_open docs.
'datasource' needs to be documented instead.
As a minor nit, the documentation also talks about calling 'fclose' on
the file pointer, which is not necessarily appropriate for ov_open_callbacks.
I am using ov_open_callbacks because my data is not coming from a FILE *.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1707libvorbis does not like being compiled by a llvm backend.2020-06-13T00:38:11Zdak180libvorbis does not like being compiled by a llvm backend.I am the mac builder for [Warzone 2100](http://developer.wz2100.net/); recently I switched everything over to compile with clang but I found that warzone would [crash](http://wz2100.pastebin.com/tjD6hq2M) on start up.
I determined that ...I am the mac builder for [Warzone 2100](http://developer.wz2100.net/); recently I switched everything over to compile with clang but I found that warzone would [crash](http://wz2100.pastebin.com/tjD6hq2M) on start up.
I determined that this only happens when libvorbis has been compiled with a LLVM backend (switching it to use gcc4.2 makes it work again).
I would really like to be able to use clang to compile libvorbis, so any ideas would be useful.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1919Build with automake-1.13 broken2020-06-13T00:36:46ZMarko LindqvistBuild with automake-1.13 brokenAutomake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Monty MontgomeryMonty Montgomery