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

cross compiling #4031

Open
firmwarecostum opened this issue Dec 18, 2023 · 9 comments
Open

cross compiling #4031

firmwarecostum opened this issue Dec 18, 2023 · 9 comments

Comments

@firmwarecostum
Copy link

firmwarecostum commented Dec 18, 2023

Expected Behavior

is there a way to build cross compilation i built it in openwrt

./vhp_gen_hufdec > vhp_hufdec.h_
/bin/bash: line 1: ./vhp_gen_hufdec: cannot execute binary file: Exec format error
make[6]: *** [Makefile:3852: vhp_hufdec.h] Error 126
make[6]: Leaving directory '/home/open/wrt/build_dir/target-aarch64_generic_musl/varnish-7.4.2/bin/varnishd'

Current Behavior

no

Possible Solution

no

Steps to Reproduce (for bugs)

no

Context

no

Varnish Cache version

varnish-7.4.2

Operating system

openwrt

Source of binary packages used (if any)

https://varnish-cache.org/downloads/varnish-7.4.2.tgz

@firmwarecostum firmwarecostum changed the title croos compiling cross compiling Dec 18, 2023
@nigoroll
Copy link
Member

The simple answer: This is not currently supported. The place you found is not the only one where we expect built binaries to be executable during the build, for example to generate documentation.
I think it would be possible to generate one or two binaries for these cases, depending on what is needed (build time, execution time or both), but someone would need to do the work to extend the build system. I personally do not have a compelling reason to.

@gquintard
Copy link
Member

Which architectures are you building on and for?

@firmwarecostum
Copy link
Author

The simple answer: This is not currently supported. The place you found is not the only one where we expect built binaries to be executable during the build, for example to generate documentation. I think it would be possible to generate one or two binaries for these cases, depending on what is needed (build time, execution time or both), but someone would need to do the work to extend the build system. I personally do not have a compelling reason to.

Thank you for your reply. for comparison if i see heimdal has the path --with-cross-tools=dir use cross tools in dir this is the cross tools path in the directory before that i have to build the host

@firmwarecostum
Copy link
Author

Which architectures are you building on and for?

arch64 just for fun

@gquintard
Copy link
Member

I meant "what architecture is the binary being built on, and which architecture will it run on" :-)
Is building inside a docker container an option?

@firmwarecostum
Copy link
Author

I meant "what architecture is the binary being built on, and which architecture will it run on" :-) Is building inside a docker container an option?

I hate docker and I don't use docker. I built varnish using openwrt-sdk and cross-compiled it

@firmwarecostum
Copy link
Author

@nigoroll @gquintard

with some tricks I can build it in openwrt. i wish varnish could be cross compiled easily

BusyBox v1.36.1 (2023-11-27 07:02:33 UTC) built-in shell (ash)
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 23.05.2, r23630-842932a63d
 -----------------------------------------------------
root@OpenWrt:~# varnishadm -h
Usage: varnishadm [-h] [-n ident] [-p] [-S secretfile] [-T [address]:port] [-t timeout] [command [...]]
        -n is mutually exclusive with -S and -T
root@OpenWrt:~# varnishadm -v
varnishadm: unrecognized option: v
Usage: varnishadm [-h] [-n ident] [-p] [-S secretfile] [-T [address]:port] [-t timeout] [command [...]]
        -n is mutually exclusive with -S and -T
root@OpenWrt:~# varnishd -V
varnishd (varnish-7.4.2 revision cd1d10ab53a6f6115b2b4f3b2a1da94c1f749f80)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2023 Varnish Software
Copyright 2010-2023 UPLEX - Nils Goroll Systemoptimierung
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~#

@gquintard
Copy link
Member

gquintard commented Dec 19, 2023

Very glad to read, it can you share what you did with the class so it can help others in the future please?

@dridi
Copy link
Member

dridi commented Dec 19, 2023

The problems with cross compilation are somewhat tricky to solve. We generate some of our sources with programs compiled at build time. In autoconf linguo we rely on $(host_cpu) artifacts to run on $(build_cpu).

In theory one way to solve this would be to distribute sources we generate at build time, but because of how make dependencies work, we'd need a way to skip a dependency from source to generated source (skipping the $(build_cpu) binaries). But we'd need to litter our makefiles with conditionals like if NOT_CROSS_COMPILING statements to only build the problematic artifacts when build and host architectures match.

And of course while that would only work from a dist archive, all bets are off if you apply patches that should affect generated sources, which is common with downstream packaging.

One way to cross-compile Varnish is to build it "natively" and then grab from there missing generated sources in your cross build.

Another way is to configure you system to run aarch64 binaries transparently with qemu. It's probably the simplest as you'd set it up once and forget about it, but not the easiest. If you're cross-compiling you probably have a sysroot in place anyway to get the aarch64 dependencies, so in that regard you're probably already halfway there.

Anyway, I'm also interested in @firmwarecostum's solution. We could add something to the wiki for the time being.

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

No branches or pull requests

4 participants