strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-gobmx/external/libffi/ExternalProject_libffi.mk

53 lines
1.8 KiB
Makefile
Raw Normal View History

python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#
$(eval $(call gb_ExternalProject_ExternalProject,libffi))
$(eval $(call gb_ExternalProject_register_targets,libffi,\
build \
))
# set prefix so that it ends up in libffi.pc so that pkg-config in python3 works
libffi: build DLL on Windows The build setup is rather horrible, with some minimal gcc MSVC wrapper. But the DLL is a prerequisite for the Python 3.8 build, which dropped the internal libffi. It's also possible to build it statically, but then you have to patch the Python 3 _ctypes msbuild properties. This also defaults to explicit --build and --host settings, even without a cross build, because the predicted name would otherwise differ (*-unknown-* instead of *-pc-*). Additionally a "make install" also fails... Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-14 16:20:06 -05:00
# For a static Windows build, change CPPFLAGS to include -D_LIB and --disable-static
# Also remove the ExternalPackage in that case
libffi_WIN_PLATFORM := $(strip \
$(if $(filter INTEL,$(CPUNAME)),32) \
$(if $(filter X86_64,$(CPUNAME)),64) \
Rename LO Windows arm64 ID to aarch64 The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-03-22 16:13:39 -05:00
$(if $(filter AARCH64,$(CPUNAME)),arm64) \
libffi: build DLL on Windows The build setup is rather horrible, with some minimal gcc MSVC wrapper. But the DLL is a prerequisite for the Python 3.8 build, which dropped the internal libffi. It's also possible to build it statically, but then you have to patch the Python 3 _ctypes msbuild properties. This also defaults to explicit --build and --host settings, even without a cross build, because the predicted name would otherwise differ (*-unknown-* instead of *-pc-*). Additionally a "make install" also fails... Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-14 16:20:06 -05:00
)
python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
$(call gb_ExternalProject_get_state_target,libffi,build):
GBUILD_TRACE, support for finding out where the build time is spent See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-10 03:31:26 -06:00
$(call gb_Trace_StartRange,libffi,EXTERNAL)
python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
$(call gb_ExternalProject_run,build,\
libffi: build DLL on Windows The build setup is rather horrible, with some minimal gcc MSVC wrapper. But the DLL is a prerequisite for the Python 3.8 build, which dropped the internal libffi. It's also possible to build it statically, but then you have to patch the Python 3 _ctypes msbuild properties. This also defaults to explicit --build and --host settings, even without a cross build, because the predicted name would otherwise differ (*-unknown-* instead of *-pc-*). Additionally a "make install" also fails... Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-14 16:20:06 -05:00
export LIB="$(ILIB)" && \
WASM: add initial support for Emscripten cross build - configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-04-23 06:45:05 -05:00
MAKE=$(MAKE) $(gb_RUN_CONFIGURE) ./configure \
python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
--enable-option-checking=fatal \
libffi: build DLL on Windows The build setup is rather horrible, with some minimal gcc MSVC wrapper. But the DLL is a prerequisite for the Python 3.8 build, which dropped the internal libffi. It's also possible to build it statically, but then you have to patch the Python 3 _ctypes msbuild properties. This also defaults to explicit --build and --host settings, even without a cross build, because the predicted name would otherwise differ (*-unknown-* instead of *-pc-*). Additionally a "make install" also fails... Change-Id: Ifb7dac840e23efffb9a5e342560aef9e11e0db79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98436 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-14 16:20:06 -05:00
--build=$(BUILD_PLATFORM) --host=$(HOST_PLATFORM) \
$(if $(filter LINUX,$(OS)), \
--disable-shared \
CC="$(CC) -fvisibility=hidden" \
--with-pic \
--enable-portable-binary) \
$(if $(filter WNT,$(OS)), \
--disable-static \
CC="$(call gb_UnpackedTarball_get_dir,libffi)/msvcc.sh -m$(libffi_WIN_PLATFORM)" \
CXX="$(call gb_UnpackedTarball_get_dir,libffi)/msvcc.sh -m$(libffi_WIN_PLATFORM)" \
LD='link' \
CPP='cl -nologo -EP' \
CXXCPP='cl -nologo -EP' \
CPPFLAGS="-DFFI_BUILDING_DLL $(SOLARINC)") \
python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
--prefix=$(call gb_UnpackedTarball_get_dir,libffi)/$(HOST_PLATFORM) \
--disable-docs \
&& $(MAKE) \
)
GBUILD_TRACE, support for finding out where the build time is spent See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-10 03:31:26 -06:00
$(call gb_Trace_EndRange,libffi,EXTERNAL)
python3: bundle libffi for GNU/Linux builds CPython commit f40d4ddff3c800b3c956a5e8820aabe3aa87cddd "Closes #27979: Remove bundled copy of libffi" causes a bit of a problem because it turns out that libffi isn't all that stable; there's libffi.so.5 on CentOS 6, libffi.so.6 on CentOS 7 and libffi.so.7 on lo_daily_update_gandalf tinderbox. So we have to bundle it in LO; it's only used on GNU/Linux currently. CPython commit 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 "bpo-35947: Update Windows to the current version of libffi (GH-11797)" also removes the libffi for MSVC, so in a future python upgrade we will have to build libffi for MSVC too. The libffi fork for MacOSX is still in CPython git master. (regression from b10be5d48433076f0b7238d818020f708553e114) Change-Id: Ibc20cf8cd3614cf9941b6970662bd930496776b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86493 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09 08:06:07 -06:00
# vim: set noet sw=4 ts=4:
Reference in a new issue Copy permalink