With Clang, LTO means compiling to LLVM intermediate representation
instead of object code, and optimisation and code generation at link
time.
As expected, linking the single executable for the iOS experimental
app takes quite some time (several hours), and in fact it eventually
fails. Hopefully better luck on OS X.
Need to use xcrun to find the right ar and ranlib, too, from the
Xcode toolchain being used.
Change-Id: Iee69397c57bf1d622882ad78c188e1734f6cbd63
on Windows Server 2012, it ends up in
c:/Program Files (x86)/Windows Kits/8.0/bin/x86/wilangid.vbs and
c:/Program Files (x86)/Windows Kits/8.0/bin/x64/wilangid.vbs
(files are identical)
No full-blown configure check is needed IMHO, since that stuff is part
of a bigger install, and not installed separately.
AFAICT it is only used when building the translated installsets
Change-Id: I1238717bb08635848bb4c54bf4f6b4049e0bc777
Reviewed-on: https://gerrit.libreoffice.org/4468
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
With slightly different semantics:
Instead of pointing at a previous checkout,
point at base directory of all repos.
Change-Id: I254ecc33071be53067c44610b030f737cf75a7ee
At least Clang trunk towards 3.4 now rejects incompatible declarations of the
same extern "C" function in different namespaces, so that trick of getting at
the function that is exported by libstdc++ but only rudimentarily if at all
exposed in cxxabi.h no longer worked.
TODO: This change should be reflected in any other bridges where it is relevant,
too.
Change-Id: Ie3ccbdb7d75cc98636d02c0435958532620724f2
MSVC supports (a subset of) C++11 without any special switch, so always
"enable" support for it and use whatever features are detected by configure
checks
Change-Id: Ic03be5a1aabe7d20cf763bae6d26a7043a51f287
...post d7ae9f7743d946845a8379e2fb47666f124e2c87 "rename HAVE_CXX0X->HAVE_CXX11
and clean up to #define in a config header."
Change-Id: Ie8f62c78c9aabe06736a25e60a3035880470e7b5
Removed in 44159c6cdf3127ef8ee628f07f3f2d38a93dc3b2 , but since it's
set in CXX, this either has to pass, or it has to fail (or it shouldn't
be hardcoded the way it is).
Change-Id: If5b7b7096927f5d97c7c744cbbfea08e90f1de55
Do not confuse GCC and libstdc++ versions. Clang defines GCC
version #defines, so the old version was wrong for it. Correct __GLIBCXX__
values found from GCC/libstdc++ repository history.
Change-Id: I94f5250609f7c9a114b2d15093abc9ca4209b13f
It definitely does not make sense for iOS, I assume. For Android the situation
is unclear, but let's disable it for now. It causes linking errors currently
anyway as the graphite_serverfont.cxx is not compiled for Android. (Whether it
could and should be compiled then instead of disabling Graphite, I don't
know.)
Change-Id: I1a874d304af508d2217da08e49dc158664f2e9d2
We always should use the internal epm anyway on OS X, so no need to
look for PackageMaker.app in /Developer which doesn't even exist any
more.
Change-Id: I943f34e14e9ce0c3bec5bd7b86612a62e5b9e83d
