from autobuild.xml's darwin64 Release and ReleaseOS build (xcodebuild)
command.

-D passed to xcodebuild does NOT set CMake variables. These switches, in this
 place, have never worked as intended.

Turns out that without HAVOK, we can't build the PhysicsExtensions_TPV; but
the viewer's build.sh is unaware of CMake switches set in autobuild.xml.
Passing those CMake overrides in build.sh allows us to test that setting
elsewhere in build.sh to skip the PhysicsExtensions_TPV step -- instead of
failing the build.

If the only use of a variable is within llassert(), have to make the
declaration conditional on SHOW_ASSERT rather than guesswork about release
builds.

Without that symlink, the helper app can't find CEF and we get no web content.

Someone evidently figured every static LLPipeline method should have at least
one void* parameter. There were methods requiring void* parameters that were
completely ignored.

More to the point, there were methods whose callers have a U32 in hand -- and
which want to use a U32 -- but which bizarrely forced callers to cast to void*
just so the method could cast back to U32. In a 64-bit compile, this isn't
merely pointless, it's erroneous. Change all such methods to accept U32;
remove (void*) casts from call sites.

While at it, fix LLPipeline API to use bool, true, false rather than their
obsolete all-caps predecessors. Once you eat that first potato chip... :-P

clang has started to reject our non-const comparison operator methods used
within standard algorithms.

The signature for LLTracker::stopTracking() was silly: it accepted a void* for
the sole purpose of testing whether it was NULL. In other words, the parameter
was really a bool in void* clothing. Most callers passed NULL.

What got ugly was when you wanted to pass 'true', or a variable bool value.
Such values had to be cast to void*. In 64-bit land, the compiler correctly
flags that as extremely dubious practice.

But it's entirely unnecessary. Since stopTracking() wants a bool, change its
parameter to bool. Everybody wins.

(While at it, change a few related method params from BOOL to builtin bool.)

Since BOOL is simply a typedef for int, casting a 64-bit pointer to 32-bit int
is correctly diagnosed by the compiler as an error.

What works is to cast the pointer to (lowercase) bool, the builtin type, which
engages the compiler's test for "is this pointer NULL?"

LLWLAnimator stores a std::map<F32, LLWLParamKey>. But llwlanimator.h only
forward-declared LLWLParamKey, begging the question of how this ever compiled
on any previous platform.

LLWLParamKey was declared for real in llwlparammanager.h, so the obvious fix
is to #include "llwlparammanager.h" in llwlanimator.h. Unfortunately this
doesn't work because llwlparammanager.h already #includes "llwlanimator.h".

As the dependency is specifically on LLWLParamKey, which isa LLEnvKey, which
is declared in llenvmanager.h, move LLWLParamKey to llenvmanager.h. Then we
can #include "llenvmanager.h" in llwlanimator.h instead of merely forward-
declaring LLWLParamKey.

This migration compiles LLWLParamKey in a context in which LLTrans isn't
visible. It's not really clear why all LLWLParamKey's methods are inline, but
toString() -- the method that requires LLTrans -- isn't going to be fast in
any case. Break toString() out to llenvmanager.cpp, and #include "lltrans.h"
there.

Storing it in a U32 and then comparing it to std::string::npos isn't going to
work in 64 bit land.

It's not really clear to me why the original coder felt it necessary to cast
the two sigaction::sa_sigaction fields to unsigned int in the first place, but
in a 64-bit clang compile, that discards information.

Going forward, the intention is to set in 00-Common.cmake only switches not
already set for ALL viewer-related libraries in
https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables.

To that end, remove all switches redundant with settings from that file.
Remove redundancies within 00-Common.cmake.
Remove cruft testing for gcc versions older than 4.3.

Turns out that Monty didn't intend for the int-flavored representation of
HttpStatus to expand to 64 bits even when unsigned long is that wide. So
change the implicit conversion operator, and its uses, to U32 instead. That
produces a consistent toHex() result for both 32-bit and 64-bit builds.

When std::istream::good() returns false, presumably we can no longer rely on
get() returning valid data. Certain streamtools tests were assuming that get()
would return the empty string at EOF, but in fact it appears that it left the
previous buffer contents unmodified.

Ruslan points out that changing TYPE_MAX could lead to extra (useless) render
passes. We will have to solve the TYPE_INDEX > TYPE_MAX problem another way.

Ruslan assures me that in fact this usage is valid.

LLStatGraph::Threshold has an operator<(const Threshold& other) -- but because
the method itself wasn't marked const, it could only be used on a non-const
instance. This change fixes a case when it was applied to const instances.

when passing -- something -- to glVertexAttribPointerARB() in
LLVertexBuffer::setupVertexArray().

LLVertexBuffer::TYPE_INDEX was past TYPE_MAX, which is used to set the maximum
sizes of various (scattered) arrays, bleh. The alarm bells that this SHOULD
set off are indeed correct: TYPE_INDEX was being used to index at least one of
those arrays, meaning we've been indexing past the end of that array, meaning
undefined behavior.

The enum that defines both TYPE_INDEX and TYPE_MAX provides a helpful comment
indicating what things must be updated when modifying the enum. (Far better to
define things centrally in a single place... but another time.) Update the
designated arrays to include a final TYPE_INDEX entry. Contents of those
entries are wild guesses -- but even wild guesses are better than completely
indeterminate data.