systemd-boot: new simple EFI bootloader replacing gummmiboot (branch yem/systemd-boot)

From: James Hilliard <[email protected]>

As explained in [0], meson will try on its own to decide whether it can run what it builds. If it happens that the host and target CPUs are "compatible", that test may fail and meson may believe it can run what it builds.

Override that test by using needs_exe_wrapper=true, and not defining an actual exe_wrapper.

[0] https://mesonbuild.com/Cross-compilation.html

Signed-off-by James Hilliard <[email protected]>

[yann.morin.1998 at free.fr:
- split in its own patch
- improve commit log
]

Signed-off-by Yann E. MORIN <[email protected]>

---
 package/meson/cross-compilation.conf.in | 1 +
 1 file changed, 1 insertion(+)

From: James Hilliard <[email protected]>

As explained in [0], meson recognises a certain set of CPU famillies, whose names slightly differ from those we know them as.

If we don't pass the proper cpu_familly, meson whines:
WARNING: Unknown CPU family 'i686', please report this at [...]

Subsequently, packages that use that to decide on what they should build and how they should build it, fail to build. That is the case for the upcoming systemd-boot, for example.

Fix that by using the list propvided by the meson documentation [0].

[0] https://mesonbuild.com/Reference-tables.html#cpu-families

Signed-off-by James Hilliard <[email protected]>

[yann.morin.1998 at free.fr:
- split in its own patch
- imnprove commit log
]

Signed-off-by "Yann E. MORIN" <[email protected]>

---
 package/meson/meson.mk | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

Some packages may want to build only specific targets, instead of the default.

So, allow them to provide FOO_NINJA_OPTS (not really options, but we just mimicked the naming we already have for autotools packages).

Update the manual accordingly.

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Eric Le Bihan <[email protected]>

Cc James Hilliard <[email protected]>

---
 docs/manual/adding-packages-meson.txt | 3 +++
 package/pkg-meson.mk                  | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

docs/manual/adding-packages-meson.txt +3 -0

index c52fe10506..549319b192 100644
@@ -94,3 +94,6 @@ will therefore only use a few of them.
 * +FOO_NINJA_ENV+, to specify additional environment variables to pass to
   +ninja+, meson companion tool in charge of the build operations. By default,
   empty.
+
+* +FOO_NINJA_OPTS+, to specify a space-separated list of targets to build. By
+  default, empty, to build the default target(s).

package/pkg-meson.mk +0 -0

index 507e686068..0588660dbf 100644
@@ -103,12 +103,12 @@ ifndef $(2)_BUILD_CMDS
 ifeq ($(4),target)

package/pkg-meson.mk +0 -1

 endef
 endif
 endif
--

2.14.1

Quoted 2 lines

Some packages may want to build only specific targets, instead of the default.

Quoted 9 lines

package/pkg-meson.mk +0 -1

index 507e686068..0588660dbf 100644
@@ -103,12 +103,12 @@ ifndef $(2)_BUILD_CMDS
 ifeq ($(4),target)
 define $(2)_BUILD_CMDS
        $$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build

package/pkg-meson.mk ifndef $(2)_BUILD_CMDS · line 111

Quoted 7 lines

package/pkg-meson.mk +2 -1

