Re: Wget2 cross-compile on iOS arm64

[Tim Rühsen]

On 21.03.21 11:41, Jeffrey Walton wrote:
> Hi Everyone/Tim,
>
> I've been testing iOS cross-compiles. It looks like Wget2 is having
> trouble with arm64:
>
> $ echo $CPPFLAGS
> -DNDEBUG -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
>
> $ echo $CFLAGS
> -Wall -g2 -O3 -fPIC -arch arm64 -miphoneos-version-min=6 --sysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
>
> $ echo $CXXFLAGS
> -Wall -g2 -O3 -fPIC -arch arm64 -miphoneos-version-min=6
> -stdlib=libc++ --sysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
>
> $ echo $LDFLAGS
>
> $ command -v cpp
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cpp
>
> $ cat config.log
> ...
> configure:6438: checking how to run the C preprocessor
> configure:6508: result: cpp
> configure:6528: cpp -DNDEBUG -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
> conftest.c
> clang: error: no input files
> configure:6528: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "wget2"
> | #define PACKAGE_TARNAME "wget2"
> | #define PACKAGE_VERSION "1.99.2"
> | #define PACKAGE_STRING "wget2 1.99.2"
> | #define PACKAGE_BUGREPORT "bug-wget@gnu.org"
> | #define PACKAGE_URL "https://savannah.gnu.org/projects/wget";
> | #define PACKAGE "wget2"
> | #define VERSION "1.99.2"
> | /* end confdefs.h.  */
> | #ifdef __STDC__
> | # include <limits.h>
> | #else
> | # include <assert.h>
> | #endif
> |                    Syntax error
> configure:6528: cpp -DNDEBUG -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
> conftest.c
> clang: error: no input files
> configure:6528: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "wget2"
> | #define PACKAGE_TARNAME "wget2"
> | #define PACKAGE_VERSION "1.99.2"
> | #define PACKAGE_STRING "wget2 1.99.2"
> | #define PACKAGE_BUGREPORT "bug-wget@gnu.org"
> | #define PACKAGE_URL "https://savannah.gnu.org/projects/wget";
> | #define PACKAGE "wget2"
> | #define VERSION "1.99.2"
> | /* end confdefs.h.  */
> | #ifdef __STDC__
> | # include <limits.h>
> | #else
> | # include <assert.h>
> | #endif
> |                    Syntax error
> configure:6558: error: in `/Users/jwalton/wget2-1.99.2':
> configure:6560: error: C preprocessor "cpp" fails sanity check
> See `config.log' for more details

Hi Jeff,

I don't have these issues on your M1 machine (thank you for the access) 
when just running ./configure. If you set flags like CPPFLAGS make sure 
these work with clang 12. The commands like 'gcc' and 'cpp' are

For example
% cpp --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: arm64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I am not a clang expert, but it looks like the -isysroot is the trouble.

So, I can build wget2 from tarball after
  ./configure --without-lzma --disable-manylibs

The first param is due to a general issue in our sloppy detection+use of 
libraries where we don't check for the header file (lzma.h in this case).

The second one is more complicated...
On Linux we use a patched version of libtool - we add 
'-no-whole-archive' to it so that only needed objects are linked to our 
libraries.
And on M1 there is not libtool in the working directory that we could 
patch (thus the non-fatal error in the configure run).
And even if we had that, proper linking then only works when using GNU ld.
As a work-around we could add @INTL_MACOSX_LIBS@ to the link step... but 
the libraries blow up in size and we might see 'multiple definition' 
errors later.

BTW, libtool is looking for a new maintainer ;-)

Unsure how to work around this properly on Mac, but --disable-manylibs 
should just work.


Then when building the tests in tests/, there seems to be a linker error 
as MHD isn't linked in and thus we have undefined symbol errors.
This is a blocker for running the tests and fixing this has priority for me.

Regards, Tim

OpenPGP_signature
Description: OpenPGP digital signature