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

Update darwin sdk and version #87

Merged
merged 16 commits into from
May 19, 2021

Conversation

michel-laterman
Copy link
Contributor

Update MacOS version + sdk to 10.13 and the corresponding Darwin version to 17.

@michel-laterman michel-laterman marked this pull request as draft May 13, 2021 16:58
@elasticmachine
Copy link

elasticmachine commented May 13, 2021

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: Pull request #87 updated

  • Start Time: 2021-05-19T15:44:18.164+0000

  • Duration: 30 min 51 sec

  • Commit: cf7402b

Trends 🧪

Image of Build Times

@michel-laterman
Copy link
Contributor Author

jenkins run tests

@michel-laterman
Copy link
Contributor Author

Currently the darwin build will fail; if the build debug flag is enabled and output is not piped to null we can see:

#6 113.4 [ 84%] Linking CXX static library ../libLLVMMC.a
#6 113.4 [ 84%] Built target LLVMMC
#6 113.4 CMakeFiles/Makefile2:28639: recipe for target 'projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule' failed
#6 113.4 make[1]: *** [projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule] Error 2
#6 113.4 Makefile:8361: recipe for target 'libtapi' failed
#6 113.4 make: *** [libtapi] Error 2
#6 113.4 + _exit
#6 113.4 + EC=2
#6 113.4 + '[' 2 -ne 0 ']'
#6 113.4 + test -z build.sh
#6 113.4 + echo ''
#6 113.4
#6 113.4 + echo 'exiting with abnormal exit code (2)'
#6 113.4 exiting with abnormal exit code (2)
#6 113.5 + test -n 1
#6 113.5 + '[' -n apple-libtapi ']'
#6 113.5 + rm -f 'build/*_built_successfully'
#6 113.5 + echo ''
#6 113.5
#6 113.5 + test build.sh = build.sh
#6 113.5 + check_for_bug_1242300
#6 113.5 + '[' -e /etc/issue ']'
#6 113.5 ++ grep -i ubuntu.13.10 /etc/issue
#6 113.5 + '[' '' ']'

@ph
Copy link
Contributor

ph commented May 17, 2021

@michel-laterman This is from the container?

@michel-laterman
Copy link
Contributor Author

Yes, there are currently 2 issues

  1. debian9 (the base image) installs a version of clang that is too old to compile osxcross
  2. the sdk for 10.13 is missing the libc++ headers

@ph
Copy link
Contributor

ph commented May 17, 2021

@urso What do you think about updating to a more recent version of debian? IIRC Debian 9 doesn't get any security updates anymore.

@michel-laterman with Debian10 do the two problems get resolved?

@ph
Copy link
Contributor

ph commented May 17, 2021

@andrewkroh would be good to have you comment on this.

@michel-laterman
Copy link
Contributor Author

