Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2009-04-19T20:20:08Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/289[PATCH] MacOS building of ogg & 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/229shared library not built2006-06-12T11:13:16Zshattyshared library not built```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to ...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libogg_la_LDFLAGS = -version-info @LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
new version:
libogg_la_LDFLAGS = -no-undefined -version-info
@LIB_CURRENT@:@LIB_REVISION@:@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.)
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/222devel rpm doesn't include aclocal/ogg.m42002-07-29T18:45:54Znoadevel rpm doesn't include aclocal/ogg.m4```
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
``````
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/163minor problem in in_vorbis plugin and may be ...2002-02-20T07:16:24Zxakepminor problem in in_vorbis plugin and may be ...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link, please download and test this situation.
Thanks.
```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/125media type audio/x-ogg or application/x-ogg should be added to Apache mime.types2002-01-11T11:17:12Zyusufgmedia type audio/x-ogg or application/x-ogg should be added to Apache mime.types```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can th...```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can then utilise Apaches mod_expires module
to generate cache-friendly headers for ogg file which speeds up serving ogg
streams to people behind ISP proxy caches
http://httpd.apache.org/docs/mod/mod_expires.html
This mechanism is explained in depth at
http://www.mnot.net/cache_docs/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/104ogg.m4 refers to ogg-config2006-06-12T10:47:55ZGitlab Botogg.m4 refers to ogg-config```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for m...```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for most trivial 'bug'?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/94100189582017-04-07T21:51:41Zgumboot10018958```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char...```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char -o oggenc oggenc.o audio.o encode.o \
platform.o /usr/lib/libvorbis.so -L/lib /usr/lib/libvorbisenc.so -lm \
/usr/lib/libogg.so ../share/libutf8.a ../share/libgetopt.a
```Michael SmithMichael Smithhttps://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/80crc block generation doesn't set crc_ready2006-06-12T10:57:30Ztimjcrc block generation doesn't set crc_ready```
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
``````
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
```Monty MontgomeryMonty Montgomeryhttps://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/56"ogg_packet_clear" not exported in ogg.def2006-06-12T11:08:23Zadonnai"ogg_packet_clear" not exported in ogg.def```
The function "ogg_packet_clear" isn't listed in ogg.def so linking fails when
calling it. One exmaple, vorbiscomment, couldn't compile because of this bug.
``````
The function "ogg_packet_clear" isn't listed in ogg.def so linking fails when
calling it. One exmaple, vorbiscomment, couldn't compile because of this bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/26'win32/*.bat' do not handle SRCROOT long path names with spaces correctly2006-06-12T10:56:22Ztom'win32/*.bat' do not handle SRCROOT long path names with spaces correctly```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRC...```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRCROOT=c:\src
with the line:
if ".%SRCROOT%"=="." set SRCROOT=c:\src
```starclassstarclasshttps://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/24missing 'ogg_stream_packetpeek' export in 'win32/ogg.def'2006-06-12T10:30:29Ztommissing 'ogg_stream_packetpeek' export in 'win32/ogg.def'```
This breaks the build of the vorbis for the win32 platform
``````
This breaks the build of the vorbis for the win32 platform
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/23oggenc manpage and --help disagree on default bitrate2006-06-12T10:41:39Zjemorrisoggenc manpage and --help disagree on default bitrate```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 k...```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 kbps mode.
(I think line 54 of oggenc.c sets the actual default to 128.)
```Monty MontgomeryMonty Montgomeryhttps://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/13Minor portability issues2006-06-12T11:22:27ZaegiskMinor portability issues```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF...```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF?
I'll attach a patch if desired.
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/2227Bug Tracker does not appear to have any Daala components.2018-05-14T02:24:00ZAnders KirchenbauerBug Tracker does not appear to have any Daala components.Bug Tracker does not appear to have any Daala components.
Want to file an enhancement request against Daala, but don't want to do it as general, don't see any Daala-related things under component dropdown.Bug Tracker does not appear to have any Daala components.
Want to file an enhancement request against Daala, but don't want to do it as general, don't see any Daala-related things under component dropdown.jj