Re: [Buildroot] [PATCH 1/2] package/rpi-utils: new package

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello,

On Thu, 25 Jul 2024 10:05:54 +0200
Gaël PORTAY <gael.portay@gmail.com> wrote:

> The CMakeLists.txt of the dtmerge utils creates an internal library by
> doing[1]:
> 
> 	add_library (dtovl ${STATIC} dtoverlay.c)
> 
> According to online documentation of cmake[2]:
> 
> 	add_library(<name> [<type>] [EXCLUDE_FROM_ALL] <sources>...)
> 
> 		Add a library target called <name> to be built from the
> 		source files listed in the command invocation.
> 
> 		The optional <type> specifies the type of library to be
> 		created:
> 
> 			STATIC An archive of object files for use when
> 			       linking other targets.
> 
> 			SHARED A dynamic library that may be linked by
> 			       other targets and loaded at runtime.
> 
> 			MODULE A plugin that may not be linked by other
> 			       targets, but may be dynamically loaded at
> 			       runtime using dlopen-like functionality.
> 
> 		If no <type> is given the default is STATIC or SHARED
> 		based on the value of the BUILD_SHARED_LIBS variable.
> 
> In rpi-utils, the optional type is controlled thanks to the environment
> variable ${STATIC}; it is unset by default. It is expected cmake builds
> a STATIC library; but...
> 
> cmake creates a STATIC library if configuring the project for my host
> system (Arch Linux).
> 
> And, cmake creates a SHARED library through buildroot (maybe because of
> BUILD_SHARED_LIBS?).
> 
> The file CMakeLists.txt does not install the shared library, and it
> results in a run-time issue saying the library libdtovl.so is not found.
> 
> So, I have decided to ensure the library is statically build by setting
> the environment variable STATIC to STATIC.
> 
> Do you prefer I install the shared library from an install hook or
> whatsover?

Meh, this is really crappy stuff from rpi-utils's CMakeLists.txt. I'd
say keep the -DSTATIC=STATIC as you had, but with a comment above that
explains what's going on.

> Well, I wanted to give a try before sending the package, but the
> toolchain all skipped.

Well, your patch was not including package/rpi-utils/Config.in, so the
option BR2_PACKAGE_RPI_UTILS does not exist. Perhaps why it gets
skipped?

Best regards,

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