Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: c-ares linking problem on Apple, cross-compiling for ARM.
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 25 Jan 2023 09:54:59 -0500
On Wed, Jan 25, 2023 at 9:37 AM Ben Greear <greearb_at_candelatech.com> wrote:
>
> On 1/25/23 3:51 AM, Jeffrey Walton wrote:
> > On Wed, Jan 25, 2023 at 12:46 AM Ben Greear via curl-library
> > <curl-library_at_lists.haxx.se> wrote:
> >>
> >> So, I'm well off in the weeds here.
> >>
> >> Trying to compile lib-cares on macos (using clang), for ARM target on x86-64 macos machine. I'm able to see the
> >> c files compiled for the right target, but the linker part is not passing the -target
> >> flag it seems.
> >>
> >> [...]
> >> Here is how I am doing the configure step:
> >>
> >> (cd c-ares.ct && \
> >> export CFLAGS="-mmacosx-version-min=11.0 -target arm64-apple-macos11"; \
> >> export LDFLAGS="-mmacosx-version-min=11.0 -target arm64-apple-macos11"; \
> >> ./configure --enable-warnings --host=aarch64-apple-darwin && \
> >> perl -i.bkp -pe 's/^archive_cmds.*\K-install_name/-target arm64-apple-macos11 -install_name/' libtool)
> >
> > I think there may be two problems. First, I think you should set a
> > sysroot. Second, I think you should set CPPFLAGS. I would also set
> > CXXFLAGS for completeness, but I don't believe it's a problem in this
> > instance. CXXFLAGS will just be ignored if it is not used.
> >
> > CPPFLAGS will include --isysroot . LDFLAGS will include --sysroot.
> >
> > Here's what things look like when I set a cross-compile environment
> > for an iPad from an old Intel MacBook using an old XCode:
>
> Thanks for the suggestion. I'm pretty sure it is not a problem with setting C*FLAGS,
> since those show up as expected in sysroot. I think '-target' is treated special
> somehow and ignored, though I cannot find exactly why/where that is happening.
>
> Even after my hack yesterday I found another problem though, and that is the libraries
> like 'openssl' that I was getting from 'mac ports' project
> are of course built for the host CPU so won't link into the m1 compiled code.
Yeah, you usually need to build the target (like cURL and c-ares) and
all the dependencies (like IDN2, PCRE and OpenSSL) in this scenario.
It has been my experience that cuRL is one of the tougher recipes you
will encounter because it has so many dependendencies. It's not good
or bad, it's just the way it is.
> Do you know if there is an easy way to install ports for a non-native CPU? I'm guessing not, and that
> my best way forward is just to buy another m1 macos machine and build directly on it.
> But, if you know a way, please let me know.
Native compilation will probably be easiest.
If you want to cross-compile, then you will want (need?) a script like
setenv-ios.sh to setup all your flags. Decide on a location, like
/opt/ios/aarch64/. Then, for cURL, c-ares and each dependent library,
you configure for the cross-compile (using --host and --build), and
build each library for the common place (--prefix=/opt/ios/aarch64/).
Your flags will need to include /opt/ios/aarch64/include in CPPFLAGS,
and /opt/ios/aarch64/lib for LDFLAGS.
The pain point of the cross-compile will be projects which do not
honor your flags. The makefile authors will overwrite your CPPFLAGS,
CFLAGS, CXXFLAGS and LDFLAGS, and it will break your cross-compile. I
have patched a lot of makefiles over the years because of this
problem.
A good program to experiment with cross-compiles is OpenSSH. OpenSSH
has two components - OpenSSH itself and OpenSSL as a dependency. (LDNS
is optional and not required). Once you work out your methodology with
OpenSSH, it will scale to bigger projects like cURL (modulo makefile
authors stomping on your flags).
Jeff
Date: Wed, 25 Jan 2023 09:54:59 -0500
On Wed, Jan 25, 2023 at 9:37 AM Ben Greear <greearb_at_candelatech.com> wrote:
>
> On 1/25/23 3:51 AM, Jeffrey Walton wrote:
> > On Wed, Jan 25, 2023 at 12:46 AM Ben Greear via curl-library
> > <curl-library_at_lists.haxx.se> wrote:
> >>
> >> So, I'm well off in the weeds here.
> >>
> >> Trying to compile lib-cares on macos (using clang), for ARM target on x86-64 macos machine. I'm able to see the
> >> c files compiled for the right target, but the linker part is not passing the -target
> >> flag it seems.
> >>
> >> [...]
> >> Here is how I am doing the configure step:
> >>
> >> (cd c-ares.ct && \
> >> export CFLAGS="-mmacosx-version-min=11.0 -target arm64-apple-macos11"; \
> >> export LDFLAGS="-mmacosx-version-min=11.0 -target arm64-apple-macos11"; \
> >> ./configure --enable-warnings --host=aarch64-apple-darwin && \
> >> perl -i.bkp -pe 's/^archive_cmds.*\K-install_name/-target arm64-apple-macos11 -install_name/' libtool)
> >
> > I think there may be two problems. First, I think you should set a
> > sysroot. Second, I think you should set CPPFLAGS. I would also set
> > CXXFLAGS for completeness, but I don't believe it's a problem in this
> > instance. CXXFLAGS will just be ignored if it is not used.
> >
> > CPPFLAGS will include --isysroot . LDFLAGS will include --sysroot.
> >
> > Here's what things look like when I set a cross-compile environment
> > for an iPad from an old Intel MacBook using an old XCode:
>
> Thanks for the suggestion. I'm pretty sure it is not a problem with setting C*FLAGS,
> since those show up as expected in sysroot. I think '-target' is treated special
> somehow and ignored, though I cannot find exactly why/where that is happening.
>
> Even after my hack yesterday I found another problem though, and that is the libraries
> like 'openssl' that I was getting from 'mac ports' project
> are of course built for the host CPU so won't link into the m1 compiled code.
Yeah, you usually need to build the target (like cURL and c-ares) and
all the dependencies (like IDN2, PCRE and OpenSSL) in this scenario.
It has been my experience that cuRL is one of the tougher recipes you
will encounter because it has so many dependendencies. It's not good
or bad, it's just the way it is.
> Do you know if there is an easy way to install ports for a non-native CPU? I'm guessing not, and that
> my best way forward is just to buy another m1 macos machine and build directly on it.
> But, if you know a way, please let me know.
Native compilation will probably be easiest.
If you want to cross-compile, then you will want (need?) a script like
setenv-ios.sh to setup all your flags. Decide on a location, like
/opt/ios/aarch64/. Then, for cURL, c-ares and each dependent library,
you configure for the cross-compile (using --host and --build), and
build each library for the common place (--prefix=/opt/ios/aarch64/).
Your flags will need to include /opt/ios/aarch64/include in CPPFLAGS,
and /opt/ios/aarch64/lib for LDFLAGS.
The pain point of the cross-compile will be projects which do not
honor your flags. The makefile authors will overwrite your CPPFLAGS,
CFLAGS, CXXFLAGS and LDFLAGS, and it will break your cross-compile. I
have patched a lot of makefiles over the years because of this
problem.
A good program to experiment with cross-compiles is OpenSSH. OpenSSH
has two components - OpenSSH itself and OpenSSL as a dependency. (LDNS
is optional and not required). Once you work out your methodology with
OpenSSH, it will scale to bigger projects like cURL (modulo makefile
authors stomping on your flags).
Jeff
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-25