Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/363autogen.sh incorrect for OSX2017-04-08T10:58:44Zhast510autogen.sh incorrect for OSX```
Okay, here's the deal. I did some heavy tweaking of autogen.sh to get this to
compile on 10.2.6, but it was convoluted. Now that I have done some further
examining, I think I have a more elegant solution. I believe OS X comes ship...```
Okay, here's the deal. I did some heavy tweaking of autogen.sh to get this to
compile on 10.2.6, but it was convoluted. Now that I have done some further
examining, I think I have a more elegant solution. I believe OS X comes shipped
with glibtool, and glibtoolize instead of libtool, and libtoolize. I believe it
also comes with libtool, and libtoolize, but libtool does not support the
--version option, and libtoolize is NOT installed. Therefore, I changed libtool
to glibtool, and libtoolize, to glibtoolize. Just a heads up. BTW, if this is
not the appropriate place to publish a bug, could the project maintainer email
me? This is my first time filing a bug for an open-source project through this
system.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/348proper pkg-config files should be generated and installed 2017-04-08T10:58:44Zsxpertproper pkg-config files should be generated and installed ```
Proper pkg-config files should be generated and installed in
$(prefix)/lib/pkg-config for all libraries so that it's much easier to find them.
``````
Proper pkg-config files should be generated and installed in
$(prefix)/lib/pkg-config for all libraries so that it's much easier to find them.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/340[PATCH] segfault in decoding: bad book->dec_codelengths address2017-04-08T10:58:44ZAndrew S. Williams[PATCH] segfault in decoding: bad book->dec_codelengths address```
i'm using vorbisgain v0.32 (a third party tool)
a seg fault is occurring within libvorbis, so maybe it is a bug in libvorbis
itself..
the seg fault can occur at any point in the analysing stage, and occurs often
(for me at least) wit...```
i'm using vorbisgain v0.32 (a third party tool)
a seg fault is occurring within libvorbis, so maybe it is a bug in libvorbis
itself..
the seg fault can occur at any point in the analysing stage, and occurs often
(for me at least) with low quality encoded files.
audio-q1.ogg is a large ogg vorbis file (about 35Mb), quality 1.
> gdb vorbisgain
(gdb) run audio-q1.ogg
Starting program: /usr/local/bin/vorbisgain audio-q1.ogg
Analyzing files...
Gain | Peak | Scale | New Peak | Track
----------+--------+-------+----------+------
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x280a6994 in decode_packed_entry_number (book=0x809e3c8, b=0xbfbff5a8)
at codebook.c:345
345 if(book->dec_codelengths[lo]<=read){
(gdb) print book->dec_codelengths
$1 = 0x800 <Error reading address 0x800: Bad address>
(gdb) print lo
$2 = 0
(gdb) print hi
$3 = 0
(gdb) bt
#0 0x280a6994 in decode_packed_entry_number (book=0x809e3c8, b=0xbfbff5a8)
at codebook.c:345
#1 0x280a67d2 in vorbis_book_decodevv_add (book=0x809e3c8, a=0xbfbff1a8,
offset=288, ch=2, b=0xbfbff5a8, n=32) at codebook.c:460
#2 0x280a4499 in res2_inverse (vb=0xbfbff5a4, vl=0x8084240, in=0xbfbff1a8,
nonzero=0x1, ch=2) at res0.c:859
#3 0x280a58e2 in mapping0_inverse (vb=0xbfbff5a4, l=0x8098000)
at mapping0.c:701
#4 0x2809b2c9 in vorbis_synthesis (vb=0xbfbff5a4, op=0x2) at synthesis.c:76
#5 0x280b3484 in _fetch_and_process_packet (vf=0xbfbff360, op_in=0x0, readp=1)
at vorbisfile.c:481
#6 0x280b5a68 in ov_read_float (vf=0xbfbff360, pcm_channels=0xbfbff354,
length=1024, bitstream=0xbfbff358) at vorbisfile.c:1612
#7 0x0804a7f4 in free ()
#8 0x08049a37 in free ()
#9 0x0804a16d in free ()
#10 0x080493d5 in free ()
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/337oggenc segfaults in apsort() in psy.c on solaris 5.92017-04-08T10:58:44Zsimonoggenc segfaults in apsort() in psy.c on solaris 5.9```
I haven't been able to determin the cause. But I have run it under dbx to find
out where it's coring and whats causing the core. Going from qsort() in psy.c to
apsort() in the same file some how corrupts the pointers. I'm not sure if...```
I haven't been able to determin the cause. But I have run it under dbx to find
out where it's coring and whats causing the core. Going from qsort() in psy.c to
apsort() in the same file some how corrupts the pointers. I'm not sure if this
is a vorbis thing or a sun thing. But considering i've managed to encode one
file sucessfully, i think it's something to do with the contents of the wav files.
(dbx) run -q 5 /tmp/test.wav
Running: oggenc -q 5 /tmp/test.wav
(process id 16546)
Opening with wav module: WAV file reader
Encoding "/tmp/test.wav" to
"/tmp/test.ogg"
at quality 5.00
signal SEGV (no mapping at the fault address) in apsort at line 953 in file "psy.c"
953 if(fabs(**(float **)a)>fabs(**(float **)b)) return -1;
(dbx) where
=>[1] apsort(a = 0xffbfedec, b = 0xffbfedf4), line 953 in "psy.c"
[2] qsort(0xffbfedf0, 0x8, 0x4, 0xff35f0a0, 0xffbfe998, 0x80), at 0xff0cb60c
[3] _vp_noise_normalize_sort(p = 0x8f860, magnitudes = 0xccaa0, sortedindex =
0xffbfeea0), line 994 in "psy.c"
[4] mapping0_forward(vb = 0xffbff4b8), line 532 in "mapping0.c"
[5] vorbis_analysis(vb = 0xffbff4b8, op = (nil)), line 48 in "analysis.c"
[6] oe_encode(0xffbff6f0, 0x1c, 0x400, 0x33f40, 0x37888, 0xc00), at 0x16f20
[7] main(0xffffffff, 0x0, 0x32280, 0x33f20, 0x33f40, 0x34a80), at 0x13844
(dbx) print a,b,*a,*b
a = 0xffbfedec
b = 0xffbfedf4
*a = (void)
*b = (void)
(dbx) up
0xff0cb60c: qsort+0x00f4: jmpl %l1, %o7
(dbx) up
Current function is _vp_noise_normalize_sort
994 qsort(work,partition,sizeof(*work),apsort);
(dbx) print partition
partition = 8
(dbx) for i in 0 1 2 3 4 5 6 7; do print *work[$i];done
*work[0] = 0.0
*work[1] = 0.0
*work[2] = 0.0
*work[3] = 0.0
*work[4] = 0.0
*work[5] = 0.0
*work[6] = 0.0
*work[7] = 0.0
(dbx)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/334[PATCH] vorbis.m4 creates a conftest.c program that crashes.2017-04-08T10:58:44Zmatt[PATCH] vorbis.m4 creates a conftest.c program that crashes.```
On NetBSD-1.6 on i386, when I used the XIPH_PATH_VORBIS() macro form vorbis.m4,
configure tells me detecting of libvorbis failed. When I look in config.log,
I see that the conftest program that is created crashes with a Segfault.
See...```
On NetBSD-1.6 on i386, when I used the XIPH_PATH_VORBIS() macro form vorbis.m4,
configure tells me detecting of libvorbis failed. When I look in config.log,
I see that the conftest program that is created crashes with a Segfault.
See http://www.mafr.de/misc/conftest.c for the file along with the used
compiler flags. The crash is somewhere in vorbis_analysis_init().
On Linux, it works without any problems.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/323floor1_inverse_dB_table has slight errors2017-04-08T10:58:44Zjripleyfloor1_inverse_dB_table has slight errors```
The table in floor1.c appears to be generated by:table[x] = pow(10, ((x - 255) * (140 / 256) / 20))Which is basically 256 entries spanning 140dB. This doesn't quite match the numbers in the table - it's off by a very small amount. I ...```
The table in floor1.c appears to be generated by:table[x] = pow(10, ((x - 255) * (140 / 256) / 20))Which is basically 256 entries spanning 140dB. This doesn't quite match the numbers in the table - it's off by a very small amount. I think that the table was generated with slight accumulated errors.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/316libvorbis package does not build on RH 8.02017-04-08T10:58:44Zmark7libvorbis package does not build on RH 8.0```
libvorbis's spec file fails to build on RH 8.0.
Here's a patch:
--- libvorbis.spec 2002-07-19 02:48:15.000000000 -0400
+++ ../../SPECS/libvorbis.spec 2003-02-10 09:26:26.000000000 -0500
@@ -81,14 +81,14 @@
%{_includedir}/vor...```
libvorbis's spec file fails to build on RH 8.0.
Here's a patch:
--- libvorbis.spec 2002-07-19 02:48:15.000000000 -0400
+++ ../../SPECS/libvorbis.spec 2003-02-10 09:26:26.000000000 -0500
@@ -81,14 +81,14 @@
%{_includedir}/vorbis/codec.h
%{_includedir}/vorbis/vorbisfile.h
%{_includedir}/vorbis/vorbisenc.h
-%{_libdir}/libvorbis.a
-%{_libdir}/libvorbis.so
-%{_libdir}/libvorbisfile.a
-%{_libdir}/libvorbisfile.so
-%{_libdir}/libvorbisenc.a
-%{_libdir}/libvorbisenc.so
+%{_libdir}/*.a
+%{_libdir}/*.so
+%{_libdir}/*.la
%changelog
+* Mon Jan 10 2003 Mark Jonathan Schreiber <mark7@andrew.cmu.edu>
+- included *.la files in libvorbis-devel
+
* Sun Jul 14 2002 Thomas Vander Stichele <thomas@apestaart.org>
- Added BuildRequires:
- updated for 1.0 release
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/311FPE when encoding with -q5 under linux/axp2017-04-08T10:58:44ZmwhitsonFPE when encoding with -q5 under linux/axp```
Certain samples reliably cause oggenc to throw a SIGFPE on an Alpha. (Only
tested with linux; haven't tried tru64 yet.) core and sample to be attached.
#0 0x200002119f4 in fit_line (acc=0x11fffdd30, fits=2, y0=0x11ffff24c,
y...```
Certain samples reliably cause oggenc to throw a SIGFPE on an Alpha. (Only
tested with linux; haven't tried tru64 yet.) core and sample to be attached.
#0 0x200002119f4 in fit_line (acc=0x11fffdd30, fits=2, y0=0x11ffff24c,
y1=0x11ffff250) at ../../lib/floor1.c:511
#1 0x2000021267c in floor1_fit (vb=0x11ffff6a0, look=0x12007ee50,
logmdct=0x12007be70, logmask=0x12007bc70) at ../../lib/floor1.c:676
#2 0x20000219ffc in mapping0_forward (vb=0x11ffff6a0)
at ../../lib/mapping0.c:423
#3 0x20000205054 in vorbis_analysis (vb=0x11ffff6a0, op=0x0)
at ../../lib/analysis.c:47
#4 0x1200097c8 in oe_encode (opt=0x11ffff9e8) at ../../oggenc/encode.c:283
#5 0x12000316c in main (argc=3, argv=0x11ffffb88) at ../../oggenc/oggenc.c:344
With this sample, starting the encoding anywhere between samples 0-8668 causes
the FPE; if I trim the wav file to start at sample 8669, it encodes fine. If I
use -q4, it encodes fine.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/296[PATCH] Runtime DLL used in Debug Mode2017-04-08T10:58:44ZGitlab Bot[PATCH] Runtime DLL used in Debug Mode```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
deve...```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
developers (IMHO) use this under Win32.
The change is simple: "Project Settings" -> "C/C++" -> "Code Generation" and set
"Use run-time library" to "debug multithreaded" on "vorbis_static.dsp",
"vorbisenc_static.dsp" and "vorbisfile_static.dsp".
This is an update against the version in CVS on 6/12/02.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/288Syntax error in code prevents building2017-04-08T10:58:44ZandreaskSyntax error in code prevents building```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in li...```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in libvorbis/lib/lookup.c like this
return INVSQ2EXP_LOOKUP[a-INVSQ2EXP_LOOKUP_MIN];
Note the missing space between 'a-' and the macro.
On my HP/PA-RISC, with the native compiler this causes an syntax error.
The expansion of the code above is
a--32
This is at least ambiguous: 'a-- 32' vs 'a- -32', and the first interpreation
truly is a syntax error.
Best solution: Change the define to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The parentheses prevent any misinterpretation of the value.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/284libvorbis crash2017-04-08T10:58:44ZStephanlibvorbis crash```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compile...```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compiled
again using electric fence just to find out that it complains about mmap.
What exactly do you need to know in order to find a solution. This is the first
time I use bugzilla and I'm quite sure the above is not sufficient.
```titihttps://gitlab.xiph.org/xiph/vorbis/-/issues/279error in use of qsort2017-04-08T10:58:44ZThomas Gerekeerror in use of qsort```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler...```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler
(watcom 11.0a) the decoder hangs in qsort called in lib/sharedbook.c. if an
extra compare is added, all is fine.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/264local_book_besterror in res0.c2017-04-08T10:58:44Zmpxplaylocal_book_besterror in res0.c```
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
``````
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/257OggEnc gives bad quality with synthetic speech2017-04-08T10:58:44ZtgirmannOggEnc gives bad quality with synthetic speech```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've...```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've tried other encoders too; at the same bit rates MP3 (LAME version 3.92 MMX)
suffers from similar problems but it sounds better (when using vbr) while
Musepack sounds almost perfectly.
(side note: when forcing LAME to 128 kbit/s the quality is really bad)
As I selected quality I want oggenc to allocate enough bits to achieve the
desired quality.
See attachment for reverence WAV and Ogg Vorbis examples.
(Yes I'm using OggEnc v1.0 (libvorbis 1.0))
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/256encoder_example (and libvorbis?) leaks memory in managed bitrate mode2017-04-08T10:58:44ZPatrick Bridgesencoder_example (and libvorbis?) leaks memory in managed bitrate mode```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is ...```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is encoded. Memory usage is constant if
_init_vbr() is used instead. Tested on RedHat Linux 7.3, with the gcc version 2.96.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/246Decoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over...2017-04-08T10:58:44ZgcDecoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over-read```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "noc...```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "nock.ogg"...
New logical stream (#1, serial: 62f352bc): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3)
Channels: 1
Rate: 11025
Nominal bitrate not set
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 721 bytes
Playback length: 0m:00s
Average bitrate: 49.798121 kbps
Logical stream 1 ended
-=-=---=-=---=-=---=-=--
which reports a "ov_pcm_total(vf, -1) * channels * 2" of 2554 bytes, when
getting read by ov_read, sends back to the caller 256 bytes, then 256, 256, 1152
and 2048, which makes a total of 3968 bytes - then tuxpuck crashes because
it malloc'ed only 2554 bytes in its buffer.
This bug seems confirmed by using "oggdec" which doesn't segfault but ends
reporting it was at 155.0% of the stream.
We're using the final 1.0 release of Ogg Vorbis (since Sun Jul 21 2002). I've
tried to query this bug database for a duplicate but didn't find one, sorry if
this has already been fixed in the CVS or already reported.
I've put the ogg file here for your convenience though it's in official tuxpuck
package:
http://people.mandrakesoft.com/~gc/files/nock.ogg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/237sound quality in high voice2017-04-08T10:58:44Zvgaborsound quality in high voice```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1...```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1.0.
```Monty MontgomeryMonty Montgomeryhttps://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/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/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 Montgomery