Files
RedBear-OS/recipes/libs/libogg/source
vasilito a399e7da08 cleanup: remove stale tracked files (1.3M lines)
Survey of the working tree found 83 tracked files
that no longer exist on disk (tracked-but-missing).
Most were inside source/ dirs (extraction differences
between git revisions) and are out of scope for this
commit. The 28 non-source tracked-but-missing files
fell into these categories:

  1. Broken self-referential symlinks in driver and
     tui recipes (5 files):
     - local/recipes/drivers/ehcid/ehcid ->
       ../../local/recipes/drivers/ehcid (loops)
     - local/recipes/drivers/ohcid/ohcid -> ...
     - local/recipes/drivers/uhcid/uhcid -> ...
     - local/recipes/drivers/usb-core/usb-core -> ...
     - local/recipes/tui/mc/mc -> ...
     These were created by the now-removed
     apply-patches.sh symlink-overlay system. Per
     AGENTS.md § 'NO OVERLAY-STYLE PATCHES', the
     overlay pattern is retired. Recipes now use the
     `path = 'source'` form in [source] blocks
     pointing at the in-tree Red Bear fork. The
     self-referential symlinks broke because the
     overlay indirection was removed.

  2. Broken absolute-path symlinks in gpu/driver
     recipes (2 files):
     - local/recipes/gpu/drivers/linux-kpi/source
       -> /mnt/data/homes/kellito/Builds/rbos/...
     - local/recipes/gpu/drivers/redox-driver-sys/source
       -> /mnt/data/homes/kellito/Builds/rbos/...
     These were committed on a different filesystem
     layout. The actual source trees are in
     `local/sources/{linux-kpi,redox-driver-sys}/`
     and are loaded via `path = 'source'` config.

  3. Tracked empty `~` (emacs backup) files in
     autotools-generated source dirs (13 files).
     Autotools regen produces `configure~`,
     `config.h.in~`, etc. whenever a developer runs
     `autoreconf` in the source dir. These are
     ephemeral working files, not upstream source.
     Re-running the cookbook's autoreconf will
     regenerate them on the next fetch.

  4. Tracked-but-missing upstream WIP recipes
     (12 recipes, 596 files):
     - recipes/wip/dev/build-system/{meson,ninja-build}
     - recipes/wip/dev/other/{bison,flex}
     - recipes/wip/libs/gnome/libepoxy
     - recipes/wip/libs/other/m4
     - recipes/wip/libs/qt/qt6/{qt6-sensors,
       qt6-sensors-local}
     - recipes/wip/wayland/qt6-wayland-smoke
     - recipes/wip/x11/{libxau,libxcb,x11proto}
     These were tracked in the upstream Redox WIP
     area but the underlying dirs/files no longer
     exist on disk (likely removed when upstream
     WIP was reorganized). They were never
     referenced by any `config/redbear-*.toml`
     and have no surviving tree dependencies.

  5. Top-level `gparted-git/` orphan (4 files):
     A staging dir from a previous attempt to add a
     gparted recipe (RBPKGBUILD + import/). The recipe
     was never finished and the postmortem H-4 says
     it was 'removed' but the dir persisted.

  6. `recipes/gpu/drivers` tracked as a file blob
     but working tree has it as a directory.
     Tree conflict from a prior overlay layout.

.gitignore additions:
  - `*\~` (emacs backup)
  - `.*.swp`, `.*.swo` (vim swap)
  These patterns prevent future accidental commits
  of ephemeral editor / autotools-regen files.

Net effect: 617 files removed, 1,304,942 lines
deleted from tracked history, 0 lines added. The
working tree is now 0 tracked-but-missing files
outside of source/ dirs (source/ extraction
differences are out of scope for this commit).
2026-06-13 00:26:21 +03:00
..

Ogg

Travis Build Status Jenkins Build Status AppVeyor Build Status

Ogg project codecs use the Ogg bitstream format to arrange the raw, compressed bitstream into a more robust, useful form. For example, the Ogg bitstream makes seeking, time stamping and error recovery possible, as well as mixing several sepearate, concurrent media streams into a single physical bitstream.

What's here

This source distribution includes libogg and nothing else. Other modules (eg, the modules libvorbis, vorbis-tools for the Vorbis music codec, libtheora for the Theora video codec) contain the codec libraries for use with Ogg bitstreams.

Directory:

  • src The source for libogg, a BSD-license inplementation of the public domain Ogg bitstream format

  • include Library API headers

  • doc Ogg specification and libogg API documents

  • win32 Win32 projects and build automation

  • macosx Mac OS X project and build files

Contact

The Ogg homepage is located at https://www.xiph.org/ogg/ . Up to date technical documents, contact information, source code and pre-built utilities may be found there.

Building

Building from tarball distributions

./configure
make

and optionally (as root):

make install

This will install the Ogg libraries (static and shared) into /usr/local/lib, includes into /usr/local/include and API documentation into /usr/local/share/doc.

Building from repository source

A standard svn build should consist of nothing more than:

./autogen.sh
./configure
make

and as root if desired :

make install

Building on Windows

Use the project file in the win32 directory. It should compile out of the box.

Cross-compiling from Linux to Windows

It is also possible to cross compile from Linux to windows using the MinGW cross tools and even to run the test suite under Wine, the Linux/*nix windows emulator.

On Debian and Ubuntu systems, these cross compiler tools can be installed by doing:

sudo apt-get mingw32 mingw32-binutils mingw32-runtime wine

Once these tools are installed its possible to compile and test by executing the following commands, or something similar depending on your system:

./configure --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux
make
make check

(Build instructions for Ogg codecs such as vorbis are similar and may be found in those source modules' README files)

Building with CMake

Ogg supports building using CMake. CMake is a meta build system that generates native projects for each platform. To generate projects just run cmake replacing YOUR-PROJECT-GENERATOR with a proper generator from a list here:

mkdir build
cd build
cmake -G YOUR-PROJECT-GENERATOR ..

Note that by default cmake generates projects that will build static libraries. To generate projects that will build dynamic library use BUILD_SHARED_LIBS option like this:

cmake -G YOUR-PROJECT-GENERATOR -DBUILD_SHARED_LIBS=1 ..

After projects are generated use them as usual

Building on Windows

Use proper generator for your Visual Studio version like:

cmake -G "Visual Studio 12 2013" ..

Building on Mac OS X

Use Xcode generator. To build framework run:

cmake -G Xcode -DBUILD_FRAMEWORK=1 ..

Building on Linux

Use Makefile generator which is default one.

cmake ..
make

License

THIS FILE IS PART OF THE OggVorbis SOFTWARE CODEC SOURCE CODE. USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING.

THE OggVorbis SOURCE CODE IS COPYRIGHT (C) 1994-2019 by the Xiph.Org Foundation https://www.xiph.org/