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

mac and linux builds #1

Closed
wants to merge 199 commits into from
Closed

mac and linux builds #1

wants to merge 199 commits into from

Conversation

vszakats
Copy link
Owner

@vszakats vszakats commented Sep 1, 2023

No description provided.

Fixing (seen on bullseye):
```
+ checksec --format=xml --fortify-file=x64-musl/usr/bin/curl
<?xml version="1.0" encoding="UTF-8"?>
<fortify-test name='x64-musl/usr/bin/curl'  libc_fortify_source='yes'  binary_compiled_with_fortify='no'>
Command exited with non-zero status 1
```
It builds correctly now. It also doesn't use nasm.
From a build perspective it behaves almost exactly like BoringSSL, and
we're assuming the same codepaths by default.

AWC-LC has a built-in way to skip building tests and command-line tools.
We do use that. It also has versioned releases and a way to retrieve
this version number at build-time, so no need for the commit hash hack
we use with BoringSSL.

It suffers from the same pthread dependency issue on Windows, by the
looks of its source code.

Actual testing on Windows reveals that the project no longer compiles
with llvm-mingw:

```
awslc/crypto/refcount_win.c:23:15: error: expected parameter declarator
static_assert(alignof(CRYPTO_refcount_t) == alignof(LONG),
              ^
```

It means we lost BoringSSL for Windows and also AWS-LC. Comments tell
that their team only tests Visual Studio, though they were open for
other compilers. That was in 2021.

This patch is experimental and AWS-LC support might be removed in the
future.
_umul128 should be supported by llvm, but apparently not on Windows?
https://reviews.llvm.org/D25353

A similar issue has been fixed in BoringSSL on 2014-12-02:
google/boringssl@af9d941
This option strips the UUID. On one hand this may cause problems
down the line according to the man page, on the other, this UUID
is calculated from the output, and doesn't contain randomness or
depends on timestamps, meaning: it's reproducible.
We disabled it partly because in macOS builds LDAPS was not
enabled in CMake builds. Also wrongly assumed this also applies
to autotools builds, but it turned out this was an issue with
CMake builds and fixed here:
  curl/curl#12006 (in curl 8.4.0)

We this fix, we can enable it.

The other reason for disabling it was that Apple deprecated the
LDAP API in 10.10.

To avoid extra deprecation warnings coming with LDAP on macOS,
target OS X 10.9 Mavericks instead of High Sierra.

The build also runs fine with these warning present.
```
+ cd libssh2
+ rm -r -f x64-musl bld
+ '[' -f configure ']'
+ autoreconf --force --install
Can't exec "aclocal": No such file or directory at /usr/local/Cellar/autoconf/2.71/share/autoconf/Autom4te/FileUtils.pm line 274.
autoreconf: error: aclocal failed with exit status: 2
```
Ref: https://github.com/vszakats/curl-for-win/actions/runs/6392970919/job/17351293395#step:3:4308
This reverts commit d118599.

Targeting 10.8 results in C++ standard library confusion when doing
feature detection in projects with a C++ requirement, such as zstd.

Will not be digging for the root cause, but keep targeting 10.9 instead.

```
variable: "CMAKE_CXX_COMPILER_WORKS"
cached: true
stdout: |
  Change Dir: '.../zstd/bld/CMakeFiles/CMakeScratch/TryCompile-8BdrEx'

  Run Build Command(s): /usr/local/Cellar/cmake/3.27.6/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTW_f093b/fast
  /Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/cmTW_f093b.dir/build.make CMakeFiles/cmTW_f093b.dir/build
  Building CXX object CMakeFiles/cmTW_f093b.dir/testCXXCompiler.cxx.o
  /usr/bin/clang++ --target=x86_64-apple-darwin   -Wno-unused-command-line-argument  -mmacosx-version-min=10.8     -mmacosx-version-min=10.8  -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk -mmacosx-version-min=10.8 -MD -MT CMakeFiles/cmTW_f093b.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTW_f093b.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTW_f093b.dir/testCXXCompiler.cxx.o -c .../zstd/bld/CMakeFiles/CMakeScratch/TryCompile-8BdrEx/testCXXCompiler.cxx
  clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
  Linking CXX executable cmTW_f093b
  /usr/local/Cellar/cmake/3.27.6/bin/cmake -E cmake_link_script CMakeFiles/cmTW_f093b.dir/link.txt --verbose=1
  /usr/bin/clang++ --target=x86_64-apple-darwin  -Wno-unused-command-line-argument  -mmacosx-version-min=10.8     -mmacosx-version-min=10.8  -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk -mmacosx-version-min=10.8 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTW_f093b.dir/testCXXCompiler.cxx.o -o cmTW_f093b
  clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
  ld: library not found for -lstdc++
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  make[1]: *** [cmTW_f093b] Error 1
  make: *** [cmTW_f093b/fast] Error 2

exitCode: 2
```
@vszakats
Copy link
Owner Author

vszakats commented Oct 8, 2023

Merged via curl#53.

@vszakats vszakats closed this Oct 8, 2023
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.

2 participants