From bill14653 at hotmail.com Wed Jun 9 11:06:12 2021 From: bill14653 at hotmail.com (bill noneofyourbusiness) Date: Wed, 9 Jun 2021 11:06:12 +0000 Subject: SSL protocl errors only when Reverse-proxying Unit (Wordpress) app behind Nginx? Message-ID: I'm working on Fronting Wordpress installed as a Unit app with Nginx. I run nginx -v nginx version: nginx/1.21.0 unitd --version unit version: 1.24.0 php -v PHP 8.0.7 (cli) (built: Jun 1 2021 18:43:05) ( NTS gcc x86_64 ) Copyright (c) The PHP Group Zend Engine v4.0.7, Copyright (c) Zend Technologies with Zend OPcache v8.0.7, Copyright (c), by Zend Technologies with Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick Rethans I'm following instructions from Unit:HOWTO:NGINX Integration:Fronting Unit with NGINX https://unit.nginx.org/howto/integration/#fronting-unit-with-nginx Unit:HOWTO:Applications:Wordpress https://unit.nginx.org/howto/wordpress/#wordpress I installed Wordpress on Unit. I can access the site and login directly, with valid SSL/cert, at https://wp.loc:60000 Host is host wp.loc wp.loc has address 127.0.0.1 The Unit config for that is { "certificates": { "bundle": { "key": "ECDH", "chain": [ { "subject": { "common_name": "wp.loc", "alt_names": [ "wp.loc", "www.wp.loc", "localhost" ], "country": "US", "state_or_province": "NY", "locality": "NYC", "organization": "loc", "department": "myCA" }, "issuer": { "common_name": "myINT", "country": "US", "state_or_province": "NY", "organization": "loc", "department": "myCA" }, "validity": { "since": "May 1 18:14:22 2021 GMT", "until": "Aug 2 18:14:22 2021 GMT" } }, { "subject": { "common_name": "myINT", "country": "US", "state_or_province": "NY", "organization": "loc", "department": "myCA" }, "issuer": { "common_name": "myROOT", "country": "US", "state_or_province": "NY", "locality": "NYC", "organization": "loc", "department": "myCA" }, "validity": { "since": "Jan 1 03:37:17 2021 GMT", "until": "Jan 2 03:37:17 2022 GMT" } }, { "subject": { "common_name": "myROOT", "country": "US", "state_or_province": "NY", "locality": "NYC", "organization": "loc", "department": "myCA" }, "issuer": { "common_name": "myROOT", "country": "US", "state_or_province": "NY", "locality": "NYC", "organization": "loc", "department": "myCA" }, "validity": { "since": "Jan 1 03:19:10 2021 GMT", "until": "Jan 2 03:19:10 2025 GMT" } } ] } }, "config": { "listeners": { "127.0.0.1:60000": { "pass": "routes", "tls": { "certificate": "bundle", "conf_commands": { "minprotocol": "TLSv1.3", "ciphersuites": "TLS_CHACHA20_POLY1305_SHA256", } } } }, "routes": [ { "match": { "uri": [ "*.php", "*.php/*", "/wp-admin/" ] }, "action": { "pass": "applications/wordpress/direct" } }, { "action": { "share": "/home/wwwrun/wordpress/", "fallback": { "pass": "applications/wordpress/index" } } } ], "applications": { "wordpress": { "type": "php", "targets": { "direct": { "root": "/home/wwwrun/wordpress/" }, "index": { "root": "/home/wwwrun/wordpress/", "script": "index.php" } } } }, "access_log": "/var/log/wwwrun/unit.access.log" } } The frontend Nginx config includes upstream WPUNITproxy { server wp.loc:60000; } server { listen 10.15.12.11:443 ssl http2; server_name front.loc; ... ssl_prefer_server_ciphers on; ssl_protocols TLSv1.3 TLSv1.2; ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!AES128:!SHA1:!SHA256:!SHA384:!COMPLEMENTOFDEFAULT"; ssl_conf_command Options PrioritizeChaCha; ssl_conf_command CipherString ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384; ssl_verify_client optional; ssl_verify_depth 2; ssl_client_certificate "/home/wwwrun/ssl/chain.crt"; ssl_certificate "/home/wwwrun/ssl/front.loc.server.crt"; ssl_certificate_key "/home/wwwrun/ssl/front.loc.server.key"; location /blog/ { proxy_pass https://WPUNITproxy/; proxy_set_header Host $host; proxy_set_header HTTPS on; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-Protocol https; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-SSL-Subject $ssl_client_s_dn; proxy_set_header X-SSL-Issuer $ssl_client_i_dn; proxy_ssl_name wp.loc; proxy_ssl_verify off; proxy_ssl_verify_depth 2; proxy_ssl_trusted_certificate "/home/wwwrun/ssl/chain.crt"; proxy_ssl_certificate "/home/wwwrun/ssl/wp.loc.client.crt"; proxy_ssl_certificate_key "/home/wwwrun/ssl/wp.loc.client.key"; } Host is host front.loc front.loc has address 10.15.12.11 When I go to the FRONT end proxy, https://front.loc/blog/ I get SSL errors ==> /var/log/wwwrun/unit.log <== 2021/06/09 06:20:00 [alert] 43183#44092 *248 SSL_do_handshake(96) failed (258: unsupported protocol) (OpenSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) ==> /var/log/wwwrun/nginx.error.log <== 2021/06/09 06:20:00 [error] 63200#63200: *4 SSL_do_handshake() failed (SSL: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:SSL alert number 70) while SSL handshaking to upstream, client: 10.15.12.11, server: front.loc, request: "GET /blog/ HTTP/2.0", upstream: "https://127.0.0.1:60000/", host: "front.loc" So I can access the backend using SSL directly, but not thorugh the proxy. What's the problem with my SSL config for the front end proxy? From pluknet at nginx.com Wed Jun 9 12:31:34 2021 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 9 Jun 2021 15:31:34 +0300 Subject: SSL protocl errors only when Reverse-proxying Unit (Wordpress) app behind Nginx? In-Reply-To: References: Message-ID: > On 9 Jun 2021, at 14:06, bill noneofyourbusiness wrote: > > I'm working on Fronting Wordpress installed as a Unit app with Nginx. > > I run > > nginx -v > nginx version: nginx/1.21.0 > unitd --version > unit version: 1.24.0 > php -v > PHP 8.0.7 (cli) (built: Jun 1 2021 18:43:05) ( NTS gcc x86_64 ) > Copyright (c) The PHP Group > Zend Engine v4.0.7, Copyright (c) Zend Technologies > with Zend OPcache v8.0.7, Copyright (c), by Zend Technologies > with Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick Rethans > > I'm following instructions from > > Unit:HOWTO:NGINX Integration:Fronting Unit with NGINX > https://unit.nginx.org/howto/integration/#fronting-unit-with-nginx > > Unit:HOWTO:Applications:Wordpress > https://unit.nginx.org/howto/wordpress/#wordpress > > I installed Wordpress on Unit. > > I can access the site and login directly, with valid SSL/cert, at > > https://wp.loc:60000 > > Host is > > host wp.loc > wp.loc has address 127.0.0.1 > > The Unit config for that is > > { > "certificates": { [snip] > }, > > "config": { > "listeners": { > "127.0.0.1:60000": { > "pass": "routes", > "tls": { > "certificate": "bundle", > "conf_commands": { > "minprotocol": "TLSv1.3", > "ciphersuites": "TLS_CHACHA20_POLY1305_SHA256", > } > } > } > }, [snip] > } > } > > The frontend Nginx config includes > > upstream WPUNITproxy { server wp.loc:60000; } > > server { [snip] > location /blog/ { > proxy_pass https://WPUNITproxy/; > proxy_set_header Host $host; > proxy_set_header HTTPS on; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Host $server_name; > proxy_set_header X-Forwarded-Port $server_port; > proxy_set_header X-Forwarded-Proto https; > proxy_set_header X-Forwarded-Protocol https; > proxy_set_header X-Forwarded-Server $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-SSL-Subject $ssl_client_s_dn; > proxy_set_header X-SSL-Issuer $ssl_client_i_dn; > > proxy_ssl_name wp.loc; > proxy_ssl_verify off; > proxy_ssl_verify_depth 2; > proxy_ssl_trusted_certificate "/home/wwwrun/ssl/chain.crt"; > proxy_ssl_certificate "/home/wwwrun/ssl/wp.loc.client.crt"; > proxy_ssl_certificate_key "/home/wwwrun/ssl/wp.loc.client.key"; > > } > > Host is > > host front.loc > front.loc has address 10.15.12.11 > > When I go to the FRONT end proxy, > > https://front.loc/blog/ > > I get SSL errors > > ==> /var/log/wwwrun/unit.log <== > 2021/06/09 06:20:00 [alert] 43183#44092 *248 SSL_do_handshake(96) failed (258: unsupported protocol) (OpenSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) > > ==> /var/log/wwwrun/nginx.error.log <== > 2021/06/09 06:20:00 [error] 63200#63200: *4 SSL_do_handshake() failed (SSL: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:SSL alert number 70) while SSL handshaking to upstream, client: 10.15.12.11, server: front.loc, request: "GET /blog/ HTTP/2.0", upstream: "https://127.0.0.1:60000/", host: "front.loc" > > So I can access the backend using SSL directly, but not thorugh the proxy. > > What's the problem with my SSL config for the front end proxy? You need to reconcile allowed TLS protocol versions between nginx and unit. In the unit configuration provided above you have: "minprotocol": "TLSv1.3" nginx doesn't enable TLSv1.3 by default (yet), it needs to be enabled explicitly, e.g.: proxy_ssl_protocols TLSv1.3; -- Sergey Kandaurov From zmey1992 at ya.ru Wed Jun 9 21:24:34 2021 From: zmey1992 at ya.ru (=?utf-8?B?0JLQsNGB0LjQu9GM0LXQsiAiWm1leSEiINCe0LvQtdCz?=) Date: Thu, 10 Jun 2021 00:24:34 +0300 Subject: Unit Go CGO_CFLAGS_ALLOW Message-ID: <2134231623273302@mail.yandex.ru> An HTML attachment was scrubbed... URL: From max.romanov at nginx.com Thu Jun 10 13:59:46 2021 From: max.romanov at nginx.com (Max Romanov) Date: Thu, 10 Jun 2021 16:59:46 +0300 Subject: Unit Go CGO_CFLAGS_ALLOW In-Reply-To: <2134231623273302@mail.yandex.ru> References: <2134231623273302@mail.yandex.ru> Message-ID: Hello! > On 10 Jun 2021, at 00:24, ???????? Zmey! ???? wrote: > > Hi! > > Tried to build Unit 1.24 and found out that I can't compile Go module without environment variable set: CGO_CFLAGS_ALLOW='-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS|-fcf-protection' > Go complains that there are invalid (untrusted) flags: > go build unit.nginx.org/go: invalid flag in #cgo CFLAGS: -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS > go build unit.nginx.org/go: invalid flag in #cgo CFLAGS: -fcf-protection Most likely these flags were added because you have specified it when configuring Unit. > > So please consider to either add CGO_CFLAGS_ALLOW to build script or remove these options. If I?m right thinking you are building Unit and Go module from sources with these flags, it is up to you to control your building environment. If my assumption is wrong, please describe what you are doing with more details. > > WBR, Oleg. ? Best regards, Max > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill14653 at protonmail.com Thu Jun 10 22:33:29 2021 From: bill14653 at protonmail.com (Bill) Date: Thu, 10 Jun 2021 22:33:29 +0000 Subject: Update to documentation for hosting Wordpress on Unit behind Nginx reverse proxy? Any working examples with complete config? Message-ID: Hello, This tutorial for putting Wordpress on Unit behind Nginx reverse-proxy Installing WordPress with NGINX Unit https://www.nginx.com/blog/installing-wordpress-with-nginx-unit/ was written back in 2018, before 'routes' etc were added to Unit. This up to date documentation WordPress https://www.nginx.com/blog/installing-wordpress-with-nginx-unit/ doesn't address Reverse-proxying. This doc NGINX Integration https://unit.nginx.org/howto/integration/ talks about "Fronting Unit with NGINX" but then only gives an example of proxying the Unit Control API. Is there a single document, showing complete configuration, for hosting Wordpress on Unit behind an Nginx Reverse-proxy that's up-to-date with latest version of Unit, AND includes detail/example of putting it all in a subdirectory of the Nginx frontend? So, for example, https://frontend.example.com/blog, on Nginx <-> https://backend.example.com:10000, Wordpress on Unit ? I've been trying for a long time to get it working with Wordpress on Nginx. Couldn't get that to work and there's no documentation or support for that configuration afaict. I did find other people's posts that tried and gave up on it too. I found these articles for using Unit on the backend host instead.? Hoping to get an updated config them to do the full reverse proxy setup. Bill From bill14653 at protonmail.com Sun Jun 13 20:34:01 2021 From: bill14653 at protonmail.com (Bill) Date: Sun, 13 Jun 2021 20:34:01 +0000 Subject: correct Nginx Unix SNI usage? getting error "SSL_get_servername() returned NULL in server name callback" Message-ID: Hi, I installed unit version: 1.24.0 It's behind a Nginx reverse proxy upstream UNIT { server 127.0.0.1:12345; } server { server_name example.com; location /testA { proxy_pass https://UNIT/testB; proxy_ssl_name example1.com; proxy_ssl_certificate "/www/example1.com.client.crt"; proxy_ssl_certificate_key "/www/example1.com.client.key"; ... } location /testB { proxy_pass https://UNIT/testB; proxy_ssl_name example2.com; proxy_ssl_certificate "/www/example2.com.client.crt"; proxy_ssl_certificate_key "/www/example2.com.client.key"; ... } ... I want to setup ssl for SNI. I watched Timo Stark's NGINX Unit 1.23 - SNI Deep Dive https://www.youtube.com/watch?v=absaan-8y1Q which was the best, and only, 'documentation' I could find that actually mentions the new SNI usage. My certs are good, and work great in Nginx, front and/or backends. For unit, I created server cert bundles, and uploaded them to Unit config { "certificates": { "example1.com.server": { "key": "ECDH", "chain": [ { "subject": { "common_name": "example1.com", "alt_names": [ "example1.com", "www.example1.com" ], "country": "US", ... }, "example2.com.server": { "key": "ECDH", "chain": [ { "subject": { "common_name": "example2.com", "alt_names": [ "example2.com", "www.example2.com" ], "country": "US", ... }, and the listener is configured for SNI with both certs "config": { "listeners": { "127.0.0.1:12345": { "pass": "routes/main", "tls": { "certificate": [ "example1.com.server", "example2.com.server" ], "conf_commands": { "minprotocol": "TLSv1.3", "ciphersuites": "TLS_CHACHA20_POLY1305_SHA256" } } } }, "routes": { ... } when I access https://example.com/testA I get in the log ==> /var/log/www/unit.log <== 2021/06/13 15:46:20 [alert] 35036#35041 *21 SSL_get_servername() returned NULL in server name callback ==> /var/log/www/nginx.error.log <== 2021/06/13 15:46:20 [crit] 29271#29271: *30 SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: fe80::5ec:3ecf:dd74:fa2e, server: example.com, request: "GET /testA HTTP/2.0", upstream: "https://127.0.0.1:12345/testA", host: "example.com" 2021/06/13 15:46:20 [warn] 29271#29271: *30 upstream server temporarily disabled while SSL handshaking to upstream, client: fe80::5ec:3ecf:dd74:fa2e, server: example.com, request: "GET /testA HTTP/2.0", upstream: "https://127.0.0.1:12345/testA", host: "example.com" ==> /var/log/www/unit.log <== 2021/06/13 15:46:20 [alert] 35036#35041 *21 SSL_do_handshake(97) failed (234: callback failed) (OpenSSL: error:1422E0EA:SSL routines:final_server_name:callback failed) Since my certs are fine with SNI in Nginx I'm sure it's my wrong usage for Unit. What in, or missing from, from config is causing that "NULL in server name callback" error? Bill From pluknet at nginx.com Tue Jun 15 10:50:51 2021 From: pluknet at nginx.com (Sergey Kandaurov) Date: Tue, 15 Jun 2021 13:50:51 +0300 Subject: correct Nginx Unix SNI usage? getting error "SSL_get_servername() returned NULL in server name callback" In-Reply-To: References: Message-ID: <9FCB28CE-9BF7-4432-8EC9-0BB46DB6DBD5@nginx.com> > On 13 Jun 2021, at 23:34, Bill wrote: > > Hi, > > I installed > > unit version: 1.24.0 > > It's behind a Nginx reverse proxy > > upstream UNIT { server 127.0.0.1:12345; } > server { > server_name example.com; > location /testA { > proxy_pass https://UNIT/testB; > proxy_ssl_name example1.com; > proxy_ssl_certificate "/www/example1.com.client.crt"; > proxy_ssl_certificate_key "/www/example1.com.client.key"; > ... > } > location /testB { > proxy_pass https://UNIT/testB; > proxy_ssl_name example2.com; > proxy_ssl_certificate "/www/example2.com.client.crt"; > proxy_ssl_certificate_key "/www/example2.com.client.key"; > ... > } > ... > > I want to setup ssl for SNI. You likely missed to enable passing SNI to the proxied server (unit). By default, it is disabled in nginx. See for details: http://nginx.org/r/proxy_ssl_server_name > > I watched Timo Stark's > > NGINX Unit 1.23 - SNI Deep Dive > https://www.youtube.com/watch?v=absaan-8y1Q > > which was the best, and only, 'documentation' I could find that actually mentions the new SNI usage. > > My certs are good, and work great in Nginx, front and/or backends. > > For unit, I created server cert bundles, and uploaded them to Unit config > > { > "certificates": { > "example1.com.server": { > "key": "ECDH", > "chain": [ > { > "subject": { > "common_name": "example1.com", > "alt_names": [ > "example1.com", > "www.example1.com" > ], > > "country": "US", > ... > }, > > "example2.com.server": { > "key": "ECDH", > "chain": [ > { > "subject": { > "common_name": "example2.com", > "alt_names": [ > "example2.com", > "www.example2.com" > ], > > "country": "US", > ... > }, > > and the listener is configured for SNI with both certs > > "config": { > "listeners": { > "127.0.0.1:12345": { > "pass": "routes/main", > "tls": { > "certificate": [ > "example1.com.server", > "example2.com.server" > ], > > "conf_commands": { > "minprotocol": "TLSv1.3", > "ciphersuites": > "TLS_CHACHA20_POLY1305_SHA256" > } > } > } > }, > > "routes": { > ... > } > > > when I access > > https://example.com/testA > > I get in the log > > ==> /var/log/www/unit.log <== > 2021/06/13 15:46:20 [alert] 35036#35041 *21 SSL_get_servername() returned NULL in server name callback That likely means that unit didn't receive SNI (because nginx didn't send SNI to unit). > > ==> /var/log/www/nginx.error.log <== > 2021/06/13 15:46:20 [crit] 29271#29271: *30 SSL_do_handshake() failed (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:SSL alert number 112) while SSL handshaking to upstream, client: fe80::5ec:3ecf:dd74:fa2e, server: example.com, request: "GET /testA HTTP/2.0", upstream: "https://127.0.0.1:12345/testA", host: "example.com" > 2021/06/13 15:46:20 [warn] 29271#29271: *30 upstream server temporarily disabled while SSL handshaking to upstream, client: fe80::5ec:3ecf:dd74:fa2e, server: example.com, request: "GET /testA HTTP/2.0", upstream: "https://127.0.0.1:12345/testA", host: "example.com" Then unit sent back the SSL alert unrecognized_name(112). > > ==> /var/log/www/unit.log <== > 2021/06/13 15:46:20 [alert] 35036#35041 *21 SSL_do_handshake(97) failed (234: callback failed) (OpenSSL: error:1422E0EA:SSL routines:final_server_name:callback failed) > > Since my certs are fine with SNI in Nginx I'm sure it's my wrong usage for Unit. > > What in, or missing from, from config is causing that "NULL in server name callback" error? > > Bill > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit -- Sergey Kandaurov From zmey1992 at ya.ru Thu Jun 17 23:04:08 2021 From: zmey1992 at ya.ru (=?utf-8?B?0JLQsNGB0LjQu9GM0LXQsiAiWm1leSEiINCe0LvQtdCz?=) Date: Fri, 18 Jun 2021 02:04:08 +0300 Subject: Unit Go CGO_CFLAGS_ALLOW In-Reply-To: References: <2134231623273302@mail.yandex.ru> Message-ID: <418631623969650@mail.yandex.ru> An HTML attachment was scrubbed... URL: From aduskett at gmail.com Fri Jun 25 21:13:49 2021 From: aduskett at gmail.com (aduskett at gmail.com) Date: Fri, 25 Jun 2021 14:13:49 -0700 Subject: [PATCH 2 of 2] build: add qemu-wrapper support for cross-compiling In-Reply-To: References: Message-ID: <54c1ab7fb6aec6f52946.1624655629@adam.duskett> # HG changeset patch # User Adam Duskett # Date 1624654367 25200 # Fri Jun 25 13:52:47 2021 -0700 # Node ID 54c1ab7fb6aec6f52946ee751160b139c485f620 # Parent e6d0b8882618fd43f4b97a6d0e708de9b82d44e5 build: add qemu-wrapper support for cross-compiling Because unit doesn't use a traditional build system like autotools, cmake, or meson, cross-compiling support has several major issues. The largest issue is that the configure system builds test application to determin compiler and system features, which, if cross-compiling, will not run on the host pc due to the architecture being different. The proper fix would be to switch the build system to CMake or Meson, but in the meantime adding support for a qemu wrapper is the best alternative. When --autotest-qemu-wrapper is provided as a configure option, auto/feature will use the wrapper to run the cross-compiled autotest application. diff -r e6d0b8882618 -r 54c1ab7fb6ae auto/feature --- a/auto/feature Fri Jun 25 13:46:21 2021 -0700 +++ b/auto/feature Fri Jun 25 13:52:47 2021 -0700 @@ -47,14 +47,18 @@ if [ -x $NXT_AUTOTEST ]; then + NXT_AUTOTEST_RUN="$NXT_AUTOTEST" + if [ "$AUTOTEST_QEMU_WRAPPER" != "none" ]; then + NXT_AUTOTEST_RUN="$AUTOTEST_QEMU_WRAPPER $NXT_AUTOTEST" + fi case "$nxt_feature_run" in value) - if /bin/sh -c "($NXT_AUTOTEST)" >> $NXT_AUTOCONF_ERR 2>&1; then + if /bin/sh -c "($NXT_AUTOTEST_RUN)" >> $NXT_AUTOCONF_ERR 2>&1; then $echo >> $NXT_AUTOCONF_ERR nxt_found=yes - nxt_feature_value=`$NXT_AUTOTEST` + nxt_feature_value=`$NXT_AUTOTEST_RUN` $echo " $nxt_feature_value" if [ -n "$nxt_feature_name" ]; then cat << END >> $NXT_AUTO_CONFIG_H @@ -71,7 +75,7 @@ ;; yes) - if /bin/sh -c "($NXT_AUTOTEST)" >> $NXT_AUTOCONF_ERR 2>&1; then + if /bin/sh -c "($NXT_AUTOTEST_RUN)" >> $NXT_AUTOCONF_ERR 2>&1; then $echo " found" nxt_found=yes if [ -n "$nxt_feature_name" ]; then diff -r e6d0b8882618 -r 54c1ab7fb6ae auto/options --- a/auto/options Fri Jun 25 13:46:21 2021 -0700 +++ b/auto/options Fri Jun 25 13:52:47 2021 -0700 @@ -50,6 +50,7 @@ esac case "$nxt_option" in + --autotest-qemu-wrapper=*) AUTOTEST_QEMU_WRAPPER="$value" ;; --cc=*) CC="$value" ;; --cc-opt=*) NXT_CC_OPT="$value" ;; --host-cc=*) HOST_CC="$value" ;; diff -r e6d0b8882618 -r 54c1ab7fb6ae auto/save --- a/auto/save Fri Jun 25 13:46:21 2021 -0700 +++ b/auto/save Fri Jun 25 13:52:47 2021 -0700 @@ -7,6 +7,7 @@ NXT_SYSTEM='$NXT_SYSTEM' +AUTOTEST_QEMU_WRAPPER='$AUTOTEST_QEMU_WRAPPER' CC='$CC' HOST_CC='$HOST_CC' CFLAGS='$CFLAGS' diff -r e6d0b8882618 -r 54c1ab7fb6ae configure --- a/configure Fri Jun 25 13:46:21 2021 -0700 +++ b/configure Fri Jun 25 13:52:47 2021 -0700 @@ -30,7 +30,7 @@ CC=${CC:-cc} HOST_CC=${HOST_CC:-cc} - +AUTOTEST_QEMU_WRAPPER=${AUTOTEST_QEMU_WRAPPER:-"none"} NXT_DAEMON=unitd NXT_BINDIR="bin" NXT_SBINDIR="sbin" From aduskett at gmail.com Fri Jun 25 21:13:48 2021 From: aduskett at gmail.com (aduskett at gmail.com) Date: Fri, 25 Jun 2021 14:13:48 -0700 Subject: [PATCH 1 of 2] build: add host-cc option Message-ID: # HG changeset patch # User Adam Duskett # Date 1624653981 25200 # Fri Jun 25 13:46:21 2021 -0700 # Node ID e6d0b8882618fd43f4b97a6d0e708de9b82d44e5 # Parent 2e84334ca8dbbf10d0fa7ca413757d7980158d91 build: add host-cc option When running ./configure, the build system currently builds the echo application using the specified --cc. However, when cross-compiling, the echo program is currently compiled using the same compiler, which results in the host x86 pc unable to execute the echo utility. Add a --host-cc compile option and use the host cc to build the echo utility. diff -r 2e84334ca8db -r e6d0b8882618 auto/echo/build --- a/auto/echo/build Thu Jun 24 04:01:15 2021 +0100 +++ b/auto/echo/build Fri Jun 25 13:46:21 2021 -0700 @@ -7,7 +7,7 @@ rm -f $NXT_BUILD_DIR/echo -nxt_echo_test="$CC -o $NXT_BUILD_DIR/echo -O $NXT_CC_OPT +nxt_echo_test="$HOST_CC -o $NXT_BUILD_DIR/echo -O $NXT_CC_OPT auto/echo/echo.c $NXT_LD_OPT" # "|| true" is to bypass "set -e" setting. diff -r 2e84334ca8db -r e6d0b8882618 auto/help --- a/auto/help Thu Jun 24 04:01:15 2021 +0100 +++ b/auto/help Fri Jun 25 13:46:21 2021 -0700 @@ -9,6 +9,7 @@ --cc=FILE set C compiler filename, default: "$CC" --cc-opt=OPTIONS set additional C compiler options + --host-cc=FILE set host C compiler filename, default: "$CC" --ld-opt=OPTIONS set additional linker options --prefix=DIRECTORY set prefix for relative pathnames, default: none diff -r 2e84334ca8db -r e6d0b8882618 auto/options --- a/auto/options Thu Jun 24 04:01:15 2021 +0100 +++ b/auto/options Fri Jun 25 13:46:21 2021 -0700 @@ -52,6 +52,7 @@ case "$nxt_option" in --cc=*) CC="$value" ;; --cc-opt=*) NXT_CC_OPT="$value" ;; + --host-cc=*) HOST_CC="$value" ;; --ld-opt=*) NXT_LD_OPT="$value" ;; --prefix=*) NXT_PREFIX="$value" ;; diff -r 2e84334ca8db -r e6d0b8882618 auto/save --- a/auto/save Thu Jun 24 04:01:15 2021 +0100 +++ b/auto/save Fri Jun 25 13:46:21 2021 -0700 @@ -8,6 +8,7 @@ NXT_SYSTEM='$NXT_SYSTEM' CC='$CC' +HOST_CC='$HOST_CC' CFLAGS='$CFLAGS' NXT_CC_NAME='$NXT_CC_NAME' diff -r 2e84334ca8db -r e6d0b8882618 configure --- a/configure Thu Jun 24 04:01:15 2021 +0100 +++ b/configure Fri Jun 25 13:46:21 2021 -0700 @@ -29,6 +29,7 @@ NXT_MAKEFILE=$NXT_BUILD_DIR/Makefile CC=${CC:-cc} +HOST_CC=${HOST_CC:-cc} NXT_DAEMON=unitd NXT_BINDIR="bin"