Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2010-10-27T13:30:10Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/484libogg2: ogg_page_getbuffer declaired but not defined2010-10-27T13:30:10ZArc Rileylibogg2: ogg_page_getbuffer declaired but not defined```
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
``````
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/841Debian rules for libogg 1.1.3 produces incorrect file names2010-10-26T11:16:42ZblendaDebian rules for libogg 1.1.3 produces incorrect file namesIssuing "fakeroot debian/rules binary" on the libogg 1.1.3 source produces Debian packages with incorrect file names: libogg0_1.1.1-1_i386.deb and libogg-dev_1.1.1-1_i386.deb.
I'm not familiar with the debian/rules thingy, but I guess t...Issuing "fakeroot debian/rules binary" on the libogg 1.1.3 source produces Debian packages with incorrect file names: libogg0_1.1.1-1_i386.deb and libogg-dev_1.1.1-1_i386.deb.
I'm not familiar with the debian/rules thingy, but I guess that debian/files is the culprit. It has these two lines:
libogg0_1.1.1-1_i386.deb libs optional
libogg-dev_1.1.1-1_i386.deb libdevel optional
BTW there is no option for chosing 1.1.3 as libogg version when creating ticket.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/586[PATCH] ogg2-arc does not compile wiht mingw322009-04-19T21:13:43Zj[PATCH] ogg2-arc does not compile wiht mingw32ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# ...ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# include <_G_config.h>
typedef _G_int64_t ogg_int64_t;
typedef _G_int32_t ogg_int32_t;
typedef _G_uint32_t ogg_uint32_t;
typedef _G_int16_t ogg_int16_t;
typedef _G_uint16_t ogg_uint16_t;
# elif defined(__MINGW32__)
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
typedef unsigned long long ogg_uint64_t;
```Arc RileyArc Rileyhttps://gitlab.xiph.org/xiph/ogg/-/issues/25'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea2009-04-19T20:39:35Ztom'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we s...```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we see just 'msdev' without a
path):
call vcvars32.bat
```starclassstarclasshttps://gitlab.xiph.org/xiph/ogg/-/issues/653[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m42009-04-19T20:23:36ZJulien Cristau[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m4Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and t...Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and the XIPH_PATH_OGG/XIPH_PATH_VORBIS
macros) when running "./configure --prefix=foo" if {OGG,VORBIS}_LIBS are
assumed to contain only `-l' options.
Moreover, header file search directory options (`-IDIR') belong in
CPPFLAGS, not CFLAGS.
Patches are available at http://perso.ens-lyon.fr/julien.cristau/ogg.m4.diff
and http://perso.ens-lyon.fr/julien.cristau/vorbis.m4.diff
Regards,
Julien CristauMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/289[PATCH] MacOS building of ogg &amp; vorbis somewhat 'hacky'2009-04-19T20:20:08ZGitlab Bot[PATCH] MacOS building of ogg & vorbis somewhat 'hacky'```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses tw...```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses two explicit macros to shunt MacOS and MacOSX builds. I've
locally worked up a solution that does the 'proper' detection of compiler(s) as
an peer solution.
In addition, the other 'hacky' piece is that ogg uses a 'fake' sys/types.h file
in order to compile. But any project trying to build against just the base
headers will then fail under Codewarrior/Mac (under GCC/Project Builder, a real
sys/types.h exists...). My solution was to inline the types, which should be
safe on the Mac given any Codewarrior from the last few years.
I'd love to get this, and other, Mac-side enhancements checked into the
mainline tree to try to improve the 'Mac user experience'. (Other things I've
done, and could clean up for submission, include a Carbon-safe build.)
Regards,
David Chait
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/245libogg's $(includedir) blitzing makes baby Jesus cry2009-04-19T20:17:38ZGitlab Botlibogg's $(includedir) blitzing makes baby Jesus cry```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Boo...```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Bootable Business Card. You should find some other way of appending "ogg" to
the $(includedir) variable that makes it so we don't have to hack around you.
Right now when I set --includedir= in the configure script, it is ignored. This
is just bad behavior.
Also, your bug system makes me jump through a ridiculous set of hoops just to
file a fucking bug. Why the hell should *I* set up an account? It's not like
any bugs will be assigned to me or anything. Just store my e-mail address and
move on. It's completely fucking bogus that I should have to go digging through
my mail for confirmation passwords sent by the mailer-daemon address. You're
lucky you get any bugs at all what with the barriers you put up. GARGARGAR!
Also, how come there are no versions in this thing later than rc3? Is anyone
actually using this bug system any more? Have you all moved on to something
sane like debbugs?
Oooh! Bug writing guidelines! Maybe I should follow that link and then submit
this to STRUNK and WHITE! Maybe the dizzying maze of input boxes aren't
STRUCTURE ENOUGH for this thing.
Any serious bug system would have, right on the front page, a big red button
marked "FILE A BUG". It should be easy to file, and then easy to triage. By
using bojira, YOU RUINED CHRISTMAS!
Oh yeah, and I love this doozy:
Bugzilla version 2.14.1
Posting Bug
One moment please...
The name baby jesus is not a valid username. Either you misspelled it, or the
person has not registered for a Bugzilla account.
Please hit the Back button and try again.
The BACK BUTTON, for krissakes. You'd think the folks who DESIGNED A WEB
BROWSER would know how to MAKE A WEB APP that didn't SUCK ARSE in the UI
department! I'll just use my BACK BUTTON to KEY IN MY BUG IN MORSE WHY DON'T I.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/374libxmms-flac.so references undefined plt symbol2007-06-17T08:42:16Zrretzlaflibxmms-flac.so references undefined plt symbol```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
Al...```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
All up looks like libtool suckage
$ libtool --version
ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001/05/22 10:39:30)
../../libtool-disable-static --mode=link gcc -I../.. -I./include -I../../includ
e -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -
Winline -DFLaC__INLINE=__inline__ -g -O2 -I/usr/pkg/include -I/usr/pkg/include/
xmms -I/usr/pkg/include/gtk-1.2 -I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/
glib/include -I/usr/X11R6/include -o libxmms-flac.la -rpath /usr/pkg/lib/xmms
/Input -module -avoid-version charset.lo configure.lo plugin.lo wrap_id3.lo fil
einfo.lo ../../src/plugin_common/libplugin_common.a ../../src/share/grabbag/lib
grabbag.a ../../src/share/gain_analysis/libgain_analysis.a ../../src/share/utf
8/libutf8.a ../../src/libFLAC/libFLAC.la -L../../src/libFLAC/.libs -L/usr/pkg
/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -L/
usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm -lxmms
mkdir .libs
*** Warning: This library needs some functionality provided by ../../src/plugin_common/libplugin_common.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/grabbag/libgrabbag.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/gain_analysis/libgain_analysis.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/utf8/libutf8.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/740libogg configure.in doubles up ldflags2007-06-17T08:40:29ZGitlab Botlibogg configure.in doubles up ldflagsan error in configure.in of libogg doubles the predefined ldflags.
Now this is not always a problem, but for some options (such as the SDK option for Mac OS X) it is.
This should fix it:
diff -ruN libogg-1.1.2/configure.in libogg/confi...an error in configure.in of libogg doubles the predefined ldflags.
Now this is not always a problem, but for some options (such as the SDK option for Mac OS X) it is.
This should fix it:
diff -ruN libogg-1.1.2/configure.in libogg/configure.in
--- libogg-1.1.2/configure.in 2004-09-23 15:30:58.000000000 +0200
+++ libogg/configure.in 2005-11-14 22:16:04.000000000 +0100
@@ -28,17 +28,17 @@
case $host in
*-*-irix*)
DEBUG="-g -signed"
- CFLAGS="-O2 -w -signed"
+ EXTRA_CFLAGS="-O2 -w -signed"
PROFILE="-p -g3 -O2 -signed"
;;
sparc-sun-solaris*)
DEBUG="-v -g"
- CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
+ EXTRA_CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
PROFILE="-v -xpg -g -xO4 -fast -native -fsimple -xcg92 -Dsuncc"
;;
*)
DEBUG="-g"
- CFLAGS="-O"
+ EXTRA_CFLAGS="-O"
PROFILE="-g -p"
;;
esac
@@ -46,30 +46,30 @@
case $host in
*-*-linux*)
DEBUG="-g -Wall -fsigned-char"
- CFLAGS="-O20 -ffast-math -fsigned-char"
+ EXTRA_CFLAGS="-O20 -ffast-math -fsigned-char"
PROFILE="-Wall -W -pg -g -O20 -ffast-math -fsigned-char"
;;
sparc-sun-*)
DEBUG="-g -Wall -fsigned-char -mv8"
- CFLAGS="-O20 -ffast-math -fsigned-char -mv8"
+ EXTRA_CFLAGS="-O20 -ffast-math -fsigned-char -mv8"
PROFILE="-pg -g -O20 -fsigned-char -mv8"
;;
*-*-darwin*)
DEBUG="-fno-common -g -Wall -fsigned-char"
- CFLAGS="-fno-common -O4 -Wall -fsigned-char -ffast-math"
+ EXTRA_CFLAGS="-fno-common -O4 -Wall -fsigned-char -ffast-math"
PROFILE="-fno-common -O4 -Wall -pg -g -fsigned-char -ffast-math"
;;
*)
DEBUG="-g -Wall -fsigned-char"
- CFLAGS="-O20 -fsigned-char"
+ EXTRA_CFLAGS="-O20 -fsigned-char"
PROFILE="-O20 -g -pg -fsigned-char"
;;
esac
fi
-CFLAGS="$CFLAGS $cflags_save"
+CFLAGS="$EXTRA_CFLAGS $cflags_save"
DEBUG="$DEBUG $cflags_save"
PROFILE="$PROFILE $cflags_save"
-LDFLAGS="$LDFLAGS $ldflags_save"
+LDFLAGS="$EXTRA_LDFLAGS $ldflags_save"
dnl Checks for programs.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/694Could not find or load the file &#34;ELIB.LIB&#34; for target &#34;WINSCW UDE...2007-06-17T08:39:21ZsenthilashokCould not find or load the file "ELIB.LIB" for target "WINSCW UDEB" for project "ogg.mcp".Hi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
SenHi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
Senhttps://gitlab.xiph.org/xiph/ogg/-/issues/1118libogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed file2007-05-28T08:28:38Zensoniclibogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed fileAs sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug...As sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug.cgi?id=397229
Unfortunately I don't get a decent backtrace here. The last function called is
ogg_stream_pagein()
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/152MSVC project settings for ogg_static_d.lib cause linker errors when used with...2006-06-12T11:39:41ZGitlab BotMSVC project settings for ogg_static_d.lib cause linker errors when used with "Debug Multithreaded" libs```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL ...```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL libs. Specific errors:
Linking...
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _malloc already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _free already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _memmove already defined in
libcmtd.lib(memmove.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _realloc already defined in
libcmtd.lib(dbgheap.obj)
LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
.\WinDebug/Game.exe : fatal error LNK1169: one or more multiply defined symbols
found
Error executing link.exe.
Cause: There are two files in the ogg_static project that are individually set
to use the "Debug Multithreaded DLL" libraries, and they do not change with the
project settings.
To fix: Open the ogg_static project with MSVC, go to Project->Settings, make
sure the active project ("Settings for:") is Win32Debug, select bitwise.c,
switch to the C++ tab, and hit the "Reset" button. This should not change the
file's settings, but it will set it to sync with the project settings, so that
changes to the entire Debug project will affect the individual file. Do the
same for framing.c.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/486libogg2's bitpackers cannot be init. due to missing structs2006-06-12T11:35:35ZArc Rileylibogg2's bitpackers cannot be init. due to missing structs```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from o...```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from ogg2/ogg.h (only in ogginternal.h).
This needs to be fixed before any further work can go into py-ogg2 or libwrit.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/483Incorrect use of 'head' in autogen.sh2006-06-12T11:33:55Zrobert.mossIncorrect use of 'head' in autogen.sh```
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
``````
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
```https://gitlab.xiph.org/xiph/ogg/-/issues/21oggpack_read() return value not well defined2006-06-12T11:31:37ZSegher Boessenkoologgpack_read() return value not well defined```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs ...```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs to be unsigned, in ogg as well as
in vorbis.
This will get rid of a lot of compiler warnings on non-x86 and non-gcc
platforms...
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/ogg/-/issues/478oggpackB not handling 9 bit values2006-06-12T11:29:55ZGhost UseroggpackB not handling 9 bit values```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the sa...```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the same
value in 8 bits works. Also oggpackB_read(opb, 0) does not return 0 like
oggpack_read() does.
Unfortunately I've not been able to construct a simpler test case that
demonstrates the 9 bit issue, but I don't think this is a good sign:
running bitwise.c compiled with -D_V_SELFTEST :
[...LSb tests all ok...]
Small preclipped packing (MSb): ok.
Null bit call (MSb): looked at incorrect value!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/464[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer poi...2006-06-12T11:25:54ZTim van Holder[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer pointer```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
an...```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
and is free()d in oggpack_writeclear(), this seems like a (fairly major) bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/91documentation doesn't mention gmake requirement2006-06-12T11:25:10Znisharfidocumentation doesn't mention gmake requirement```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neithe...```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neither $GZIP_ENV nor $TAR are defined in my shell.
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/ogg/-/issues/60src/Makefile.am doesn't work with outside-the-tree builds2006-06-12T11:23:31Zahltorpsrc/Makefile.am doesn't work with outside-the-tree builds```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
===...```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
==========
RCS file: /usr/local/cvsroot/ogg/src/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- Makefile.am 2000/11/02 20:11:33 1.3
+++ Makefile.am 2001/10/08 01:29:52
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = foreign
-INCLUDES = -I../include
+INCLUDES = -I../include -I$(top_srcdir)/include
lib_LTLIBRARIES = libogg.la
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/295Runtime DLL used in Debug Mode2006-06-12T11:22:35ZGitlab BotRuntime 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 the "ogg_static.dsp".
```Stan SeibertStan Seibert