Search Criteria
Package Details: mingw-w64-assimp 5.4.3-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/mingw-w64-assimp.git (read-only, click to copy) |
---|---|
Package Base: | mingw-w64-assimp |
Description: | Portable Open Source library to import various well-known 3D model formats in an uniform manner (mingw-w64) |
Upstream URL: | http://www.assimp.org/ |
Licenses: | BSD |
Submitter: | xantares |
Maintainer: | patlefort |
Last Packager: | patlefort |
Votes: | 2 |
Popularity: | 0.000000 |
First Submitted: | 2015-10-30 17:33 (UTC) |
Last Updated: | 2024-08-30 20:42 (UTC) |
Dependencies (6)
- mingw-w64-boostAUR
- mingw-w64-minizipAUR
- mingw-w64-zlibAUR
- mingw-w64-cmakeAUR (llvm-mingw-w64-cmakeAUR) (make)
- ninja (ninja-kitwareAUR, ninja-memAUR, ninja-fuchsia-gitAUR, ninja-gitAUR, ninja-jobserverAUR) (make)
- mingw-w64-wineAUR (check)
Latest Comments
1 2 Next › Last »
Martchus commented on 2022-08-01 10:52 (UTC)
Looks like the latest version doesn't build due to some warning treated as error:
Martchus commented on 2022-01-08 16:14 (UTC)
Makes sense. It would be best if
makepkg
itself would not pull-in any LTO flags if!buildflags
is set as an option (so we don't have to adjust all our packages and!buildflags
is really ensuring no extra flags are added as one would expect).patlefort commented on 2022-01-03 01:25 (UTC)
I assumed it was only a problem for mingw. After some more reading, gcc on mingw simply doesn't support lto and lto-fat-objects simply allows it to fallback to standard linking, so enabling lto is pointless for static libs. Stripping also is causing problems with lto and static libs from what you linked. So with that, I think it would be reasonable to disable lto with !buildflags and packages can still opt-in on shared libs or .exe. We'll have to bring it up to the maintainers.
Martchus commented on 2022-01-02 21:26 (UTC)
Yes, that's also what's suggested in https://archlinux.org/todo/lto-fat-objects. Adding it to
mingw-env
(or even specific PKGBUILDs) seems conceptionally wrong, though. Wouldn't it be better if that flag was added at the same point where other LTO flags are added?Static libs with LTO enabled also seem quite big so it is questionable whether we actually want it for mingw-w64 packages (which generally contain static libs in contrast to regular packages)?
patlefort commented on 2022-01-02 14:07 (UTC)
I found out that adding
-ffat-lto-objects
fix the issue with static linking. Maybe it should be added to the default flags inmingw-env
?Martchus commented on 2022-01-02 11:01 (UTC)
Since you had to disable LTO: I'm wondering whether disabling buildflags should disable lto as well. Otherwise we needed to disable it likely in many packages or workaround issues with static libraries.
xantares commented on 2021-06-09 17:06 (UTC)
It should be fixed now
Martchus commented on 2021-06-09 15:40 (UTC) (edited on 2021-06-09 15:47 (UTC) by Martchus)
Luckily assimp is only an optional dependency for mingw-w64-qt6-quick3d. I guess for now I'll simply disable the feature completely.
Btw, it looks like the regular package is also using the bundled version and they also ran into the build error: https://github.com/archlinux/svntogit-packages/blob/packages/qt6-quick3d/trunk/qt6-3d-gcc11.patch
Martchus commented on 2021-06-09 14:54 (UTC)
I was trying to compile mingw-w64-quick3d for the 6.1.1 update and ran into the following error:
Apparently Qt's build system is unable to make use of the package. I've only noticed it now because now the bundled assimp no longer compiles (likely just a missing
#include
).I've also noticed that there's no static version of the library which would be needed for the static Qt builds. If you look at the condition producing the warning within the CMake module that's actually the condition to distinguish shared from static builds so likely this is a prime example for a library where the static version can not easily be installed alongside the shared version (without running into configuration issues). Maybe I'll just try to make it work with the bundled version for now.
patlefort commented on 2020-11-03 19:15 (UTC)
Yes that's what I meant.
1 2 Next › Last »