| Commit message (Collapse) | Author | Files | Lines |
|
up http://redmine.kokuaviewer.org/issues/598 and http://redmine.kokuaviewer.org/issues/602
|
|
discussed on IRC and the mailing list, and remove some SL logos.
I know, there are two slightly different LICENSE-logos.txt files.
One that was originally in the source repo, one that was from the artwork package.
I'm a coder, not a lawyer, and not the owner of those copyrights, so left them as is.
|
|
to do so: (have anything for crosscompiling installed),
export WORD_SIZE='32'
before configuring and/or building.
Be aware: Mixing several platforms in one root directory probably wont work (didn't try though).
Cross compiling the 64bit viewer on a i686 platform isn't tested, but probably will work using export WORD_SIZE='64'
|
|
|
|
This might also be possible on other platforms, the newer your gstreamer
is, the easier to get rid of libxml2.
|
|
for Linux64 the 32bit compatibility libs (32bit openal et al.)
are now integrated into the openal package.
|
|
But lloctree crashes teleporting to mega regions using -ffast-math .
|
|
|
|
package project still currently only supports 'Release'
|
|
|
|
This is accomplished by dynamically reordering the CMake variable
CMAKE_CONFIGURATION_TYPES so that the current build type (the value
of CMAKE_BUILD_TYPE) is listed first.
|
|
Run "make package" in the build directory to create a tarball.
|
|
viewer_info.py provides a way to easily query the viewer name and
version (from viewerinfo.cpp). It replaces build_version.py, which has
been removed. BuildVersion.cmake has been updated to use
viewer_info.py instead of build_version.py.
|
|
|
|
thanks to Aleric and Siana for the idea
|
|
|
|
GStreamer010Plugin.cmake and fixed some out-of-date lib requirements for Windows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(notes: need to add archives for iconv and gstreamer to install.xml, doesn't link yet)
|
|
Note: only VS2005 libs currently included
|
|
libs (linux)
(cherry picked from commit a3cffd06a0e7aa92e1b6c28e7bad655b7085296c)
|
|
GCC 4.0 on Mac OS X 10.5 can't handle SSE4, GCC 4.2 fails.
|
|
|
|
To use ld.gold configure with:
-DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold".
ld.gold links the viewer on my machine in 8 seconds, as
opposed to 19 seconds with ld.bfd. Moreover, it uses a
LOT less memory during linking (about 750 MB instead of
2.5 GB!). Thanks to Siana Gearz for pointing out that
ld.gold is so much faster.
|
|
See http://jira.secondlife.com/browse/SNOW-713
This patch makes llcommon shared. It contains the following snowglobe
(SVN) changesets: 3478, 3479, 3480, 3481, 3482, 3485, 3496, 3498, 3500,
3519 and 3531, plus the fix for all rejects. Note that changes
to scripts/automated_build_scripts/opensrc-build.sh (changesets 3500
and 3625) were ignored as we don't have scripts/automated_build_scripts.
|
|
|
|
|
|
Also, darwin doesn't use quicktime, so disabled compiling that plugin
for darwin.
|
|
can be sorted on windows
|
|
using standalone.
|
|
|
|
Standalone now works (I have no idea why it worked before, since
obviously I tested it before committing the previous commit).
|
|
default, gcc-4.2 is used and 10.5 SDK is auto selected. Build from commandline in Release mode now work perfectly (./develop.py -t Release build) without the need for Xcode at all.
|
|
If Qt is found in a non-standard place, you still have
to set LD_LIBRARY_PATH yourself (to $QTDIR/lib) before running
imprudence of course (or the webkit plugin will silently fail).
|
|
|
|
Plus some white space fixes (TABs --> spaces) in install.xml.
|
|
|
|
|
|
|
|
|
|
Related information from Nemurimasu Neiro:
stay away from find_library!
due to an undocumented feature of find_xxx functions in CMake, no
additional libraries may be found after the first call to a find_xxx
function that searches the prebuilt libraries folder. CMake will request
the folder contents *at most once* and libraries added by install.py
will be missed.
|
|
libs (linux)
This patch fixes the problem that there were no 'developer' symlinks
for the prebuilt packages (which is not needed for runtim), causing
the casual user that tries to compile the viewer on linux (without
using --standalone) to link against their system libs (while using
the header files of the prebuilt versions), often causing linker
errors.
It also fixes the fact that a few libraries were completely missing,
most notably the dbusglib package only had header files and not
a library at all! libgio and libpangocairo where missing from the
link command line so that the wrong libraries were picked up, if
any at all.
Finally, the last GTK related prebuilt libraries have simply been
removed from the packaging: linux has those installed (or else
the users will know how to install them as soon as they see that
the viewer complains about a missing library). This is much more
stable, as all those libraries more or less form a whole.
Or rather, the libraries that use glib, as especially that one
gives a problem at the moment since the latest glib has new
g_malloc_n functions that don't exist in the prebuilt glib.
Note the difference between a USER compiling her own viewer,
and the imprudence team compiling a release:
When the imprudence team compiles a release we need to create
a portable binary that runs on many versions of linux. In order
to achieve that we link against "old" library versions, so
that the viewer still works on old operating systems, and
(hopefull) also on newer systems, since libraries with the
same SONAME are backwards compatible. With g_malloc_n as
example: our viewer binary doesn't use that function, so
a user that links with their own glib will never have a problem,
whether or not his library provides this function.
On the other hand, when a user gets the sources and compiles
his own viewer he wants to use the LATEST library versions:
his own operating system ones. The best way to achieve this
is to configure with --standalone, but that currently demands
that ALL libraries are installed on her system, including
a few very-hard-to-get libraries. If she therefore chooses
to configure without --standalone, she suddenly gets all
the old library versions, forcing her to at least link against
those at compile time (in order to minimize the risk of version
incompatibilities). A better solution for the do-it-yourself
user would be to have a --semi-standalone configuration that
only uses the hard-to-get prebuilt libs and further uses
as much the operating system libraries as possible. For most
of the hard-to-get libraries this is no problem since they
all only depend on libc and similar stable ABI libs.
|
|
Related information from Nemurimasu Neiro:
stay away from find_library!
due to an undocumented feature of find_xxx functions in CMake, no
additional libraries may be found after the first call to a find_xxx
function that searches the prebuilt libraries folder. CMake will request
the folder contents *at most once* and libraries added by install.py
will be missed.
|