OpenSSL on Windows does not pull certificates from any well-known
 location (in fact most binaries continue to use the default Unix
 path, which usually doesn't even exist).
We could ship our own set of certificates (e.g., cloned from the
 Mozilla root list), but I don't want to be responsible for
 releasing libopusfile updates when things like DigiNotar
 fiasco [1] happen.
That approach also means that we would need to load, parse, and
 keep a copy of every certificate in the system for every SSL
 session.

OpenSSL has had patches sitting in their bugtracker which load
 certificates from the Crypto API's system certificate store.
However, those patches have been sitting around for several years,
 so movement on that front in the near future seems unlikely.
We don't care about using OpenSSL's builtin CAPI engine, though, so
 we can do the same thing with less than 200 lines of code.
This puts the maintenance burden on Windows Update, which will be
 far more timely and effective than getting people to upgrade
 libopusfile, and gets us on-demand loading of just the
 certificates we need.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=682927>

Apparently Vista includes more things in its Winsock implementation
 and errno.h than earlier versions of Windows.

This keeps differences which can be cleanly abstracted away clean
 (closesocket, ioctlsocket, getsockopt, setsockopt), and makes
 differences which cannot be cleanly abstracted explicit (SOCKET,
 INVALID_SOCKET, WSAGetLastError/WSASetLastError).
It also gets rid of wsockwrapper.[ch], since it contained just a
 single function.

This can successfully pass the seeking_example tests on
 big.chained.blob over https when built with i686-w64-mingw32 and
 run under wine.
It does not solve the certificate distribution problems with using
 OpenSSL on a real Windows system.

It turns out i686-pc-mingw32 does define these functions, and they
 are always available (unlike _fseeki64/_ftelli64).
This means we can build and link without requiring
 i686-w64-mingw32.
The resulting binary still doesn't run in wine for me, but that may
 be a personal problem.

This allows an i686-pc-mingw32 build to use getaddrinfo/
 freeaddrinfo correctly.
It's not needed for an i686-w64-mingw32 build, but it doesn't hurt
 to leave it in here.
i686-pc-mingw32 still won't work correctly, because it does not
 support fseeko/ftello, nor (unless using MSVCRT 8.0 or later)
 _fseeki64/_ftelli64.
We could define __MSVCRT_VERSION__ to 0x800 to get the latter, but
 this would require different MSVCRT versions than libogg and
 libopus are built with by default, which makes a bit of a mess.

Properly check for HTTP support and handle the case where it's
 disabled.
Also fixes the include paths broken by 3e7f0ddc.

The former is too generic.

Some tweak might be still needed to take care of OPENSSL_AppLink
to get https support working. In win32, user application of openssl
is required to include openssl/applink.c or something, when openssl
is compiled with OPENSSL_USE_APPLINK.

I don't know how it should be taken care of, from the library point of
view (it must be done by user of libopusfile, since openssl always
searches that function in executable module).

Posted to the hydrogenaudio format 2012 November 19.
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=97856&view=findpost&p=814582

The assert might also be helpful for static analysis.

These are useful alternatives to the autoconf build,
since we're maintaining them we should include them
in release packages.

This was needed in the opus Makefile.am to pass the results
to submakefiles. Since we build everything from the top-level
Makefile, we don't need this for opusfile.

I don't think it actually breaks anything if we don't (seeking will
 fail, but it will fail cleanly).
However, it _is_ an indication that the file data changed out from
 under us (or of another library bug), so we should fail fast.

Using op_get_prev_page_serial() meant if there were valid pages
 from another stream, we would re-scan them all repeatedly until we
 managed to back up, a page at a time, to a chunk with a page from
 the preferred stream with a valid granule position.
Breaking this case into its own function means we can guarantee we
 only scan each page once, and that we can stop as soon as we hit a
 page from a different link (in the unlikely event that the stream
 has no pages with valid timestamps).

Be more specific about which RFC we're quoting in the SSL hostname
 verification.

Adding AM_MAINTAINER_MODE([enable]) preserves the current behaviour of
rebuilding the autotools support by default if anything changed to make
it out of date -- which is desirable for people building from git to
avoid "Why is the build broken? Oh I forgot to rerun autogen.sh", which
is an all too frequent FAQ.

But it also allows it to be disabled, which is mostly useful for things
like distro package builds where the files should be preserved in their
original form, and configure shouldn't be run twice on the first build
if the timestamps were not strictly preserved for these files.

Signed-off-by: Ralph Giles <giles@mozilla.com>

The opusfile and install-opusfile targets let us build and install just
the library (without the docs, even if doxygen is present and enabled).

The docs and install-docs targets let us build and install just the docs
without the library.

The default for make and make install remains to build both if doxgen
is present and enabled.

Signed-off-by: Ralph Giles <giles@mozilla.com>

We'll want that stuff in the release tarballs, even if the person running
make dist doesn't have doxygen installed (or --enabled) themselves.

Signed-off-by: Ralph Giles <giles@mozilla.com>

Mostly so that people looking at or cloning it later don't get confused
into thinking that they are.

Signed-off-by: Ralph Giles <giles@mozilla.com>

Thnks to Ron Lee for the report.

Thanks to Ron Lee for the report.

The 'echo' built into /bin/sh on MacOS X doesn't support -n, which
confuses the AC_INIT macro. Use the separate binary which does.

The jenkins autotools build has never worked because we try to
build against uninstalled versions of the opus and ogg libraries,
whose pkg-config files export a static library. This works fine
for executables, but libtool seemingly can't link a dynamic library
against a static library.

We could change the -uninstalled.pc files to reference the libtool
versions of the libraries, but that breaks the unix makefile builds,
which of course don't use libtool.

As a work around, write out our own versions of the pc files and
use those to reference the file we need.

Also sets -x on both continuous integration scripts so it's more
clear what steps are being applied.

Fixes the case where a raw IPv6 address would be rejected as not
 looking like a FQDN.
Also simplifies the wildcard comparison a little.

a7c5b93c flipped the argument to it from true to false, since it
 made certificate checking actually work.
This commit removes the option entirely to avoid encouraging people
 to use it now that that checking does work.

seeking_example still disables checking (since it's not really
 needed).

We weren't loading the default certificate store, so there were no
 trusted certificates to validate hosts with, and all checks would
 fail (unless explicitly disabled with
 OP_SSL_SKIP_CERTIFICATE_CHECK(0)).
This adds that call, and also adds hostname verification (which
 OpenSSL does not do for us, because they are morons).
I've done my best to get the latter right by reading the RFCs, but
 this stuff is complex, it's easy to make mistakes, and I only have
 a limited ability to test it, so caveat emptor.

This is, as far as I can remember, the process I went through
to produce the 0.1 source and win32 binary packages.

I also added a few things I wish I'd done, like stripping
the binaries and including release notes and dependency versions
in the README to help us remember next time.

We need the sed invocation to strip the 'v' prefix
when naming the dist tarball.

We use some C99 features (like lrintf) despite passing
-std=c89 -pedantic. This works on normal linux and mac
builds because we define _GNU_SOURCE, which enables
them, but the mingw32 headers ignore this, generating
warnings for lrintf and _putenv, the later hacked in
by libtool.

Avoid these by undefining __STRICT_ANSI__ in mingw builds,
which allows the default extensions and fixes the warnings.

This should make mingw32-configure --enable-http less confusing.

This avoids trying to build in http support when cross-compiling
for windows.

Also cleans up some adjacent formatting.

Instead of assigning the return code to a local variable and then
 using OP_ASSERT(), define a new OP_ALWAYS_TRUE() macro that still
 evaluates its argument when assertions are disabled.
This avoids -Wunused-but-set-variable warnings from clang and
 useless scan-build reports (if scan-build is run without
 assertions enabled).