In general glTF shader files does not contain version
directives and in some case it make shader compiler
using GLSL 1.1 which leads to that the shader compiler
fails.
So we need to append the choosen version number which is
GLSL 1.3 in case of libgltf, but this also means that
from that point OpenGL 3.0 is the new reuirements since
GLSL 1.3 is available only from that version.
Change-Id: Ic4382266432ea474aeb3e603b32a998b9aeed280
Here only handle precision. Using precision unconditionally
causing problems when shader source is compiled with GLSL 1.2.
The #version dircetives can be added by the glTF parser.
For example libgltf implementation:
https://gerrit.libreoffice.org/gitweb?p=libgltf.git;a=commit;
h=e4544a8b5ca8470a96bf28c6ccdb7461e78ca293
Change-Id: I934cdfa8651a8787fbcd476cea9892bf7e89dd11
That's why it was worked in some case, when OpenGL ES is
available then it is the default and not the GLSL 1.1.
Change-Id: I60d545e76115396433df8dc300bc13935099c776
It seems under linux we need to specify the version number
explicitly, because otherwise shader compiler will use GLSL 1.1
and will fail. Base line is GLSL 1.3 or OpenGL ES 3.0.
Change-Id: Ie143275ade8d6989fda055ab96943b25ef220e9d
There is only a single libmwaw switch to enable both "noopt + symbols"
and "debug messages", and we enable that switch in debug builds.
Backport upstream patch to avoid a debug message during type detection.
Change-Id: I53440ceed90529e3db7c9d91c788c7a3b2723eb1
I noticed in the debugger that this code tried to load a freebl dylib, but
after then making it link to the freebl entry point statically, I no longer
see it being entered. Huh, confusing. Making NSS work on iOS to the extent we
need is a pain.
Change-Id: Iafc3785752587c38566441f566e187859022733e
(hopefully, the various ccc script variants do not include code that would
unintentionally fail the script with -e)
Change-Id: Ia04291983d99a8cf5a74e6a0078e179c17a93f2b
Let's hope that the various static archives that get built by the NSS
build machinery contain what an iOS app that needs NSS services
requires. I patch out the construction of any dylibs and executables
in nss. We don't use any dylibs on iOS anyway, and of course don't
need any NSS executables either.
Change-Id: Ic977c6e3d6c4e953202e78f8e08c4e61f6c9cb1b
Otherwise those external projects will fail, because with only VS2013 installed
there is no ToolsVersion 4.0 (which is set inside the VC projects files).
http://msdn.microsoft.com/en-us/library/bb383985.aspx
Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd
For whatever reason the tinderboxes still try to regenerate the
autotools based files, even after applying the generated file
change after the template changes.
These patches aren't needed, as the original problem is the CPPFLAGS
environment visibility, so we drop them.
Change-Id: Idb5caf662c997221337416686313101ad2193e40
The libgltf configure.ac script changes the autotools user variables
CFLAGS and CXXFLAGS, which is not allowed and can overwrite user
settings (which it does for the -D_GLIBCXX_DEBUG flag).
So this moves the special compile settings to seperate variables and
passes them to AM_CXXFLAGS and AM_CPPFLAGS, so the library actually
gets compiled with libstdc++ debug objects.
Change-Id: I00989f5fb629a6aac43ee5a2eb287b0491a3b86d
Add a patch to mangle the project files a bit so that they work better
on a machine with only VS2013 installed. At least in my case. But why
we still need to *also* have those /p:PlatformToolset=v120
/p:VisualStudioVersion=12.0 in the ExternalProject_coinmp.mk I don't
know.
Change-Id: Ieebd729c3ba89cf22231fb943f3739d6be5c7acd
Easier than trying to figure out how to make the VC2010 project work
with VS2013, it seems. Luckily it works fine tojust have VS2013
upgrade the old project file and then pass that to msbuild.
Change-Id: I94c0248211767d97f2898f35b1b677aee372a329
Easier than trying to figure out how to make the VC2010 projec work
with VS2013, it seems. We only need a project file for the lcms2_DLL
project.
Change-Id: Icab47ac7625b9a492942ea0835fe52ef06cdf2d9
Linking libxml2 against ICU libraries has a nasty side effect:
The URE library javavm.dll links against URE libxml2.dll, which
is now linked against OOO icuuc53.dll; when a URE program, like
uno.exe, tries to load javavm.dll it fails because the OOO layer
"program" dir is not on PATH; this breaks the installation of Java
extensions.
Fix that by splitting up ICU libraries and putting the required ones
into URE layer.
(regression from 7515b1a90f)
Change-Id: If98dd0357162cb632d9762cd2d20162de5eb1a52
