summaryrefslogtreecommitdiff
path: root/external/lcms2
AgeCommit message (Collapse)Author
2019-10-16Allow building lcms2 with Windows SDK 8.1Mike Kaganski
Change-Id: I81052f7634c7873d893d67deb79ed7bfa6dcbc44 Reviewed-on: https://gerrit.libreoffice.org/80888 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-04-16Initial VS 2019 SupportTomoyuki Kubota
Change-Id: I8e08efb549ebd52c37183a1185d6de73f2b00601 Reviewed-on: https://gerrit.libreoffice.org/64630 Reviewed-by: himajin100000 <himajin100000@gmail.com> Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-16Minimum Supported Version is VS2017himajin100000
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c Reviewed-on: https://gerrit.libreoffice.org/66424 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-01-16lcms2: upgrade to release 2.9Michael Stahl
... at least, that's the plan - this is harder than it appears, as the upstream maintainer appears to have released version 2.9 at least 3 times: - Fedora has a file evidently downloaded before Nov. 17 with SHA512 of e30ad5a9a1ab9e7aaace9431434caa19a5ff6143db46644aba971a5ee37a265b26bf738e886d766405a7eb45a9d620d67c7ab3684ace86a107cf5a76642c04a5 - Gentoo has a file evidently downloaded before Nov. 19 with SHA256 of d4ad6f8718f7f9dc8b2a3276c9f237aa3f5eccdcf98b86dedc4262d8a1e7f009 - Debian has a file evidently downloaded before Dec. 17 with SHA256 of 48c6fdf98396fa245ed86e622028caf49b96fa22f3e5734f853f806fbc8e7d20 The lcms2-2.9.tar.gz available from sourceforge currently matches the one Debian has, so let's use it. * 0017-Upgrade-Visual-studio-2017-15.8.patch added (fixing CVE-2018-16435) * 0001-Added-an-extra-check-to-MLU-bounds.patch.1 removed (fixed upstream) Change-Id: Iab8dada8f6d77d5b2da8560993380b3332bc02f6 Reviewed-on: https://gerrit.libreoffice.org/66400 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2017-11-07external/lcms2: Stop warnings/errors about "register"Stephan Bergmann
...when workdir/UnpackedTarball/lcms2/include/lcms2.h is included from workdir/UnpackedTarball/pdfium/core/fpdfapi/page/cpdf_colorspace.cpp (Library_pdfium). Even with -std=gnu++17, GCC only emits a warning (that is not promoted to an error when building external Library_pdfium) about "register", but at least recent trunk Clang does emit an error by default. (Clang used to have a bug by which it failed to emit any warning/error for uses of "register" on function parameters, but that got recently fixed with <http://llvm.org/viewvc/llvm-project?view=revision&revision=317140> "Fix missing -Wregister warning when 'register' is applied to a function parameter", causing an --enable-werror build failure now when building in C++17 mode with <https://gerrit.libreoffice.org/#/c/43851/> "Build as C++17 when GCC/Clang supports it" locally included.) So instead of trying to further demote any warnings/errors about those uses of "register", just patch them away for good. Change-Id: I7c8757e654d87be710eaaafa871300656d9ee8ff
2017-10-10use gbuild way to update config.*, continuedDavid Tardon
Change-Id: I9abf1742c213f47c576ffbb7dafd33087f7037e5 Reviewed-on: https://gerrit.libreoffice.org/43307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-06-22--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutilStephan Bergmann
Change-Id: I277f30129560ea9fa76d6439a60bb191358df99d Reviewed-on: https://gerrit.libreoffice.org/39088 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-11iOS lcms2 support for arm64jan Iversen
Added patch to support arm64 Change-Id: Ie5d9ea3f3bed6e8f3142f0209a0068bb698a3960
2017-05-30sal,external: remove checks for obsolete VCVER=120Michael Stahl
Change-Id: I4d32b7c4b2e545a8d979bc516f64cfcbf66ecd07
2017-03-07lcms2: try to get rid of $(DEVENV) /UpgradeMichael Stahl
It's not clear to me that this is actually required, particularly why it would be required for VS 2015 but not VS 2017, and why only for this external and not the others that use MSBuild.exe. Reportedly this can fail if you have an expired or not yet registered VS, while strangely enough everything else compiles fine in that case, so rather than try to find out how to check for that issue in configure, avoid the problem by removing the /Upgrade. Change-Id: I55566e109e57117f65febb91de7580667c984a54 Reviewed-on: https://gerrit.libreoffice.org/34947 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-02-22MSVC 14.0: Make it work with older SDK versionDavid Ostrovsky
Change-Id: I50a9e8b122250af445c2a1b3d0941d508e027318 Reviewed-on: https://gerrit.libreoffice.org/34528 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-21Fix check for non-empty UCRTVERSIONStephan Bergmann
...introduced with b862cbdd345ec57c2595629ded6a3969e1e65d56 "Support MSVC 15.0", but $(filter ...,) always expands to the empty string, and this is probably what was intended. Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862 Reviewed-on: https://gerrit.libreoffice.org/34482 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-15Support MSVC 15.0David Ostrovsky
New compiler changes quite some stuff: * Compiler detection done based on different registry key * .NET SDK detection done based on different registry key * Msbuild installation directory changed * Merge modules installation directory changed * SDK number in registry doesn't match the directory name: (registry key: 10.0.14393, directory name: 10.0.14393.0) * Compiler, include and library location directories changed * Architecture specific directory changed: x64 instead of amd64 * Compiler own include directory must be added with -I option * To force usage of SDK 10 (8.1 is selected per default) new switch WindowsTargetPlatformVersion is passed to msbuild, to avoid patching VC project files with this line: <WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion> Known issues: * Firebird is broken: http://paste.openstack.org/show/594333 Change-Id: I148d7932aff43bbbd07bd493504df974726234c2 Reviewed-on: https://gerrit.libreoffice.org/31279 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-01upload lcms2 2.8David Tardon
Change-Id: I8a3b138c051d3cddf25855a635262311669bdddc Reviewed-on: https://gerrit.libreoffice.org/33798 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2016-08-29lcms2: Out-of-bounds read in Type_MLU_Read() (rhbz#1367357)Michael Stahl
Change-Id: I9c5a442125476412435ebefea29ad1b166faab8a
2016-07-11Break gb_DEBUGINFO_FLAGS out of gb_DEBUG_CFLAGSStephan Bergmann
...in preparation of making them orthogonal Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52 Reviewed-on: https://gerrit.libreoffice.org/27056 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-04-22pass original CFLAGSDavid Tardon
Change-Id: I1a2e9d41226822934b64ad31a61c816b3163a9ed
2016-03-12Fix lcms2 on MSVC 14.0David Ostrovsky
Without explicitly specifying toolset v140, the build was failing when only MSVC 14.0 was installed: The builds tools for v120 (Platform Toolset = 'v120') cannot be found Change-Id: I6fb386d56e38cbf922de5069e70a3d3def147c0b Reviewed-on: https://gerrit.libreoffice.org/23162 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: Jenkins <ci@libreoffice.org>
2016-01-29Android autoconf fixesPeter Foley
Change-Id: I3429f6a80dd7e080e8f2634ca744d1dac5ea1865 Reviewed-on: https://gerrit.libreoffice.org/21558 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: jan iversen <jani@documentfoundation.org>
2015-09-09externals: remove various obsolete MSVC2012 specific flagsMichael Stahl
Change-Id: I8848d042a008c21e407d9610161b5c67d2137a18
2015-07-09Lcms2: Fix compilation on VS 2015David Ostrovsky
Change-Id: I303494f692520cdd34b88f9d5daf8a92a6b72ca2 Reviewed-on: https://gerrit.libreoffice.org/16803 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-06-05simplify conditionDavid Tardon
Change-Id: I9e69e9d7fc8d3c0ccd393efca75be04c710fee6a
2015-06-05use $(DISABLE_DYNLOADING)David Tardon
Change-Id: I0636f45bf5653ff3feabfdc2742eb767f1b84507
2015-01-28external/lcms2: Work around -fsanitize=alignmentStephan Bergmann
Change-Id: I57c49172fa5bb19968bf217285d0cd9222cc3530
2014-12-02lcms2: Don't hard code Win32 platform on WindowsDavid Ostrovsky
Change-Id: I60701b2c0a0ec06ada24b397107b337676dbd319 Reviewed-on: https://gerrit.libreoffice.org/13229 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2014-11-11Avoid -fsanitize=signed-integer-overflowStephan Bergmann
Change-Id: I1a8ae99401e488e2ece47be4119843945154ef98
2014-11-11Pass down some CFLAGSStephan Bergmann
Change-Id: I2c69d9ad61137adb82213ad2a4c40e7403a395a5
2014-10-02fdo#82430: MSVC build: avoid using SSE2 instructions in some externalsMichael Stahl
Hopefully this should fix up the most important external libraries. Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
2014-08-26Update some external config.{guess,sub}Stephan Bergmann
...to latest versions from <http://git.savannah.gnu.org/gitweb/?p=config.git; a=blob_plain;f=config.guess;hb=HEAD> and <http://git.savannah.gnu.org/gitweb/? p=config.git;a=blob_plain;f=config.sub;hb=HEAD>, for aarch64 support. Change-Id: I99756c33652aa8e19c6a407260b5c49de140128e
2014-07-28Add separate project file for VS2013Tor Lillqvist
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
2014-07-11VS2013: Adjust lcms2 to 12.0 vcproj versionDavid Ostrovsky
Change-Id: I5ec1ea40e57c7d9de337645421be89e1e4c5a867 Reviewed-on: https://gerrit.libreoffice.org/10157 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2014-07-07Handle VCVER==120 (VS 2013) tooTor Lillqvist
Change-Id: I4dbf663790bd8906ef8b123a01bdf52e0c0c1962
2014-05-26externals: do not use "v110_xp" when building with MSVC 2012 and SDK 8.0Michael Stahl
Change-Id: I40bc9e4c31e270f29cc145b5d2f3544cad586bf7
2014-05-19fdo#77891 fix python crash when in GUI mode, target WinXP with VS2012Christian Lohmaier
VS2012 did change return value of fileno function, this results in a crash when run in GUI mode (but not when launching from a shell), as python tries to access the nonexisting stdin/stdout/stderr Also explicitly target Windows XP Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
2014-05-13no lcms2d.dll nowadays, there is only lcms2.dllMatúš Kukan
Change-Id: I0d6537da5d605a011bd9b4491c472b0b58fcd668
2014-05-12upgrade to lcms2-2.6Thomas Arnhold
Change-Id: Iaa5593d1593c9a54127c9019a4121af6a207d4c5 Reviewed-on: https://gerrit.libreoffice.org/9317 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
2014-02-27normalize values of CROSS_COMPILINGMichael Stahl
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
2013-10-28gbuild: set Package default target to INSTDIRMichael Stahl
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
2013-10-27gbuild: remove gb_ExternalPackage_add_library_for_installMichael Stahl
Deliver all external libraries to INSTDIR directly. Change-Id: I8d3e035e5cfa07bd0f53ee4a226c48d4b86a4032
2013-10-24lcms2: use libraries from WORKDIRMichael Stahl
Change-Id: Ieddc80d510884eeb6f64325f9dfbb34f1d3fb0b5
2013-10-19fdo#70393: move lcms2 to a subdir of externalKhaled Hosny
Change-Id: I122a8564795f3a422d6bb10a5d6a845b72e77102 Reviewed-on: https://gerrit.libreoffice.org/6327 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
generated by cgit (git 2.34.1) at 2024-07-06 23:00:12 +0000