The build does not get far before it runs into trouble in the GNU libstdc++
headers, though:
android-ndk-r10/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include/bits/opt_random.h:33:23:
fatal error: x86intrin.h: No such file or directory
Change-Id: I9d459c64980091ba8bf5b3d631d47342625f6be9
News in this version:
- Solve some limitations of walkthrough mode (fdo#81425)
- Multisampling (better rendering quality, mainly at the edges)
- Better error handling (no crash in case of invalid input file)
Change-Id: I46fdf56b00476614487fbcc04178e43e33a01794
Reviewed-on: https://gerrit.libreoffice.org/11179
Reviewed-by: Zolnai Tamás <tamas.zolnai@collabora.com>
Tested-by: Zolnai Tamás <tamas.zolnai@collabora.com>
If we don't know of any separate DirectX SDK library, don't use the
$DIRECTXSDK_LIB variable which is bogus at that point.
Thanks to Nicholas Ferguson for noticing.
Change-Id: I333478da7757694ca9236fd485e93bbd88305278
Argh, this is getting even uglier.
We cheerfully ignore for now the theoretical possibility that the URE
unorc used by build-time tools (i.e. the configure-expanded
ure/source/unorc) could be different for HOST and BUILD (in case they
use different --enable-canonical-installation-tree-structure), and use
the HOST one for the BUILD tools.
The right thing would probably be to construct the URE unorc in the
relevant Makefile, like we do for fundamentalrc? Or then to just
re-design the whole mess of rc files into some simpler (good luck).
Change-Id: I654309503d0e696778910acadcbf2f6b90ffa02a
Makes CppunitTest_dbaccess_hsqldb_test work also in the
--enable-canonical-installation-tree-structure (on OS X), otherwise
the use of $URE_INTERNAL_JAVA_CLASSPATH (looked up from the URE unorc)
in stoc/source/javavm/javavm.cxx fails.
Change-Id: I5ea045594c32e6a1398b73cff1e4aa8bbe1aa265
The preference for compiler picking on Windows is:
1. vs2012
2. vs2010
3. vs2013
Because vs2013 was considered as unsupported compiler the only
option to acivate is to provide additional option to the autogen:
--with-visual-studio=2013
Now, that vs2013 is up and running change the preference order and
pick the newest installed compiler.
Change-Id: I76412b9a1bd9514904bbcca99230896add0424f1
Reviewed-on: https://gerrit.libreoffice.org/10154
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
The only thing that needs to be reimplemented is the pbuffer based
custom sprite rendering. We should use a FBO with a texture backend
for that. This will also save several OpenGL context switches!
Change-Id: I4aef33ae2499e44c8b5f41c296d8721cb94a37a1
I thought it was possible now to build on Windows with Visual Studio
2013 as the only installed Visual Studio version, but no. I tried on a
fresh Windows 8.1 installation.
This commit fixes the configury a bit at least. (One needs to pass the
--with-visual-studio=2013 option. Otherwise configure gets confused by
the partial (?) VS2012 that seems to be installed, too, when
installing VS2013, and prefers that...)
The build fails at least in external/lcms2, but I'll leave sorting out
that for later.
Change-Id: I15942e4b088a3f0a62c3f7fa8f9b45f77beaff6f
The eventual goal is to make vcl capable of handling a backend
that use double instead of sal_Int32 as its base type
for device coordinate.
Change-Id: I6174f1f4afe00992b95c9163bc21dd54fec98631