All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: <yann.morin@orange.com>
Cc: "J . Neuschäfer" <j.neuschaefer@gmx.net>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/Makefile.in: work around buggy filesystem wrt LDFLAGS
Date: Sat, 10 Aug 2024 00:03:25 +0200	[thread overview]
Message-ID: <20240810000325.055e85dc@windsurf> (raw)
In-Reply-To: <0907a7f51a6681bf626ab27febd4a32ddd7e617d.1723208902.git.yann.morin@orange.com>

On Fri, 9 Aug 2024 15:08:22 +0200
<yann.morin@orange.com> wrote:

> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> Some buildsystems (or their use of it by packages) will cause flags in
> LDFLAGS to be re-orderded, or even dropped, causing some incompremsible
> mayhem... For example, gpsd [0] has this in its SConscript [1](typoes
> not mines, for once):
> 
>     591 # scons uses gcc, or clang, to link. Thus LDFLAGS does not serve its
>     592 # traditional function of providing arguments to ln. LDFLAGS set in the
>     593 # environment before running scons get moved into CCFLAGS by scons.
>     594 # LDFLAGS set while running scons get ignored.
>     [--SNIP--]
>     611 for i in ["ARFLAGS",
>     612           "CCFLAGS",
>     613           "CFLAGS",
>     614           "CPPFLAGS",
>     615           "CXXFLAGS",
>     616           "LDFLAGS",
>     617           "LINKFLAGS",
>     618           "SHLINKFLAGS",
>     619           ]:
>     620     if i in os.environ:
>     621         # MergeFlags() puts the options where scons wants them, not
>     622         # where you asked them to go.
>     623         env.MergeFlags(Split(os.getenv(i)))
> 
> So, when LDFLAGS (our TARGET_LDFLAGS) contains "-z text"  (without the
> quotes), that gets turned into a command line like (line-splitted for
> readability):
> 
>     [...]/buildroot/output/host/bin/aarch64_be-buildroot-linux-musl-gcc \
>         -o gpsd-3.25/drivers/driver_rtcm2.os \
>         -c \
>         --sysroot=[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot \
>         -O3 -g0 \
>         -z \
>         -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
>         gpsd-3.25/drivers/driver_rtcm2.c
> 
> Notice how there is a lone "-z" without any following keyword.
> 
> This then causes a build failure that looks totally unrelated [2]:
> 
>     In file included from gpsd-3.25/drivers/../include/gpsd.h:36,
>                      from gpsd-3.25/drivers/driver_rtcm2.c:65:
>     gpsd-3.25/drivers/../include/os_compat.h:40:8: error: redefinition of ‘struct timespec’
>        40 | struct timespec {
>           |        ^~~~~~~~
>     In file included from [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/sys/select.h:16,
>                      from gpsd-3.25/drivers/../include/gpsd.h:31:
>     [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/alltypes.h:237:8: note: originally defined here
>       237 | struct timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };
>           |        ^~~~~~~~
>     gpsd-3.25/drivers/../include/os_compat.h:48:5: error: conflicting types for ‘clock_gettime’; have ‘int(clockid_t,  struct timespec *)’ {aka ‘int(int,  struct timespec *)’}
>        48 | int clock_gettime(clockid_t, struct timespec *);
>           |     ^~~~~~~~~~~~~
>     In file included from gpsd-3.25/drivers/../include/gpsd.h:33:
>     [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/time.h:104:5: note: previous declaration of ‘clock_gettime’ with type ‘int(clockid_t,  struct timespec *)’ {aka ‘int(int,  struct timespec *)’}
>       104 | int clock_gettime (clockid_t, struct timespec *);
>           |     ^~~~~~~~~~~~~
>     scons: *** [gpsd-3.25/drivers/driver_rtcm2.os] Error 1
>     scons: building terminated because of errors.
>     make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/gpsd-3.25/.stamp_built] Error 2
>     make: *** [Makefile:83: _all] Error 2
> 
> Although undocumented, neither in gcc not ld (clang unchecked by lack of
> a clang toolchain here, and by lack of clang knowledge), -z accepts the
> keyword to be snatch-glued onto it, like -zkeyword, rather than be
> spearated with a space. So, use that to pass -ztext.
> 
> Fixes:
>     http://autobuild.buildroot.org/results/c03/c039989947b960ac6af17c87090366abc26dcb6d/
>     http://autobuild.buildroot.net/results/bc35d3e7b0e8c59c776652070650af3c749250ee/
> 
> [0] Our other scons-based package, mongodb, does not build for another
> reason that probably hides the same issue as seen with gpsd.
> 
> [1] As explained in gpsd's SConscript (se above), Scons does play tricks
> with variables:
>     https://scons.org/doc/production/HTML/scons-man.html#f-MergeFlags
>     https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
> 
> Quoting:
>     Flag values are translated according to the prefix found, and added
>     to the following construction variables:
>     [...]
>     -Wl,                    LINKFLAGS
>     [...]
>     -                       CCFLAGS
>     [...]
>     Any other strings not associated with options are assumed to be the
>     names of libraries and added to the $LIBS construction variable.
> 
> So in our case, it finds that -z is an unknown option that matches the
> '-' prefix, so it is added to CFLAGS, while 'text' is a string on its
> own, so added to LIBS, and thus it would try to link with -ltext
> (supposedly, because we do not even go that far). Funnily enough, we can
> se that "-Wl," is a known option prefix, that is added to LINKFLAGS (to
> properly be used with gcc or clang, not ld).
> 
> As a consequence, gpsd's buildsystem does drop -ztext from the link
> flags, and only passes it to the compile flags, which brings us back to
> before we banned textrels in a1a2f498d7ec (package/Makefile.in: ban
> textrels on musl toolchains). Fixing gpsd is a task for another,
> separate patch...
> 
> [2] I spent quite some time to look at recent, time-related changes in
> Buildroot, especially due to the infamous time64_t issues... Alas, that
> was not related, and only a git-bisect pinpointed the actual issue. Poor
> polar bears...
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: J. Neuschäfer <j.neuschaefer@gmx.net>
> ---
>  package/Makefile.in | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      parent reply	other threads:[~2024-08-09 22:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-09 13:08 [Buildroot] [PATCH] package/Makefile.in: work around buggy filesystem wrt LDFLAGS yann.morin
2024-08-09 13:14 ` yann.morin
2024-08-09 14:37 ` J. Neuschäfer via buildroot
2024-08-09 22:03 ` Thomas Petazzoni via buildroot [this message]

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=20240810000325.055e85dc@windsurf \
    --to=buildroot@buildroot.org \
    --cc=j.neuschaefer@gmx.net \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin@orange.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.