On Wed, 2024-05-01 at 08:17 +0200, Zoltan Boszormenyi via
lists.openembedded.org wrote:
> The build framework of zip adds -DNO_DIR to CFLAGS after
> failing to link this piece of test code:
>
> int main() { return closedir(opendir(".")); }
>
> However, zip does not take a case into account when it does not
> need to link to an extra library for these functions.
>
> When -DNO_DIR is used, the code in unix.c defines custom
> opendir()/readdir()/closedir() functions in a way that GCC 14
> chokes on.
>
> GLIBC has both <dirent.h> and <sys/dir.h> and apps don't need
> any extra library to link with.
>
> Add a patch to remove the definition of NO_DIR.
> Instead, use -DHAVE_DIRENT_H in the recipe.
>
> Remove 0002-unix.c-Do-not-redefine-DIR-as-FILE.patch which
> is now unnecessary.
>
> This fixes the compiler error observed with GCC 14.
>
> Signed-off-by: Zoltán Böszörményi <zbos...@gmail.com>
> ---
> ...2-unix.c-Do-not-redefine-DIR-as-FILE.patch | 35 -------------------
> .../zip/zip-3.0/dont-define-NO_DIR.patch | 14 ++++++++
> meta/recipes-extended/zip/zip_3.0.bb | 6 ++--
> 3 files changed, 17 insertions(+), 38 deletions(-)
> delete mode 100644
> meta/recipes-extended/zip/zip-3.0/0002-unix.c-Do-not-redefine-DIR-as-FILE.patch
> create mode 100644 meta/recipes-extended/zip/zip-3.0/dont-define-NO_DIR.patch
>
[...]
> diff --git a/meta/recipes-extended/zip/zip-3.0/dont-define-NO_DIR.patch
> b/meta/recipes-extended/zip/zip-3.0/dont-define-NO_DIR.patch
> new file mode 100644
> index 0000000000..8528dbb55e
> --- /dev/null
> +++ b/meta/recipes-extended/zip/zip-3.0/dont-define-NO_DIR.patch
> @@ -0,0 +1,14 @@
> +Upstream-Status: Inactive-Upstream [no upstream]
> +Signed-off-by: Zoltán Böszörményi <zbos...@gmail.com>
> +
> +--- zip30/unix/configure~ 2024-05-01 07:22:18.000000000 +0200
> ++++ zip30/unix/configure 2024-05-01 07:23:04.725337836 +0200
> +
I'm struggling to get to replying to patches for review but I just
wanted to explain the issue here.
The challenge is this change removed one patch and added a new one
which is fine but the new patch has no headers/information on it.
In the context of this commit, it makes sense but anyone coming to it
later would wonder what the issue was, why it was there and so on.
Whilst it is a pain, some of the info in the commit does need to be
duplicated into the patch header so that over time, we can know why
we're carrying these things.
I believe Khem tweaked and sent a v2.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199142):
https://lists.openembedded.org/g/openembedded-core/message/199142
Mute This Topic: https://lists.openembedded.org/mt/105836341/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
