Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rust: refactor build system #20686

Merged
merged 8 commits into from
Mar 23, 2023
Merged

rust: refactor build system #20686

merged 8 commits into from
Mar 23, 2023

Conversation

1715173329
Copy link
Member

@1715173329 1715173329 commented Mar 19, 2023

Maintainer: @lu-zero
Compile tested: ipq807x/generic
Run tested: redmi-ax6

Description:
refactor the rust build system (added in #19863 )

These tarball cannot be reused, so simply drop them.

Also move cargo config to a file instead of using echo command.

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
They are for the target build which is not supported yet, drop them.

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Copy link
Contributor

@lu-zero lu-zero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thank you!

@PolynomialDivision
Copy link
Member

PolynomialDivision commented Mar 19, 2023

Awesome! Thanks. I'm currently giving it a testbuild on my machine.

Besides those changes, what's the status of the plan to reuse the llvm openwrt toolchain? AFAIK, it is already shipped with the SDK. So build time would reduce even more.

@lu-zero
Copy link
Contributor

lu-zero commented Mar 19, 2023

this version is fetching the pre-built llvm from the rust-lang ci.

@1715173329
Copy link
Member Author

Besides those changes, what's the status of the plan to reuse the llvm openwrt toolchain? AFAIK, it is already shipped with the SDK. So build time would reduce even more.

There're some issues with llvm-bpf:

  • It's not defaultly enabled in buildroot
  • We need to enable more targets in LLVM_TARGETS_TO_BUILD (looks like it should go to toolchain)
  • Need to disable LLVM_ENABLE_ZSTD or rust will fail to lookup library.

@BKPepe BKPepe requested a review from dangowrt March 19, 2023 12:03
@trippleflux
Copy link

@1715173329

Please add options/possibilities to self-built llvm, instead of pre-built one.

Still compiling for x86_64, will edit this message about the result.

@1715173329
Copy link
Member Author

The default configuration of llvm-bpf does not work for rust, I don't wanna add a broken option.
Given that you have to modify llvm-bpf manually, then just do it for rust again.

@trippleflux
Copy link

Based on yoctoproject rust Makefile, must-root is only valid for musl libc, while on glibc it's doesn't need it :

 config.set(host_section, "cxx", e(d.expand("${RUST_TARGET_CXX}")))
    config.set(host_section, "cc", e(d.expand("${RUST_TARGET_CC}")))
    config.set(host_section, "linker", e(d.expand("${RUST_TARGET_CCLD}")))
    if "musl" in host_section:
        config.set(host_section, "musl-root", e(d.expand("${STAGING_DIR_HOST}${exec_prefix}")))

    # If we don't do this rust-native will compile it's own llvm for BUILD.
    # [target.${BUILD_ARCH}-unknown-linux-gnu]
    build_section = "target.{}".format(d.getVar('RUST_BUILD_SYS'))

So I proposing the following for OpenWrt Makefile :

$(if $(CONFIG_USE_MUSL),--set=target.$(RUSTC_TARGET_ARCH).musl-root=$(TOOLCHAIN_DIR) \)

Also regarding CONFIG_PKG_CC_STACKPROTECTOR_REGULAR & CONFIG_PKG_CC_STACKPROTECTOR_STRONG in glibc, the "-lssp_nonshared" seems cannot be found.

What do you think of the following for rust-values.mk :

ifeq ($(CONFIG_USE_MUSL),y)
  # Force linking of the SSP library
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_REGULAR
    ifeq ($(strip $(PKG_SSP)),1)
      RUSTC_LDFLAGS += -lssp_nonshared
    endif
  endif
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_STRONG
    ifeq ($(strip $(PKG_SSP)),1)
      TARGET_CFLAGS += -lssp_nonshared
    endif
  endif
endif

ifeq ($(CONFIG_USE_GLIBC),y)
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_REGULAR
    ifeq ($(strip $(PKG_SSP)),1)
      TARGET_CFLAGS += --enable-stack-protector=yes
    endif
  endif
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_STRONG
    ifeq ($(strip $(PKG_SSP)),1)
      TARGET_CFLAGS += --enable-stack-protector=strong
    endif
  endif
endif

@lu-zero
Copy link
Contributor

lu-zero commented Mar 19, 2023

--enable-stack-protector=strong doesn't seem something you'd pass to gcc, TARGET_CFLAGS is being used to make sure that the stand-alone ssp gets linked in. glibc should have it as part of itself.

@trippleflux
Copy link

Other finding, If I am enabled ccache, the HOSTCC will return as ccache then the Build/Compile/Cargo will failed, changing back CC=cc inside Build/Compile/Cargo will return successful rust app compilation.

@1715173329
Copy link
Member Author

Thanks for the test, it should be $(HOSTCC_NOCACHE).

@1715173329
Copy link
Member Author

So I proposing the following for OpenWrt Makefile :

$(if $(CONFIG_USE_MUSL),--set=target.$(RUSTC_TARGET_ARCH).musl-root=$(TOOLCHAIN_DIR) \)

Looks good to me.

ifeq ($(CONFIG_USE_GLIBC),y)
ifdef CONFIG_PKG_CC_STACKPROTECTOR_REGULAR
ifeq ($(strip $(PKG_SSP)),1)
TARGET_CFLAGS += --enable-stack-protector=yes
endif
endif
ifdef CONFIG_PKG_CC_STACKPROTECTOR_STRONG
ifeq ($(strip $(PKG_SSP)),1)
TARGET_CFLAGS += --enable-stack-protector=strong
endif
endif
endif

https://github.com/openwrt/openwrt/blob/c98e09f01bc6788644d22ffd02cd7aaaef63f5ea/toolchain/glibc/common.mk#L64-L65

Looks like it's enabled already?

@oskarirauta
Copy link
Contributor

Seems like an improvement, I haven't tested yet; but looking at Makefile, it would seem that this fixes previous version's won't build if host and target are same arch. (x86_64 and x86_64 for example/most often).

I'll test later, but it looks like none of problems to build on a must host has not been fixed, so glibc hosts without changes only.

@trippleflux
Copy link

trippleflux commented Mar 20, 2023

ifeq ($(CONFIG_USE_MUSL),y)

Force linking of the SSP library

ifdef CONFIG_PKG_CC_STACKPROTECTOR_REGULAR
ifeq ($(strip $(PKG_SSP)),1)
RUSTC_LDFLAGS += -lssp_nonshared
endif
endif
ifdef CONFIG_PKG_CC_STACKPROTECTOR_STRONG
ifeq ($(strip $(PKG_SSP)),1)
TARGET_CFLAGS += -lssp_nonshared
endif
endif
endif

Perhaps the force -lssp_nonshared linkage need to be enclosed as :

ifeq ($(CONFIG_USE_MUSL),y)
  # Force linking of the SSP library
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_REGULAR
    ifeq ($(strip $(PKG_SSP)),1)
      RUSTC_LDFLAGS += -lssp_nonshared
    endif
  endif
  ifdef CONFIG_PKG_CC_STACKPROTECTOR_STRONG
    ifeq ($(strip $(PKG_SSP)),1)
      TARGET_CFLAGS += -lssp_nonshared
    endif
  endif
endif

Then left for glibc with nothing addition?.

Seems like an improvement, I haven't tested yet; but looking at Makefile, it would seem that this fixes previous version's won't build if host and target are same arch. (x86_64 and x86_64 for example/most often).

I'll test later, but it looks like none of problems to build on a must host has not been fixed, so glibc hosts without changes only.

For me when building for x86_64 on x86_64 the solution for current OpenWrt rust Makefile is :

define Host/PackageDist
	( \
		cd $(HOST_BUILD_DIR)/build/dist ; \
		$(TAR) -cJf $(DL_DIR)/$(RUST_INSTALL_TARGET_FILENAME) \
			rust-*-$(RUSTC_TARGET_ARCH).tar.xz ; \
		$(TAR) -cJf $(DL_DIR)/$(RUST_INSTALL_HOST_FILENAME) \
			*.xz ; \
	)
endef

Removing the "--exclude rust-*-$(RUSTC_TARGET_ARCH).tar.xz " & removing Force linking of the SSP library.

@1715173329
Copy link
Member Author

I just removed Host/PackageDist, seems useless at least for now

Added new RustBinPackage, RustBinHostBuild wrapper.
Added new RUST_PKG_FEATURES flag.
Moved CARGO_HOME to STAGING_DIR_HOSTPKG.
Overrode default Build/Compile and Host/Compile to Cargo build.

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
While at it, move maturin out of rust directory.

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Fixed a build error:
> unresolved import `time::macros`

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
llvm-bpf is not ready for generic usage, so use prebuilt llvm toolchain
provided by the rust project to speedup build (~1hour faster).

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Don't set musl-specific options/ldflags when using glibc.

Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
@oskarirauta
Copy link
Contributor

oskarirauta commented Mar 20, 2023

For me when building for x86_64 on x86_64 the solution for current OpenWrt rust Makefile is :

define Host/PackageDist
	( \
		cd $(HOST_BUILD_DIR)/build/dist ; \
		$(TAR) -cJf $(DL_DIR)/$(RUST_INSTALL_TARGET_FILENAME) \
			rust-*-$(RUSTC_TARGET_ARCH).tar.xz ; \
		$(TAR) -cJf $(DL_DIR)/$(RUST_INSTALL_HOST_FILENAME) \
			*.xz ; \
	)
endef

That didn't work for me.. I locally changed it to

        cd $(HOST_BUILD_DIR)/build/dist && \
          $(TAR) -cJf $(DL_DIR)/$(RUST_INSTALL_TARGET_FILENAME) \
          *.xz

That worked. I was looking that this refactored version fixes that issue.
Working version of rust for musl-host build with target_arch = host_arch is available here: https://github.com/oskarirauta/openwrt-rust/tree/main/lang/rust

@1715173329 1715173329 marked this pull request as ready for review March 21, 2023 09:03
@esaaprillia
Copy link
Contributor

I still doubt rust will exist in openwrt

@oskarirauta
Copy link
Contributor

I still doubt rust will exist in openwrt

May I ask why?

@1715173329
Copy link
Member Author

I'd say this guy just threw garbage everywhere, check his github activity

@oskarirauta
Copy link
Contributor

@1715173329 no need, I'll take your word on it.

@PolynomialDivision
Copy link
Member

@1715173329 I think you can merge? ;)

@1715173329
Copy link
Member Author

Sure, I will merge this tonight if there's no objection :-)

@1715173329 1715173329 merged commit bb3082a into openwrt:master Mar 23, 2023
@1715173329 1715173329 deleted the rustc branch March 23, 2023 18:08
@fuqiang03
Copy link

fuqiang03 commented Jul 24, 2023

@1715173329
001
002
gcc12 glibc2.37 master
找不到解决的方法

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants