NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
fc7ba3ab8f
kumquat-buildroot/package/assimp/assimp.mk

45 lines
1.4 KiB
Makefile
Raw Normal View History

assimp: new package Signed-off-by: Peter Seiderer <ps.report@gmx.net> ---- Changes v1 -> v2: - use github helper (thanks to Jörg Krause) Changes v2 -> v3: - add c++ dependency (suggested by Thomas Petazzoni) - fix linking problem with builtin zlib (linking code with/without '-fpic' compiled, see e.g. [2]), workaround by selecting buildroot zlib package (failure detected by Thomas Petazzoni [2]) [1] https://cmake.org/pipermail/cmake/2006-March/008482.html [2] http://lists.busybox.net/pipermail/buildroot/2015-December/146859.html Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-17 23:18:18 +01:00
################################################################################
#
# assimp
#
################################################################################
package/assimp: bump version to 5.2.1 For details see [1]. [1] https://github.com/assimp/assimp/releases/tag/v5.2.1 Signed-off-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-02-15 22:41:25 +01:00
ASSIMP_VERSION = 5.2.1
package: remove 'v' prefix from github-fetched packages On Github, a large number of projects name their tag vXYZ (i.e v3.0, v0.1, etc.). In some packages we do: <pkg>_VERSION = v0.3 <pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION)) And in some other packages we do: <pkg>_VERSION = 0.3 <pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION)) I.e in one case we consider the version to be v0.3, in the other case we consider 0.3 to be the version. The problem with v0.3 is that when used in conjunction with release-monitoring.org, it doesn't work very well, because release-monitoring.org has the concept of "version prefix" and using that they drop the "v" prefix for the version. Therefore, a number of packages in Buildroot have a version that doesn't match with release-monitoring.org because Buildroot has 'v0.3' and release-monitoring.org has '0.3'. Since really the version number of 0.3, is makes sense to update our packages to drop this 'v'. This commit only addresses the (common) case of github packages where the prefix is simply 'v'. Other cases will be handled by separate commits. Also, there are a few cases that couldn't be handled mechanically that aren't covered by this commit. Signed-off-by: Victor Huesca <victor.huesca@bootlin.com> [Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite, python-scapy3k, softether] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-06-12 08:42:06 +02:00
ASSIMP_SITE = $(call github,assimp,assimp,v$(ASSIMP_VERSION))
boot, package: use SPDX short identifier for BSD-3c We want to use SPDX identifier for license string as much as possible. SPDX short identifier for BSD-3c is BSD-3-Clause. This change is done using following command. find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/BSD-3c/BSD-3-Clause/g' Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-30 15:43:38 +02:00
ASSIMP_LICENSE = BSD-3-Clause
assimp: new package Signed-off-by: Peter Seiderer <ps.report@gmx.net> ---- Changes v1 -> v2: - use github helper (thanks to Jörg Krause) Changes v2 -> v3: - add c++ dependency (suggested by Thomas Petazzoni) - fix linking problem with builtin zlib (linking code with/without '-fpic' compiled, see e.g. [2]), workaround by selecting buildroot zlib package (failure detected by Thomas Petazzoni [2]) [1] https://cmake.org/pipermail/cmake/2006-March/008482.html [2] http://lists.busybox.net/pipermail/buildroot/2015-December/146859.html Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-17 23:18:18 +01:00
ASSIMP_LICENSE_FILES = LICENSE
package/assimp: add ASSIMP_CPE_ID_VENDOR cpe:2.3:a:assimp:assimp is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aassimp%3Aassimp Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-14 18:38:36 +02:00
ASSIMP_CPE_ID_VENDOR = assimp
Revert "package/assimp: fix musl zlib/zip related compile failure" This reverts commit b529a582ba4d7671597e95d7ab54ee652cbbc261 as it raises a build failure with hiawatha because assimp installs its own zlib library in staging directory. Fixes: - http://autobuild.buildroot.org/results/9cac31962d48245a5579da692dbc9488292a397e Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-01-28 21:04:33 +01:00
ASSIMP_DEPENDENCIES = zlib
assimp: new package Signed-off-by: Peter Seiderer <ps.report@gmx.net> ---- Changes v1 -> v2: - use github helper (thanks to Jörg Krause) Changes v2 -> v3: - add c++ dependency (suggested by Thomas Petazzoni) - fix linking problem with builtin zlib (linking code with/without '-fpic' compiled, see e.g. [2]), workaround by selecting buildroot zlib package (failure detected by Thomas Petazzoni [2]) [1] https://cmake.org/pipermail/cmake/2006-March/008482.html [2] http://lists.busybox.net/pipermail/buildroot/2015-December/146859.html Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-17 23:18:18 +01:00
ASSIMP_INSTALL_STAGING = YES
package/assimp: workaround m68k build issues On m68k coldfire, we already pass -mxgot, but since the bump to assimp 5.0.1, this is no longer sufficient, and we have failures such as: /tmp/ccqmJLil.s: Assembler messages: /tmp/ccqmJLil.s:307948: Error: value -43420 out of range /tmp/ccqmJLil.s:307985: Error: value -38606 out of range /tmp/ccqmJLil.s:308010: Error: value -38626 out of range /tmp/ccqmJLil.s:308056: Error: value -33280 out of range Since these issues only arise when building with -O2, let's disable the optimization for this package on m68k. The very relative relevance of assimp on m68k coldfire makes the research of a better solution not really useful (for the record, assimp is a "library to import various well-known 3D model formats in a uniform manner"). Fixes: http://autobuild.buildroot.net/results/a7d4fb2653b0f1be4d036ee46a44e72da0ed4376/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-25 23:01:41 +02:00
# relocation truncated to fit: R_68K_GOT16O. We also need to disable
# optimizations to not run into "Error: value -43420 out of range"
# assembler issues.
assimp: fix m68k uclinux compile The GCC manual suggest when getting: relocation truncated to fit: R_68K_GOT16O foobar to use -mxgot. https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html Fixes: http://autobuild.buildroot.net/results/63898c00929b4546279bda52148b218f847714ed/ http://autobuild.buildroot.net/results/bb7a107d1ca6e8713e6ccffe6c61c43b777fb962/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-31 20:07:43 +02:00
ifeq ($(BR2_m68k),y)
package/assimp: workaround m68k build issues On m68k coldfire, we already pass -mxgot, but since the bump to assimp 5.0.1, this is no longer sufficient, and we have failures such as: /tmp/ccqmJLil.s: Assembler messages: /tmp/ccqmJLil.s:307948: Error: value -43420 out of range /tmp/ccqmJLil.s:307985: Error: value -38606 out of range /tmp/ccqmJLil.s:308010: Error: value -38626 out of range /tmp/ccqmJLil.s:308056: Error: value -33280 out of range Since these issues only arise when building with -O2, let's disable the optimization for this package on m68k. The very relative relevance of assimp on m68k coldfire makes the research of a better solution not really useful (for the record, assimp is a "library to import various well-known 3D model formats in a uniform manner"). Fixes: http://autobuild.buildroot.net/results/a7d4fb2653b0f1be4d036ee46a44e72da0ed4376/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-25 23:01:41 +02:00
ASSIMP_CXXFLAGS += -mxgot -O0
assimp: fix m68k uclinux compile The GCC manual suggest when getting: relocation truncated to fit: R_68K_GOT16O foobar to use -mxgot. https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html Fixes: http://autobuild.buildroot.net/results/63898c00929b4546279bda52148b218f847714ed/ http://autobuild.buildroot.net/results/bb7a107d1ca6e8713e6ccffe6c61c43b777fb962/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-31 20:07:43 +02:00
endif
package/assimp: also build with -mxgot on mips64(el) Since the bump of assimp to 5.0.1, we have build failures on mips64el, due to relocations being truncated. The issue seems to be quite similar to the one on m68k coldfire, as both m68k and MIPS have this -mxgot gcc option to switch to using a GOT that has no size limit (but causes less efficient code to be produced). Here as well, the overall relevance of assimp on mips64(el) platforms being probably very limited, the incentive to search for a better solution is pretty limited. Fixes: http://autobuild.buildroot.net/results/7df487d5117b2ee440a07dbff9cae1b181566748/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-25 23:01:42 +02:00
# just like m68k coldfire, mips64 also has some limitations on the GOT
# size for large libraries, which can be overcome by passing
# -mxgot. Solves "relocation truncated to fit: R_MIPS_CALL16" issues.
ifeq ($(BR2_mips64)$(BR2_mips64el),y)
ASSIMP_CXXFLAGS += -mxgot
endif
assimp: work around gcc bug on SuperH gcc versions earlier than gcc 6.x fail to build assimp on SuperH when static linking: AssxmlExporter.cpp:623:1: error: unable to find a register to spill in class 'GENERAL_REGS' It's the combination of -Os and *not* having -fPIC that makes gcc fail, which explains why configurations with dynamic linking work fine. -Os -fPIC -> works -Os -> fails -O2 -fPIC -> works -O2 -> works Therefore, as a workaround, we are forcing the use of -O2 on SuperH when the gcc version is older than gcc 6.x and we're statically linking. Fixes: http://autobuild.buildroot.net/results/ec88aa8118179e30e24603cc45292047dca19216/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-26 23:38:26 +01:00
# workaround SuperH compiler failure when static linking (i.e -fPIC is
# not passed) in gcc versions 5.x or older. The -Os optimization level
# causes a "unable to find a register to spill in class
package/assimp: replace utf-8 quote by ascii single quote Signed-off-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-05-07 22:35:21 +02:00
# 'GENERAL_REGS'" error. -O2 works fine.
assimp: fix gcc version condition In commit 68cebedeb977396f64f5f591f5e93f34fab8e0a8 ("assimp: work around gcc bug on SuperH"), a work around was added to make the package build with gcc on SuperH. The condition included a test on the gcc version, which was mistakenly done on the host gcc version, while a test on the target gcc version was intended. Thanks to Peter Korsgaard for spotting the issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-27 22:53:24 +01:00
ifeq ($(BR2_sh):$(BR2_STATIC_LIBS):$(BR2_TOOLCHAIN_GCC_AT_LEAST_6),y:y:)
assimp: work around gcc bug on SuperH gcc versions earlier than gcc 6.x fail to build assimp on SuperH when static linking: AssxmlExporter.cpp:623:1: error: unable to find a register to spill in class 'GENERAL_REGS' It's the combination of -Os and *not* having -fPIC that makes gcc fail, which explains why configurations with dynamic linking work fine. -Os -fPIC -> works -Os -> fails -O2 -fPIC -> works -O2 -> works Therefore, as a workaround, we are forcing the use of -O2 on SuperH when the gcc version is older than gcc 6.x and we're statically linking. Fixes: http://autobuild.buildroot.net/results/ec88aa8118179e30e24603cc45292047dca19216/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-26 23:38:26 +01:00
ASSIMP_CXXFLAGS += -O2
endif
package/assimp: re-enable package on Microblaze With Microblaze ccc version < 8.x the build hangs due to bug 85180: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180. To avoid this, the assimp package has a !BR2_microblaze dependency. However, gcc bug 85180 only triggers when optimization is enabled, so we can work around the issue by passing -O0, which is what we do in other Buildroot packages to work around this bug. So, this commit passes -O0 when BR2_TOOLCHAIN_HAS_GCC_BUG_85180, and re-enables assimp on Microblaze. Note that the comment was talking about gcc bug 71124, but this gcc bug is a duplicate of 85180. Since all Buildroot packages now use the reference to gcc bug 85180 and the option is named BR2_TOOLCHAIN_HAS_GCC_BUG_85180, we use this naming as well for assimp. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-05-22 15:59:02 +02:00
ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_85180),y)
ASSIMP_CXXFLAGS += -O0
endif
Revert "package/assimp: fix musl zlib/zip related compile failure" This reverts commit b529a582ba4d7671597e95d7ab54ee652cbbc261 as it raises a build failure with hiawatha because assimp installs its own zlib library in staging directory. Fixes: - http://autobuild.buildroot.org/results/9cac31962d48245a5579da692dbc9488292a397e Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-01-28 21:04:33 +01:00
ASSIMP_CONF_OPTS += -DASSIMP_BUILD_TESTS=OFF \
package/assimp: wrap long lines Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-15 11:44:31 +02:00
-DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) $(ASSIMP_CXXFLAGS)"
assimp: new package Signed-off-by: Peter Seiderer <ps.report@gmx.net> ---- Changes v1 -> v2: - use github helper (thanks to Jörg Krause) Changes v2 -> v3: - add c++ dependency (suggested by Thomas Petazzoni) - fix linking problem with builtin zlib (linking code with/without '-fpic' compiled, see e.g. [2]), workaround by selecting buildroot zlib package (failure detected by Thomas Petazzoni [2]) [1] https://cmake.org/pipermail/cmake/2006-March/008482.html [2] http://lists.busybox.net/pipermail/buildroot/2015-December/146859.html Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-17 23:18:18 +01:00
$(eval $(cmake-package))
Reference in New Issue Copy Permalink