| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
boost libraries when we tend to want statics. Try to work around
that for the moment.
|
|
|
|
hard stall
while allocating the first easy handle in a descent of the global initiailization
code but that doesn't seem to be a problem on TC machines. Perhaps the static
linking is creating multiple data copies. More work needed.
|
|
defenses in the delete functions of the allocation support. General
boost library renaming again. Linux builds in TC though it shouldn't
based on what Boost.cmake lookes like...
|
|
boost::thread and the easiest path to that was to go with the 1.48 Boost release
in the 3P tree (eliminating a fork for a modified 1.45 packaging). One unit test,
the most important one, is failing in test_httprequest but that can be attended
to later. This test issues a GET to http://localhost:2/ and that is hitting the
wire but the libcurl plumbing isn't delivering the failure, only the eventual
timeout. An unexpected change in behavior.
|
|
|
|
|
|
|
|
It appears that the LLTrans machinery, or at least the way it's used in this
program, is buggy: linux-updater.bin has been crashing. Tracebacks and
experimentation identify LLTrans as the culprit, so replace it with baked-in
string constants copied from strings.xml. (linux-updater.bin was already
producing English-only messages because the update_install shell script that
calls it was specifically passing the English version of strings.xml.)
|
|
|
|
|
|
|
|
|
|
on and off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HTTP when all objects loading are done.
|
|
|
|
|
|
|
|
though it's a dead library so far.
|
|
|
|
As a viewer architect, I would like to understand how fast each of the components of the texture pipeline can run in isolation
|
|
disconnect.
Added checks for LLViewerRegion pointer in LLViewerObject being invalid.
|
|
Mindful that some autobuild packages populate only packages/lib/release
(rather than packages/lib/debug), Linking.cmake always appends
packages/lib/release to CMake's link_directories() directive. But since CMake
always appends CMAKE_BUILD_TYPE to those directories, we end up with a phantom
packages/lib/release/Release directory on the search path. This would be
harmless except that the Mac's 'ld' command produces a warning. These warnings
quickly make TC's "Important Messages" output useless. Try appending
packages/lib/release only when the build type isn't already Release.
|
|
the logs when passing
WOLF-363: (partial) correct ordering of cleaning build dir vs running
'autobuild install'
|
|
actual problem but this will quiet the compiler.
|
|
problem as Mac.
|
|
value which wasn't caught in other environments.
|
|
|
|
|
|
|
|
|
|
The unit/integration tests don't work yet as I'm still battling cmake/autobuild
as usual but first milestone passed.
|
|
This handles the case when the target file doesn't exist, just as APR_TRUNCATE
handles the case when it does.
Strengthen error checks concerning downloaded installer file from
ll_apr_warn_status() to ll_apr_assert_status(). Failing to recognize (e.g.)
failure to open that file only leads to mysterious crashes down the road; this
removes the mystery.
|
|
|
|
Reviewed by Ted.
|
|
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In
that case, CreateProcess() passes NO handles -- even the files you've
explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO
struct! Remove LLProcess code to tweak bInheritHandles; we should also remove
the corresponding (useless) APR extension.
Instead, given that the Windows file-locking problem we've observed is
specific to the viewer installer .exe file downloaded by the background
updater logic, use APR file I/O for that specific file. Empirically, both
llofstream and std::ofstream seem to make the open file handle inheritable;
but apr_file_open() documentation says: "By default, the returned file
descriptor will not be inherited by child processes created by
apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
|
|
|
