All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: buildroot@buildroot.org,
	Marcus Folkesson <marcus.folkesson@gmail.com>,
	Kamel Bouhara <kamel.bouhara@gmail.com>,
	Woodrow Douglass <wdouglass@carnegierobotics.com>,
	Julien Olivain <ju.o@free.fr>, Asaf Kahlon <asafka7@gmail.com>,
	Marcin Niestroj <m.niestroj@grinn-global.com>,
	Christian Stewart <christian@aperture.us>,
	Robert Rose <robertroyrose@gmail.com>,
	Fabrice Fontaine <fontaine.fabrice@gmail.com>
Subject: Re: [Buildroot] [PATCH v4 1/6] package/{python-}protobuf: bump to version 28.1
Date: Wed, 6 Nov 2024 22:26:11 +0100	[thread overview]
Message-ID: <20241106222611.338f4a97@windsurf> (raw)
In-Reply-To: <20241030190020.1444105-1-james.hilliard1@gmail.com>

Hello,

Thanks for your work on this complicated package.

On Wed, 30 Oct 2024 13:00:15 -0600
James Hilliard <james.hilliard1@gmail.com> wrote:

> Migrate protobuf build from autotools to cmake.

Unfortunately, while doing so, you have missed to review carefully
protobuf.mk, and you left some code that was autotools-related, and
therefore no longer taken into account after the cmake migration.

In particular:

ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
PROTOBUF_CONF_ENV += LIBS=-latomic
endif

is not taken into account after the cmake migration, but is still
needed, otherwise the build breaks for example on SPARC. It needs to be
changed to:

 ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
-PROTOBUF_CONF_ENV += LIBS=-latomic
+PROTOBUF_CONF_OPTS += -DCMAKE_EXE_LINKER_FLAGS=-latomic
 endif

Also:

PROTOBUF_CXXFLAGS = $(TARGET_CXXFLAGS)

ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_85180),y)
PROTOBUF_CXXFLAGS += -O0
endif

ifeq ($(BR2_or1k),y)
PROTOBUF_CXXFLAGS += -mcmodel=large
endif

PROTOBUF_CONF_ENV = CXXFLAGS="$(PROTOBUF_CXXFLAGS)"

is not taken into account after the cmake migration... but is in fact
no longer needed, and therefore should be dropped (perhaps as a
preparation commit). It is no longer needed because:

    The BR2_or1k workaround is removed, as protobuf depends on
    libabseil-cpp, which isn't available on OpenRISC.
    
    The BR2_TOOLCHAIN_HAS_GCC_BUG_85180 workaround is removed, as this
    workaround is for Microblaze, and protobuf depends on libabseil-cpp,
    which isn't avialable on Microblaze.
    
Finally, this protobuf bump breaks the build of kismet (at least).
Could you check this, and generally check more reverse dependencies of
protobuf?

Thanks a lot!

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

      parent reply	other threads:[~2024-11-06 21:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30 19:00 [Buildroot] [PATCH v4 1/6] package/{python-}protobuf: bump to version 28.1 James Hilliard
2024-10-30 19:00 ` [Buildroot] [PATCH v4 2/6] package/grpc: bump to version 1.66.1 James Hilliard
2024-11-06 21:30   ` Thomas Petazzoni via buildroot
2024-10-30 19:00 ` [Buildroot] [PATCH v4 3/6] package/pkgconf: bump to version 2.3.0 James Hilliard
2024-11-06 21:21   ` Thomas Petazzoni via buildroot
2024-10-30 19:00 ` [Buildroot] [PATCH v4 4/6] package/protobuf-c: fix protobuf >= 26.0 compatibility James Hilliard
2024-11-06 21:22   ` Thomas Petazzoni via buildroot
2024-10-30 19:00 ` [Buildroot] [PATCH v4 5/6] package/mosh: fix compatibility with newer protobuf versions James Hilliard
2024-11-06 21:21   ` Thomas Petazzoni via buildroot
2024-10-30 19:00 ` [Buildroot] [PATCH v4 6/6] package/collectd: fix protoc version check James Hilliard
2024-11-06 21:21   ` Thomas Petazzoni via buildroot
2024-11-06 21:26 ` 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=20241106222611.338f4a97@windsurf \
    --to=buildroot@buildroot.org \
    --cc=asafka7@gmail.com \
    --cc=christian@aperture.us \
    --cc=fontaine.fabrice@gmail.com \
    --cc=james.hilliard1@gmail.com \
    --cc=ju.o@free.fr \
    --cc=kamel.bouhara@gmail.com \
    --cc=m.niestroj@grinn-global.com \
    --cc=marcus.folkesson@gmail.com \
    --cc=robertroyrose@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wdouglass@carnegierobotics.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.