@ph after recompressing (from bz2 to xz) a 10.14 SDK that another user has made (https://github.com/joseluisq/macosx-sdks/releases/tag/10.14) I was able to get osxcross compiling on debian10.

It seems that the releases that https://github.com/phracker/MacOSX-SDKs provides are broken for earler SDKs

@urso
Copy link

urso commented May 18, 2021

GO 1.14 is EOL, and 1.15 will soon be EOL as well. This is why we switch to 1.16. I think we can remove 1.14 already.

What do you think about updating to a more recent version of debian? IIRC Debian 9 doesn't get any security updates anymore.

For cross compiling to MacOS/Windows, the actual debian version should not matter.

For compiling on linux it matters unfortunately, and we need to keep debian7 in order to ensure our binaries continue to function with CentOS/RH7.
By accident I shared a Filebeat not build using the debian7 container 2 weeks ago, and the user was not able to run the binary on on RH7. RH7 goes EOL end of 2021, but we might have users that continue to use it even after.
The Beats-tester using a centos7 image should be able to discover potential problems (system linker complains on startup) if we update our debian build image. But debian10 might be too new I'm afraid.

after recompressing (from bz2 to xz) a 10.14 SDK that another user has made

We are moving here from MacOS 10.12 to 10.14. As MacOS 10.13 is EOL since December 2020 I think this is fine. We still want to report this as a breaking change in the next Beats release.

Cross compilation can be kinda painful. Plus we have to jump through some hoops in order to sign our binaries. For the future we might consider to switch to native build environments. @v1v WDYT?

@kuisathaverat
Copy link
Contributor

kuisathaverat commented May 18, 2021

GO 1.14 is EOL, and 1.15 will soon be EOL as well. This is why we switch to 1.16. I think we can remove 1.14 already.

we have removed 1.14 a couple of days ago, we only build 1.15 and 1.16

The Beats-tester using a centos7 image should be able to discover potential problems (system linker complains on startup)

it also runs tests on CentOS 6

Cross compilation can be kinda painful. Plus we have to jump through some hoops in order to sign our binaries. For the future we might consider to switch to native build environments.

We can switch now to build on native environments for x86, ARM, and MacOS. We have workers for those architectures. However, this requires changes on the build system, some of the package parts must be replaced.

@kuisathaverat
Copy link
Contributor

@ph after recompressing (from bz2 to xz) a 10.14 SDK that another user has made (https://github.com/joseluisq/macosx-sdks/releases/tag/10.14) I was able to get osxcross compiling on debian10.

It seems that the releases that https://github.com/phracker/MacOSX-SDKs provides are broken for earler SDKs

Update your PR with the changes on the master I have fixed all the stuff broken last week in the systemd dependencies. I seems like the new SDK does not work on old Libcs, it is fine we can use that new SDK only on Debian 10 and the old in the other versions of the cross-compiler Docker images. Then on the package build, we should choose the right Docker image depending on our target, on MacOS we do not have the issue related to libc compatibility is other OS.

Comment on lines 19 to 24
ARG OSXCROSS_SDK_URL=https://s3.amazonaws.com/beats-files/deps/MacOSX10.13.sdk.tar.xz
ARG OSXCROSS_PATH=/usr/osxcross
ARG OSXCROSS_REV=3034f7149716d815bc473d0a7b35d17e4cf175aa
ARG SDK_VERSION=10.11
ARG DARWIN_VERSION=15
ARG OSX_VERSION_MIN=10.10
ARG OSXCROSS_REV=8a716a43a72dab1db9630d7824ee0af3730cb8f9
ARG SDK_VERSION=10.13
ARG DARWIN_VERSION=17
ARG OSX_VERSION_MIN=10.12
Copy link
Contributor

@kuisathaverat kuisathaverat May 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{{if eq .DEBIAN_VERSION "10"}}
ARG OSXCROSS_SDK_URL=https://s3.amazonaws.com/beats-files/deps/MacOSX10.13.sdk.tar.xz
ARG OSXCROSS_PATH=/usr/osxcross
ARG OSXCROSS_REV=8a716a43a72dab1db9630d7824ee0af3730cb8f9
ARG SDK_VERSION=10.13
ARG DARWIN_VERSION=17
ARG OSX_VERSION_MIN=10.12
{{ else }}
ARG OSXCROSS_SDK_URL=https://s3.amazonaws.com/beats-files/deps/MacOSX10.11.sdk.tar.xz
ARG OSXCROSS_PATH=/usr/osxcross
ARG OSXCROSS_REV=3034f7149716d815bc473d0a7b35d17e4cf175aa
ARG SDK_VERSION=10.11
ARG DARWIN_VERSION=15
ARG OSX_VERSION_MIN=10.10
{{ end }}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this resolve the issue we will have the SDK 10.11 on Debian 7/8/9 and the SDK 10.13 on Debian 10

@kuisathaverat
Copy link
Contributor

now the SDK is downloaded and the osxcross compiled, but the helloWorld test falied

[2021-05-19T09:05:04.551Z] Step 15/21 : RUN cd /   && o64-clang helloWorld.c -o helloWorld   && file helloWorld   && file helloWorld | grep -c 'Mach-O 64-bit x86_64'

[2021-05-19T09:05:04.551Z]  ---> Running in 5c632da30120

[2021-05-19T09:05:04.551Z] /usr/osxcross/bin/x86_64-apple-darwin18-ld: error while loading shared libraries: libtapi.so.8svn: cannot open shared object file: No such file or directory

@kuisathaverat
Copy link
Contributor

ready to go

Jenkinsfile Outdated Show resolved Hide resolved
```

The SDK should be in the working directory.
The tmp dir can be safely deleted after this.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think the upload to the bucket should be also added in this section?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

@michel-laterman michel-laterman marked this pull request as ready for review May 19, 2021 15:45
@michel-laterman michel-laterman merged commit e96f6ca into elastic:master May 19, 2021
@michel-laterman michel-laterman deleted the macos-update branch May 19, 2021 19:30
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.

Building beats exposes some warning for legacy OS X versions
6 participants