+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
 endef
 else
 define $(2)_BUILD_CMDS
        $$(HOST_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build

shouldn't $$($$(PKG)_NINJA_OPTS) come after $$($$(PKG)_SRCDIR)/build?

James, ?ric, All,

On 2018-12-26 05:36 -0600, James Hilliard spake thusly:

Quoted 3 lines · Yann E. MORIN

Quoted 2 lines

Some packages may want to build only specific targets, instead of the default.

[--SNIP--]

Quoted 9 lines

Quoted 9 lines

package/pkg-meson.mk +0 -1

index 507e686068..0588660dbf 100644
@@ -103,12 +103,12 @@ ifndef $(2)_BUILD_CMDS
 ifeq ($(4),target)
 define $(2)_BUILD_CMDS
        $$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build

Quoted 8 lines

package/pkg-meson.mk ifndef $(2)_BUILD_CMDS · line 111

Quoted 7 lines

package/pkg-meson.mk +2 -1

+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
 endef
 else
 define $(2)_BUILD_CMDS
        $$(HOST_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build

shouldn't $$($$(PKG)_NINJA_OPTS) come after $$($$(PKG)_SRCDIR)/build?

I don't know. It worked that way for me, and I wanted to group together the two _OPTS variables, and also like we do for the autotools infra. But your suggestion also makes sense, and is indeed more in-line with the ninja's short-help:

    $ ./output/host/bin/ninja -h
    usage: ninja [options] [targets...]
    [...]

?ric, your opinion?

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 26 lines

James, ?ric, All,

On 2018-12-26 05:36 -0600, James Hilliard spake thusly:

Quoted 3 lines · Yann E. MORIN

Quoted 2 lines

Some packages may want to build only specific targets, instead of the default.

[--SNIP--]

Quoted 17 lines

Quoted 6 lines

package/pkg-meson.mk +0 -0

index 507e686068..0588660dbf 100644
@@ -103,12 +103,12 @@ ifndef $(2)_BUILD_CMDS
 ifeq ($(4),target)

package/pkg-meson.mk ifndef $(2)_BUILD_CMDS · line 111

Quoted 10 lines

package/pkg-meson.mk +2 -2

 define $(2)_BUILD_CMDS
        $$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
 endef
 else
 define $(2)_BUILD_CMDS
        $$(HOST_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
-               $$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
+               $$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build

shouldn't $$($$(PKG)_NINJA_OPTS) come after $$($$(PKG)_SRCDIR)/build?

Quoted 4 lines

I don't know. It worked that way for me, and I wanted to group together the two _OPTS variables, and also like we do for the autotools infra. But your suggestion also makes sense, and is indeed more in-line with the ninja's short-help:

Maybe add a $$($$(PKG)_NINJA_TARGETS) option as well?

Quoted 16 lines

    $ ./output/host/bin/ninja -h
    usage: ninja [options] [targets...]
    [...]

?ric, your opinion?

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Some packages may want to build only specific targets, instead of the default.

So, allow them to provide FOO_NINJA_OPTS (not really options, but we just mimicked the naming we already have for autotools packages).

Update the manual accordingly.

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Eric Le Bihan <[email protected]>

Cc James Hilliard <[email protected]>

---
 docs/manual/adding-packages-meson.txt | 3 +++
 package/pkg-meson.mk                  | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Hello,

Thanks for working on this!

Quoted 14 lines · Yann E. MORIN

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

So it would be good to make sure we have a really solid use-case for adding this complexity.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Well systemd-boot is a perfectly good bootloader even without systemd. It uses plain text config files so it's not hard to manage even without the systemd userspace tools.

Hello,

On Wed, 26 Dec 2018 15:37:42 -0600, James Hilliard wrote:

Quoted 3 lines

Well systemd-boot is a perfectly good bootloader even without systemd. It uses plain text config files so it's not hard to manage even without the systemd userspace tools.

OK, but there must be some compelling reason to use systemd-boot instead of another x86-capable bootloader, such as grub or syslinux. I believe even U-Boot works on x86 EFI systems. All of these also use plain text configuration files that don't require userspace tools.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Quoted 14 lines

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

So it would be good to make sure we have a really solid use-case for adding this complexity.

Thomas, All,

Adding Peter in the loop; see at the end.

On 2018-12-26 22:23 +0100, Thomas Petazzoni spake thusly:

Quoted 23 lines · Yann E. MORIN

Quoted 14 lines

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Quoted 8 lines

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

And I now even dropped all of them completely, with the v240 bump, so we no longer whare any patch with systemd. There is only one patch that is now needed to build systemd-boot standalone. We still need to investigate why James was not able to build it, though. James, care to give my series a new spin, please? (I've repushed the branch just now)

So, the only complexity that remains is the sharing of the boot files and their install commands.

That, and the little trick to share the source file.

Quoted 2 lines

So it would be good to make sure we have a really solid use-case for adding this complexity.

Peter, care to elaborate your position, since you were advocating also for it, earlier? ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 38 lines · Yann E. MORIN

Thomas, All,

Adding Peter in the loop; see at the end.

On 2018-12-26 22:23 +0100, Thomas Petazzoni spake thusly:

Quoted 31 lines · Yann E. MORIN

Quoted 14 lines

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

Quoted 5 lines

And I now even dropped all of them completely, with the v240 bump, so we no longer whare any patch with systemd. There is only one patch that is now needed to build systemd-boot standalone. We still need to investigate why James was not able to build it, though. James, care to give my series a new spin, please? (I've repushed the branch just now)

Did a fresh compilation run, I get a failure here
https://github.com/systemd/systemd/blob/v239/meson.build#L278

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 22 lines

So, the only complexity that remains is the sharing of the boot files and their install commands.

That, and the little trick to share the source file.

Quoted 2 lines

So it would be good to make sure we have a really solid use-case for adding this complexity.

Peter, care to elaborate your position, since you were advocating also for it, earlier? ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 45 lines · James Hilliard

Quoted 43 lines · Yann E. MORIN

Thomas, All,

Adding Peter in the loop; see at the end.

On 2018-12-26 22:23 +0100, Thomas Petazzoni spake thusly:

Quoted 23 lines · Yann E. MORIN

Quoted 14 lines

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Quoted 8 lines

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

And I now even dropped all of them completely, with the v240 bump, so we no longer whare any patch with systemd. There is only one patch that is now needed to build systemd-boot standalone. We still need to investigate why James was not able to build it, though. James, care to give my series a new spin, please? (I've repushed the branch just now)

Quoted 2 lines

Did a fresh compilation run, I get a failure here
https://github.com/systemd/systemd/blob/v239/meson.build#L278

Correction: failure is here
https://github.com/systemd/systemd/blob/v240/meson.build#L293

Quoted 24 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 22 lines

So, the only complexity that remains is the sharing of the boot files and their install commands.

That, and the little trick to share the source file.

Quoted 2 lines

So it would be good to make sure we have a really solid use-case for adding this complexity.

Peter, care to elaborate your position, since you were advocating also for it, earlier? ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 48 lines · James Hilliard

Quoted 45 lines · James Hilliard

Quoted 43 lines · Yann E. MORIN

Thomas, All,

Adding Peter in the loop; see at the end.

On 2018-12-26 22:23 +0100, Thomas Petazzoni spake thusly:

Quoted 23 lines · Yann E. MORIN

Quoted 14 lines

From: James Hilliard <[email protected]>

systemd-boot is the integration of gummiboot into systemd, and gummiboot is no longer maintained [0]. However, it is still interesting to use it as a simple, stand-alone bootloader.

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 7 lines

To avoid duplication, we just symlink the systemd patches as-is. We just need to add a specific patch, that just relaxes the dependency checks, since we're only interested in building the boot blobs.

[0] https://cgit.freedesktop.org/gummiboot/commit/?id=55df1539c9d330732e88bd196afee386db6e4a1d

Signed-off-by James Hilliard <[email protected]>

Quoted 8 lines

Do we have a serious valid use-case for wanting to use systemd-boot without systemd? This adds a fair bit of complexity, so I'd like to be sure of what we're doing here.

An example of the complexity is with the symlinks to the patches. Every time a patch is added/removed in package/systemd/, one should remember to adjust the symlinks in boot/systemd-boot/. This is something that can very easily be missed.

And I now even dropped all of them completely, with the v240 bump, so we no longer whare any patch with systemd. There is only one patch that is now needed to build systemd-boot standalone. We still need to investigate why James was not able to build it, though. James, care to give my series a new spin, please? (I've repushed the branch just now)

Quoted 4 lines

Quoted 2 lines

Did a fresh compilation run, I get a failure here
https://github.com/systemd/systemd/blob/v239/meson.build#L278

Correction: failure is here
https://github.com/systemd/systemd/blob/v240/meson.build#L293

Upstream bug report https://github.com/systemd/systemd/issues/11278

Quoted 24 lines

Quoted 24 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 22 lines

So, the only complexity that remains is the sharing of the boot files and their install commands.

That, and the little trick to share the source file.

Quoted 2 lines

So it would be good to make sure we have a really solid use-case for adding this complexity.

Peter, care to elaborate your position, since you were advocating also for it, earlier? ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 3 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

James, All,

On 2018-12-26 19:27 -0600, James Hilliard spake thusly:

Quoted 5 lines

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 3 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

That unfortunately does not work:

ERROR: No specified compiler can handle file src/libsystemd/sd-bus/test-bus-vtable-cc.cc

But if you also add:

    diff --git a/src/test/meson.build b/src/test/meson.build
    index ea049a6fb..d9d87e02c 100644
    --- a/src/test/meson.build
    +++ b/src/test/meson.build
    @@ -957,7 +957,7 @@ tests += [

     ]

    -if cxx.found()
    +if cxx_cmd != ''
             tests += [
                     [['src/libsystemd/sd-bus/test-bus-vtable-cc.cc'],
                      [],

Then it works.

Obviously, I'm not sure this is the right fix...

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 4 lines

On 2018-12-26 19:27 -0600, James Hilliard spake thusly:

Quoted 3 lines

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 8 lines

Quoted 2 lines

Quoted 1 line

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

That unfortunately does not work:
ERROR: No specified compiler can handle file src/libsystemd/sd-bus/test-bus-vtable-cc.cc But if you also add:

    -if cxx.found()
    +if cxx_cmd != ''

Then it works.

Pushed that fix and one other I found, didn't realize cxx.found() was being used other places(I only tested that pull request against a c only cross toolchain).

James, All,

On 2018-12-27 03:07 -0600, James Hilliard spake thusly:

Quoted 13 lines · Yann E. MORIN

Quoted 12 lines

On 2018-12-26 19:27 -0600, James Hilliard spake thusly:

Quoted 5 lines

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 3 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

That unfortunately does not work:
ERROR: No specified compiler can handle file src/libsystemd/sd-bus/test-bus-vtable-cc.cc But if you also add:

    -if cxx.found()
    +if cxx_cmd != ''

Then it works.

Quoted 3 lines

Pushed that fix and one other I found, didn't realize cxx.found() was being used other places(I only tested that pull request against a c only cross toolchain).

It worked for me without the hunk in src/systemd/meson.build. However, for our case in Buildroot (just building systemd-boot standalone), we don't need a 100% perfect patch, as long as it allows building.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 18 lines

On 2018-12-27 03:07 -0600, James Hilliard spake thusly:

Quoted 16 lines · Yann E. MORIN

Quoted 4 lines

On 2018-12-26 19:27 -0600, James Hilliard spake thusly:

Quoted 3 lines

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 8 lines

Quoted 2 lines

Quoted 1 line

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

That unfortunately does not work:
ERROR: No specified compiler can handle file src/libsystemd/sd-bus/test-bus-vtable-cc.cc But if you also add:

    -if cxx.found()
    +if cxx_cmd != ''

Then it works.

Pushed that fix and one other I found, didn't realize cxx.found() was being used other places(I only tested that pull request against a c only cross toolchain).

Quoted 3 lines

It worked for me without the hunk in src/systemd/meson.build. However, for our case in Buildroot (just building systemd-boot standalone), we don't need a 100% perfect patch, as long as it allows building.

That patch I think is needed to build systemd itself when using a cross toolchain without c++, not just systemd-boot.

James, All,

On 2018-12-27 03:13 -0600, James Hilliard spake thusly:

Quoted 22 lines · Yann E. MORIN

Quoted 21 lines

On 2018-12-27 03:07 -0600, James Hilliard spake thusly:

Quoted 13 lines · Yann E. MORIN

Quoted 4 lines

On 2018-12-26 19:27 -0600, James Hilliard spake thusly:

Quoted 3 lines

On Wed, Dec 26, 2018 at 4:52 PM James Hilliard

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

meson.build:293:8: ERROR: Unknown compiler(s):
[['/home/buildroot/buildroot/output/host/bin/i586-buildroot-linux-uclibc-g++']]

Quoted 8 lines

Quoted 2 lines

Quoted 1 line

Upstream bug report https://github.com/systemd/systemd/issues/11278

Potential fix: https://github.com/systemd/systemd/pull/11279

That unfortunately does not work:
ERROR: No specified compiler can handle file src/libsystemd/sd-bus/test-bus-vtable-cc.cc But if you also add:

    -if cxx.found()
    +if cxx_cmd != ''

Then it works.

Quoted 3 lines

Pushed that fix and one other I found, didn't realize cxx.found() was being used other places(I only tested that pull request against a c only cross toolchain).

It worked for me without the hunk in src/systemd/meson.build. However, for our case in Buildroot (just building systemd-boot standalone), we don't need a 100% perfect patch, as long as it allows building.

Quoted 2 lines

That patch I think is needed to build systemd itself when using a cross toolchain without c++, not just systemd-boot.

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:

BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

That's without c++ right?

James, All,

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 6 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

That's without c++ right?

Yes, that's without C++.

You can check a defconfig by doing:

    $ cat >.config <<_EOF_
    BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
    BR2_INIT_SYSTEMD=y
    _EOF_

    $ make olddefconfig

    $ grep CXX .config
    # BR2_TOOLCHAIN_BUILDROOT_CXX is not set

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 7 lines

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 6 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

That's without c++ right?

James, All,

On 2018-12-27 05:01 -0600, James Hilliard spake thusly:

Quoted 7 lines · Yann E. MORIN

Quoted 6 lines

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 5 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

Quoted 1 line

Quoted 1 line

Quoted 1 line

That's without c++ right?

Your no-C++ patch has been accepted upstream! :-)

Care to backport that fix in Buildroot, please?

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 8 lines

On 2018-12-27 05:01 -0600, James Hilliard spake thusly:

Quoted 7 lines · Yann E. MORIN

Quoted 6 lines

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 5 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

That's without c++ right?

Your no-C++ patch has been accepted upstream! :-)

Care to backport that fix in Buildroot, please?

Backported in my tree here
https://github.com/jameshilliard/buildroot/tree/systemd-boot

I did a test build selecting only systemd-boot and now I get this error:
Program gperf found: NO
meson.build:634:0: ERROR: Program(s) ['gperf'] not found or not executable

James, All,

On 2018-12-29 04:50 -0600, James Hilliard spake thusly:

Quoted 13 lines · Yann E. MORIN

Quoted 12 lines

On 2018-12-27 05:01 -0600, James Hilliard spake thusly:

Quoted 8 lines · Yann E. MORIN

Quoted 7 lines

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 6 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

That's without c++ right?

Your no-C++ patch has been accepted upstream! :-)

Quoted 3 lines

Quoted 1 line

Care to backport that fix in Buildroot, please?

Backported in my tree here
https://github.com/jameshilliard/buildroot/tree/systemd-boot

Could you please send it soon to the list as a patch to systemd, as it is not correlated to systemd-boot at all (it is also needed by systemd to build on a non-C++ toolchain)?

Quoted 4 lines

I did a test build selecting only systemd-boot and now I get this error:
Program gperf found: NO
meson.build:634:0: ERROR: Program(s) ['gperf'] not found or not executable

Until now, only minor patching was needed (a header and two libs checks) that were trivial to patchout. But this new gperf check is less trivial to patch-out in a way that is maintainable long-term.

My opinion now is now joining that of Thomas, that we should not try to build a standalone systemd-boot until it is properly supported by upstream. Work to that effect should be directed at upstream rather than monkey-patching in Buildroot.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

James, All,

On 2018-12-29 04:50 -0600, James Hilliard spake thusly:

Quoted 9 lines · Yann E. MORIN

Quoted 8 lines

On 2018-12-27 05:01 -0600, James Hilliard spake thusly:

Quoted 7 lines · Yann E. MORIN

Quoted 6 lines

On 2018-12-27 04:42 -0600, James Hilliard spake thusly:

Quoted 5 lines · Yann E. MORIN

Quoted 4 lines

I can confirm that, without the hunk in src/systemd/meson.build, I was able to build systemd with this defconfig:
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_INIT_SYSTEMD=y

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

That's without c++ right?

Your no-C++ patch has been accepted upstream! :-)

Care to backport that fix in Buildroot, please?

Backported in my tree here
https://github.com/jameshilliard/buildroot/tree/systemd-boot

Could you please send it soon to the list as a patch to systemd, as it is not correlated to systemd-boot at all (it is also needed by systemd to build on a non-C++ toolchain)?

Quoted 3 lines

I did a test build selecting only systemd-boot and now I get this error:
Program gperf found: NO
meson.build:634:0: ERROR: Program(s) ['gperf'] not found or not executable

Until now, only minor patching was needed (a header and two libs checks) that were trivial to patchout. But this new gperf check is less trivial to patch-out in a way that is maintainable long-term.

My opinion now is now joining that of Thomas, that we should not try to build a standalone systemd-boot until it is properly supported by upstream. Work to that effect should be directed at upstream rather than monkey-patching in Buildroot.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 3 lines

Until now, only minor patching was needed (a header and two libs checks) that were trivial to patchout. But this new gperf check is less trivial to patch-out in a way that is maintainable long-term.

What do you think of this strategy using meson's disabler feature?
https://github.com/systemd/systemd/pull/11294

James, All,

On 2018-12-30 02:44 -0600, James Hilliard spake thusly:

Quoted 1 line · Yann E. MORIN

[--SNIP--]

Quoted 5 lines

Quoted 3 lines

Until now, only minor patching was needed (a header and two libs checks) that were trivial to patchout. But this new gperf check is less trivial to patch-out in a way that is maintainable long-term.

What do you think of this strategy using meson's disabler feature?
https://github.com/systemd/systemd/pull/11294

To be honest, I don't really care how it's done, sorry... It just has to be a solution that pleases upstream.

I just got into the original thread to help sort out a solution in Buildroot, should that were possible, but it turns out that it is not really workable easily without upstream support.

Good luck in your endeavour! ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 12 lines

On 2018-12-30 02:44 -0600, James Hilliard spake thusly:

Quoted 1 line · Yann E. MORIN

[--SNIP--]

Quoted 5 lines

Quoted 3 lines

Until now, only minor patching was needed (a header and two libs checks) that were trivial to patchout. But this new gperf check is less trivial to patch-out in a way that is maintainable long-term.

What do you think of this strategy using meson's disabler feature?
https://github.com/systemd/systemd/pull/11294

To be honest, I don't really care how it's done, sorry... It just has to be a solution that pleases upstream.

Quoted 3 lines

I just got into the original thread to help sort out a solution in Buildroot, should that were possible, but it turns out that it is not really workable easily without upstream support.

It's not super difficult to create a patch for our usage in buildroot in order to allow building systemd-boot by itself at least, the diff will just be a bit on the large side for the moment until upstream is refactored since I need to strip out most of the configure checks, does that sound ok?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Quoted 2 lines

So it would be good to make sure we have a really solid use-case for adding this complexity.

Peter, care to elaborate your position, since you were advocating also for it, earlier? ;-)

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

Quoted 5 lines

What is wrong is that it makes the systemd package *and* the init selectionmuch more copmplex, and this is not acceptable (IMHO).

I'd rather have a second package that is trivial, with mimimum, if at all, changes in the main systemd package.

Quoted 7 lines

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

I really don't like this approach of copying systemd.

I would instead try harder to keep the standalone version part of the systemd
package itself. Yes, I realize that I'm coming very late with this... The only reason we got here is this statement from Yann:

Quoted 5 lines

Quoted 5 lines

What is wrong is that it makes the systemd package *and* the init selectionmuch more copmplex, and this is not acceptable (IMHO).

I'd rather have a second package that is trivial, with mimimum, if at all, changes in the main systemd package.

The second package turns out not to be trivial at all...

Finally note that I fully agree that we should not even start support for
standalone systemd-boot until upstream progresses into making it buildable standalone. I really don't want that huge patch either. But that's independent of how standalone systemd-boot is implemented.

Quoted 7 lines · Yann E. MORIN

Since systemd-boot is really part of systemd, when systemd is enabled (as an init system), we rely on it to build the boot blobs, and systemd-boot (this package) is not available.

Now, when systemd is not enabled, systemd-boot (this package) will actually build the boot blobs, and only that. No userspace tool is built.

I really don't like this approach of copying systemd.

I would instead try harder to keep the standalone version part of the systemd
package itself. Yes, I realize that I'm coming very late with this... The only reason we got here is this statement from Yann:

Quoted 5 lines

Quoted 5 lines

What is wrong is that it makes the systemd package *and* the init selectionmuch more copmplex, and this is not acceptable (IMHO).

I'd rather have a second package that is trivial, with mimimum, if at all, changes in the main systemd package.

The second package turns out not to be trivial at all...

So, looking back to James's original v2 patch, I'd structure the Config.in
something like this:

config BR2_PACKAGE_SYSTEMD
bool
depends on BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS depends on ...
# select any dependency that is relevant for system-boot

config BR2_PACKAGE_SYSTEMD_BOOT
bool

menuconfig BR2_PACKAGE_SYSTEMD_SYSTEMD
depends on BR2_PACKAGE_SYSTEMD
# addition depends/selects that are relevant for full systemd

# rest of the file stays the same

Note that BR2_PACKAGE_SYSTEMD was never user-selectable because it was always
implicit from BR2_INIT_SYSTEMD, so it's OK to turn it into a blind option.

Note that we will need to declare the symbol BR2_PACKAGE_SYSTEMD_BOOT option
twice: in the standalone systemd-boot case, we need the symbol declared somewhere so it can be selected by BR2_TARGET_SYSTEMD_BOOT.

Finally note that I fully agree that we should not even start support for
standalone systemd-boot until upstream progresses into making it buildable standalone. I really don't want that huge patch either. But that's independent of how standalone systemd-boot is implemented.

Regards,
Arnout