summaryrefslogtreecommitdiff
path: root/external/harfbuzz
AgeCommit message (Collapse)Author
2017-02-02workaround libtool library name subst.David Tardon
When libtool links a library with another libtool-based library, it replaces -lfoo by path to installed foo, like $foo-libdir/libfoo.la. harfbuzz would be installed to /usr/local/lib by default, therefore libtool replaces -lharfbuzz by /usr/local/lib/libharfbuzz.la in libfreetype.la, which causes a failure (nonexistent file) when building fontconfig... Change-Id: Ie2510034e69803af084dd90671fdbc8f6863fcf2
2016-12-30build fixJochen Nitschke
apparently harfbuzz is not build with std=c++11 everywhere Change-Id: Ie105706212d9dd32f33bc67c8a878ce8a55e60ef Reviewed-on: https://gerrit.libreoffice.org/32521 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
2016-12-30external/harfbuzz: Silence -fsanitize=nonnull-attributeStephan Bergmann
...as reported during CppunitTest_sw_odfimport Change-Id: I3c8542d46cf1106c9910a04ed1f953459c7c7ea5
2016-12-15Build HarfBuzz with CoreText support also for iOSTor Lillqvist
Change-Id: Id755894def35d59836dff8cff7df1273a8e296b2
2016-11-17chmod -xTor Lillqvist
Change-Id: Ie07ef2f9e9f6d0b31b513afa913b79d9c641e4f1
2016-11-04external/harfbuzz: -fsanitize=functionStephan Bergmann
Change-Id: Ie72eec98f1337e895b81c4ebebeefa4861a5a6a1
2016-11-04external/harfbuzz: Work around ASan out of bounds warningStephan Bergmann
CppunitTest_sccomp_lpsolver failed with the below error. struct _mtx (hb-ot-hmtx-table.hh) has two "variable-sized" array members (each of size VAR=1) longMetric and leadingBearingX, where the latter isn't used anywhere in the code; so removing it would make ASan's variable-sized array member heuristic kick in here and suppress the warning, but who knows whether there's some requirement on the exact sizeof(_mtx). > hb-ot-font.cc:128:12: runtime error: index 3 out of bounds for type 'OT::LongMetric const[1]' > hb_ot_face_metrics_accelerator_t::get_advance(unsigned int) const workdir/UnpackedTarball/harfbuzz/src/hb-ot-font.cc:128:43 > hb_ot_get_glyph_h_advance(hb_font_t*, void*, unsigned int, void*) workdir/UnpackedTarball/harfbuzz/src/hb-ot-font.cc:439:47 > hb_font_t::get_glyph_h_advance(unsigned int) workdir/UnpackedTarball/harfbuzz/src/./hb-font-private.hh:207:12 > hb_ot_position_default(hb_ot_shape_context_t*) workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:613:35 > hb_ot_position(hb_ot_shape_context_t*) workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:719:3 > hb_ot_shape_internal(hb_ot_shape_context_t*) workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:768:3 > _hb_ot_shape workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:792:3 > hb_shape_plan_execute workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:43:1 > CommonSalLayout::LayoutText(ImplLayoutArgs&) vcl/source/gdi/CommonSalLayout.cxx:485:23 > OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*) const vcl/source/outdev/text.cxx:1400:36 > OutputDevice::GetTextArray(rtl::OUString const&, long*, int, int, vcl::TextLayoutCache const*) const vcl/source/outdev/text.cxx:999:35 > OutputDevice::GetTextWidth(rtl::OUString const&, int, int, vcl::TextLayoutCache const*) const vcl/source/outdev/text.cxx:915:19 > ImplFontMetricData::ImplInitTextLineSize(OutputDevice const*) vcl/source/font/fontmetric.cxx:372:30 > OutputDevice::ImplNewFont() const vcl/source/outdev/font.cxx:1100:42 > OutputDevice::GetTextHeight() const vcl/source/outdev/text.cxx:924:14 > vcl::Window::ImplInitAppFontData(vcl::Window*) vcl/source/window/window.cxx:1177:33 > vcl::Window::ImplInit(vcl::Window*, long, SystemParentData*) vcl/source/window/window.cxx:1168:9 > ImplBorderWindow::ImplInit(vcl::Window*, long, BorderWindowStyle, SystemParentData*) vcl/source/window/brdwin.cxx:1758:13 > ImplBorderWindow::ImplBorderWindow(vcl::Window*, SystemParentData*, long, BorderWindowStyle) vcl/source/window/brdwin.cxx:1790:5 > VclPtrInstance<ImplBorderWindow>::VclPtrInstance<vcl::Window*&, SystemParentData*&, long&, BorderWindowStyle&>(vcl::Window*&, SystemParentData*&, long&, BorderWindowStyle&) include/vcl/vclptr.hxx:281:39 > WorkWindow::ImplInit(vcl::Window*, long, SystemParentData*) vcl/source/window/wrkwin.cxx:52:38 > WorkWindow::WorkWindow(vcl::Window*, long) vcl/source/window/wrkwin.cxx:95:5 > VclPtr<WorkWindow> VclPtr<WorkWindow>::Create<vcl::Window*&, long&>(vcl::Window*&, long&) include/vcl/vclptr.hxx:131:46 > (anonymous namespace)::VCLXToolkit::ImplCreateWindow(VCLXWindow**, com::sun::star::awt::WindowDescriptor const&, vcl::Window*, long) toolkit/source/awt/vclxtoolkit.cxx:1195:42 > (anonymous namespace)::VCLXToolkit::ImplCreateWindow(com::sun::star::awt::WindowDescriptor const&, long) toolkit/source/awt/vclxtoolkit.cxx:1306:22 > (anonymous namespace)::VCLXToolkit::createWindow(com::sun::star::awt::WindowDescriptor const&) toolkit/source/awt/vclxtoolkit.cxx:799:12 > non-virtual thunk to (anonymous namespace)::VCLXToolkit::createWindow(com::sun::star::awt::WindowDescriptor const&) toolkit/source/awt/vclxtoolkit.cxx:797:59 > (anonymous namespace)::TaskCreatorService::implts_createContainerWindow(com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, com::sun::star::awt::Rectangle const&, bool) framework/source/services/taskcreatorsrv.cxx:268:73 > (anonymous namespace)::TaskCreatorService::createInstanceWithArguments(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) framework/source/services/taskcreatorsrv.cxx:165:28 > non-virtual thunk to (anonymous namespace)::TaskCreatorService::createInstanceWithArguments(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) framework/source/services/taskcreatorsrv.cxx:133:74 > framework::TaskCreator::createTask(rtl::OUString const&) framework/source/classes/taskcreator.cxx:112:63 > framework::Desktop::findFrame(rtl::OUString const&, int) framework/source/services/desktop.cxx:951:28 > non-virtual thunk to framework::Desktop::findFrame(rtl::OUString const&, int) framework/source/services/desktop.cxx:920:61 > framework::LoadEnv::impl_loadContent() framework/source/loadenv/loadenv.cxx:1017:50 > framework::LoadEnv::startLoading() framework/source/loadenv/loadenv.cxx:379:20 > framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) framework/source/loadenv/loadenv.cxx:165:14 > framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) framework/source/services/desktop.cxx:597:12 > non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) framework/source/services/desktop.cxx:583:64 > (anonymous namespace)::LpSolverTest::setUp() sccomp/qa/unit/lpsolver.cxx:45:67 ... Change-Id: If46d9b82225a70caa9ad2f17fbeb99c6adc63990
2016-11-01Forward debug/optimization flags to external/harfbuzzStephan Bergmann
Change-Id: Ie3bc54a43e46dc28faca9356f414a700a0727cec Reviewed-on: https://gerrit.libreoffice.org/30456 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-11-01Revert "tdf#103403: Wrong glyph advances with Graphite"Khaled Hosny
This reverts commit 3d83c42008ab51202c0577f493e8ed3fde0310b7. A simpler fix in the next commit.
2016-10-31tdf#103403: Wrong glyph advances with GraphiteKhaled Hosny
Patch sent upstream: https://github.com/behdad/harfbuzz/pull/357 Change-Id: I245509d386e83970e4b08bd2a4b20a590303025a
2016-10-20external/harfbuzz: Silence clang-cl -Werror,-Wmicrosoft-enum-valueStephan Bergmann
The code in harfbuzz' src/hb_common.h apparently goes to some length to ensure that any value of type hb_tag_t (aka unit32_t) can be transported as a value of the hb_script_t enum type. However, under MSVC any C (or non-fixed C++) enum type has an underlying type of int, so _HB_SCRIPT_MAX_VALUE of value 0xFFFFFFFF will cause a -Wmicrosoft-enum-value under clang-cl. To not complicate things further, acknowledge that converting between hb_tag_t (an unsigned integer type with 32 value bits) and hb_script_t (a two's-complement signed integer type with 32 value bits) is well-defined under MSVC and drop _HB_SCRIPT_MAX_VALUE (which appears to be an otherwise unused implementation detail) there. Change-Id: Ic03dff64a9dd24683c45347fa78699708c269972
2016-10-18Make sure HarfBuzz module depends on GraphiteKhaled Hosny
Change-Id: I9c1cc9c679ceebeb4e5cd898876aaa7b61c18f17
2016-10-18Build HarfBuzz with Core Text on MacKhaled Hosny
To enable support for AAT fonts. Change-Id: Ifcc7d1672e98f8c067482400b7e45226bed4dbf1
2016-10-18GSoC: Enable building Harfbuzz with GraphiteAkash Jain
Harfbuzz will now need to be built with Graphite support. This allows Harfbuzz to handle Graphite fonts. In case we all building with system Harfbuzz, then it should be built with Graphite support else we error out. Change-Id: I156ec08b9e5ad7ce87cc15e4b5852d9c57c98f7f
2016-09-30Update HarfBuzz to 1.3.2Khaled Hosny
* Only build the library, makes no-freetype patch redundant. * Don’t build ICU support as a separate library, otherwise we would also build the alternative UCDN Unicode functions which we do not use. * Don’t build FontConfig support stuff that was added a few releases ago as we don’t need it as well. Change-Id: Ia5f296c61a6ce2a589b1c521b3c2c7c75dbcf74d Reviewed-on: https://gerrit.libreoffice.org/29342 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-09-16external/harfbuzz: Remove hidden dependency on freetypeStephan Bergmann
In external/harfbuzz/ExternalProject_harfbuzz.mk we are careful to configure harfbuzz --with-freetype=no, but then harfbuzz goes on to nevertheless link some of its programs against freetype. However, those all appear to be test programs that we do not otherwise rely on, so just suppress building them in the first place. (I ran into this when trying to do a 32-bit Linux build in a 64-bit environment, with only very limited 32-bit support installed in the system.) Change-Id: I1bab2ff4b533e5a30d68d72ec001904cb63f5d94 Reviewed-on: https://gerrit.libreoffice.org/28963 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-05-24Add option to enable HarfBuzz support independent of platformAkash Jain
Make HarfBuzz compile on any platform using the --with-harfbuzz option. Support is experimental only. Change-Id: I84fb80f3f8abed8ac877a294cf7ef39cf4cb2e9e Reviewed-on: https://gerrit.libreoffice.org/25369 Reviewed-by: Khaled Hosny <khaledhosny@eglug.org> Tested-by: Khaled Hosny <khaledhosny@eglug.org>
2016-02-18fdo#94009: harfbuzz: don't export symbols from VCLMichael Stahl
Should fix crashes due to symbol clashes in ELF global namespace where system's libharfbuzz.so.0 is loaded as well. Change-Id: I35ffcbe4ac4de5a25cd8bf0cb9a8f0c11f4554c5
2015-08-11gbuild/config stop using VERBOSE, use only verbose=tNorbert Thiebaud
configure.ac was setting VERBOSE=YES/NO when really we use verbose=t or verbose= Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299 Reviewed-on: https://gerrit.libreoffice.org/17634 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2015-05-19external/harfbuzz: work around -fsanitize=functionStephan Bergmann
Change-Id: I8e107c155a99fd68b0aa054435bc85246444b3c6
2015-05-09Update HarfBuzz to 0.9.40Khaled Hosny
Most of ubsan.patch seems to have been applied upstream, and I can’t reproduce the issue referenced for the remaining bits, anyway it is better to push such changes upstream first. Change-Id: Ie56786c01c06d3542052cd91e36d1f707092beba Reviewed-on: https://gerrit.libreoffice.org/15643 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-05-04Use a dummy icu-config when cross-compiling harfbuzz (to Android)Tor Lillqvist
Seems that when cross-compiling to Android from Linux, we apparently have used either the build platform's pkg-config files for ICU, or the build platform's icu-config. Both of which are obviously the wrong thing to do, but apparently it has worked by accident anyway. This makes building for Android on OS X proceed past harfbuzz, at least. Change-Id: I27351f6177438697a1cded642c8c669ba7221009
2015-02-13external/harfbuzz: -fsanitize=vptr needs -frttiStephan Bergmann
Change-Id: I4da774b8ebd2115a7f1ae717843498c0f452f7df
2015-01-26external/harfbuzz: Fix types of functions called via pointerStephan Bergmann
(-fsanitize=function) Change-Id: I009f1558990a46900e2dfa56492827cb6dcfb3cd
2015-01-06external/harfbuzz: Work around -fsanitize=nullStephan Bergmann
Change-Id: I81dc29f5ba2ef442ffb7e2823f02b9bfead24a46
2014-02-27normalize values of CROSS_COMPILINGMichael Stahl
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
2013-10-18Fix building from inside modules moved to externalKhaled Hosny
Change-Id: Id6023dc3751fe70984f489682be17d1ab1855f71
2013-10-17fdo#70393: move harfbuzz to a subdir of externalKhaled Hosny
Change-Id: I3eaa6d95aaa1753822e20d21f90f39cadb939332 Reviewed-on: https://gerrit.libreoffice.org/6276 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
generated by cgit (git 2.34.1) at 2024-12-26 10:23:47 +0000