mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Mircea Ciocan <m.ciocan@ppc-ag.de>
To: christian melki <christian.melki@t2data.com>
Cc: ptxdist <ptxdist@pengutronix.de>
Subject: Re: [ptxdist] util-linux fail to compile with 2023.10.0
Date: Wed, 25 Oct 2023 21:53:33 +0200 (CEST)	[thread overview]
Message-ID: <793465806.493628.1698263613576.JavaMail.zimbra@ppc-ag.de> (raw)
In-Reply-To: <ca9faa95-9904-4626-932a-cf690fa5f0c3@t2data.com>



----- Ursprüngliche Mail -----
Von: "Christian Melki" <christian.melki@t2data.com>
An: "Mircea Ciocan" <m.ciocan@ppc-ag.de>
CC: "ptxdist" <ptxdist@pengutronix.de>
Gesendet: Mittwoch, 25. Oktober 2023 21:38:18
Betreff: Re: [ptxdist] util-linux fail to compile with 2023.10.0

On 10/25/23 15:48, Mircea Ciocan wrote:
> Hello list,
> 
> while attempting to compile ptxdist with 2023.10.0 I've encountered a failure in cfdisk package, that is build regardless if it is selected or not in the ptxconfig :(, no one seems to use PTXCONF_UTIL_LINUX_CFDISK to select if the cfdisk utility is build or not,

Hi!

This is is what I see:
CFDISK is a separate flag that sets FDISKS.
FDISKS is then used to build all fdisks.
But only the selected fdisks get installed.
I don't see an error here?

but unfortunately if also no other packages that use the ncurses library
are also not selected, when cfdisk is compiled the following error occurs:

Do I understand it correctly when you say that the only user of ncurses
in your entire build is cfdisk? Seems quite odd, hence my rather stupid
question. In that case, can you please check that NCURSES actually gets
built before util-linux?
And that your selected ptxconfig contains ncurses?

> 
> [479/612] Linking target cfdisk
> FAILED: cfdisk 
> /opt/OSELAS.Toolchain-2023.07.0/arm-v7a-linux-gnueabihf/gcc-13.2.0-clang-17.0.1-glibc-2.37-binutils-2.41-kernel-6.1-sanitized/lib/gcc/arm-v7a-linux-gnueabihf/13.2.0/../../../../arm-v7a-linux-gnueabihf/bin/ld: platform-dabija/build-target/util-linux-2.39.2-build/../util-linux-2.39.2/disk-utils/cfdisk.c:685:(.text+0x50): undefined reference to `wclrtoeol'
> /opt/OSELAS.Toolchain-2023.07.0/arm-v7a-linux-gnueabihf/gcc-13.2.0-clang-17.0.1-glibc-2.37-binutils-2.41-kernel-6.1-sanitized/lib/gcc/arm-v7a-linux-gnueabihf/13.2.0/../../../../arm-v7a-linux-gnueabihf/bin/ld: platform-dabija/build-target/util-linux-2.39.2-build/../util-linux-2.39.2/disk-utils/cfdisk.c:697:(.text+0xae): undefined reference to `wattr_on'
> [...snip many more similar messages...]
> 
> Maybe the maintainer of the package will have a look, because I think there may be some other packages that are not actually constrained with the ptxconf selection options.
> 

I couldn't reproduce this in 09 or 10. x86_64 or arm-v7a.
Now I don't have an ncurses cfdisk only build nor do I have OSELAS as
toolchain. I don't think the latter should make much of a difference
though. Our toolchain for arm-v7a looks rather similar in components.

Regards,
Christian

> Best regards,
> Mircea
>

Thanks for the answer Christian, I'm at home now, but I remember that there were actually three sub-packages of util-linux that were selecting ncurses, in my configuration, by chance, none of them was selected and no other packages in the whole configuration are using ncurses, as my device is fully headless, there is no need for it.
The problem is that cfdisk can be individually de-selected in menuconfig, but still it is build, if is actually installed in the fw image even if deselected, this I don't know, I can test if you like.
Would be nice if cfdisk (and other parts of util-linux that can be individually deselected in the configuration menu) could be inhibited to be build at all when not selected, I don't know if is possible as an util-linux configuration parameter.
Right now, if I select cfdisk in the configuration menu, the build succeeds but I have yet another library that I don't need as well as anotother useless utility (for the specific use case).
I really don't know how to solve this, and I will be happy to learn from this, the whole Meson crazyness is still new to me.
BTW, the previous release set of rules are working, but I believe these are still autoconf based.


 Best regards,
 Mircea




  reply	other threads:[~2023-10-25 19:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 13:48 Mircea Ciocan
2023-10-25 19:38 ` Christian Melki
2023-10-25 19:53   ` Mircea Ciocan [this message]
2023-10-27  6:16 ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=793465806.493628.1698263613576.JavaMail.zimbra@ppc-ag.de \
    --to=m.ciocan@ppc-ag.de \
    --cc=christian.melki@t2data.com \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox