Oh, then you're right and the package is broken. The DLL name must definitely match what's referenced by the import library.
Search Criteria
Package Details: mingw-w64-icu 75.1-2
Package Actions
| Git Clone URL: | https://aur.archlinux.org/mingw-w64-icu.git (read-only, click to copy) |
|---|---|
| Package Base: | mingw-w64-icu |
| Description: | International Components for Unicode library (mingw-w64) |
| Upstream URL: | https://icu.unicode.org/ |
| Keywords: | icu mingw mingw-w64 |
| Licenses: | custom |
| Submitter: | xantares |
| Maintainer: | pingplug |
| Last Packager: | pingplug |
| Votes: | 16 |
| Popularity: | 0.000000 |
| First Submitted: | 2013-10-17 08:42 (UTC) |
| Last Updated: | 2024-08-02 01:00 (UTC) |
Dependencies (3)
- mingw-w64-crt (llvm-mingw-w64-toolchain-ucrt-binAUR, llvm-mingw-w64-toolchain-msvcrt-binAUR)
- autoconf-archive (autoconf-archive-gitAUR) (make)
- mingw-w64-configureAUR (llvm-mingw-w64-configureAUR) (make)
Required by (8)
Sources (5)
Martchus commented on 2021-04-29 17:12 (UTC)
jpcima commented on 2021-04-29 16:45 (UTC)
@Martchus, the rename gives the dll the correct name that it should have. If you examine the dll.a file, you will notice it references a dll name which is not "lib"-prefixed.
Martchus commented on 2021-04-29 15:04 (UTC) (edited on 2021-04-29 15:06 (UTC) by Martchus)
@jpcima It is true that the static library should rather be placed within lib but before moving things around make sure the library is not referenced anywhere, e.g. CMake modules. I'm also afraid that you must not simply change the name of the DLL. The name of the DLL is incorporated within the corresponding import library (so if one links against the import library a dependency to the DLL is created). It might also be an intentional decisions by upstream to add the lib prefix to the DLL name which we shouldn't revert without a good reason.
Note that this package generally works, e.g. I was able to rebuild ICU against the latest version.
jpcima commented on 2021-04-29 13:06 (UTC)
Some libs don't get installed at their correct locations. It's weird and inconsistent, and I don't know how to explain it, but this can be fixed with a couple of lines. see https://git.io/J3tMp
colonelx commented on 2020-07-28 21:15 (UTC) (edited on 2020-07-28 21:19 (UTC) by colonelx)
I am getting this:
gpg --recv-keys E1BBA44593CF2AE0
gpg: keyserver receive failed: General error
Fixed by importing https://raw.githubusercontent.com/unicode-org/icu/master/KEYS
gpg --import KEYS
Martchus commented on 2020-04-08 17:06 (UTC) (edited on 2020-04-08 17:07 (UTC) by Martchus)
Please do not use nproc.
@luntik2012 One is supposed to setup such flags in /etc/makepkg.conf instead of hard-coding them in the PKGBUILD file so everybody would be forced to use them. E.g. when building on a Raspberry Pi one might want to build with less than nproc cores because the RAM is otherwise not sufficient.
luntik2012 commented on 2020-04-08 16:29 (UTC)
please, use nproc in make
xantares commented on 2018-02-17 14:48 (UTC)
It sucks to depend on an unstable of the crt, added mingw-w64-icu5x package. Do you know if they release a newcrt soon ?
Martchus commented on 2018-02-14 18:09 (UTC)
What do you mean with all mingw-w64-* packages need rebuild. I doubt that. Likely we only need to rebuild harfbuzz, poppler and qt5-webkit as usual.
Note that requiring ResolveLocaleName also means that this now can only run on Windows 7 or newer.
Pinned Comments