-
Notifications
You must be signed in to change notification settings - Fork 132
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
Not possible to build source-build release/3.0 on new distributions #1083
Comments
libgit2sharp has an so file for fedora under the fedora-x64 rid:
that one would work, but instead it is using the linux-x64 rid:
which has missing libraries for openssl. If you set |
Hello, I am having the same issue under Arch Linux, copying the fedora-x64 .so file over the linux-x64 one works. This is because libgit2sharp.nativebinaries builds its linux-x64 binary using Ubuntu 14.04 (https://github.com/libgit2/libgit2sharp.nativebinaries/blob/master/Dockerfile.linux-x64). |
@omajid did you give this a try? This issue also relates to providing a complete source tarball per release (cfr #298). The issue happens here because |
SourceLink removed its dependency on this native binary with dotnet/sourcelink#288, maybe similar could be done for Darc? My understanding is that /cc @crummel |
No, I didn't. |
Oops. Turns out I was wrong. I built source build to create the release tarball on Fedora 28. I then built from the tarball (which doesn't need git?) on Fedora 30. The issue still persists. This FROM fedora:30
RUN dnf install --setopt tsflags=nodocs --refresh -y \
clang \
cmake \
compat-openssl10 \
curl-devel \
findutils \
git \
hostname \
krb5-devel \
libicu-devel \
libunwind-devel \
lldb-devel \
llvm \
lttng-ust-devel \
make \
openssl-devel \
python3 \
tar \
wget \
which \
zlib-devel && \
dnf upgrade -y && \
dnf clean all -y
CMD git clone https://github.com/dotnet/source-build && \
cd source-build && \
git checkout release/3.0 && \
git submodule update --init --recursive && \
./build.sh |
Yes, this matches my earlier comment: #1083 (comment). Try setting |
Yes, that works. But it doesn't address the real issue that results from having very specific runtime ids, no real runtime id fallback mechanism, and bundling native libraries. |
This is indeed an issue. Even with a fallback mechanism, source-build wouldn't work on some platforms. |
If we acquire DARC rather than build it, this should be solved. @crummel to confirm. |
Edit: I just realized that arcade-services doesn't use SourceLink, it uses libgit2sharp directly for git operations. |
@crummel Will #1041 take care of this issue?
@ericstj Can you comment on the above? |
I think acquiring Darc will fix this. Another thing I'm seeing is that after I switched Darc to be compiled with the 3.0 SDK in the BuildTools removal PR, this worked with a little manual intervention that I think could be added to the build. If neither of those take care of the problem, we can look into shelling out to Git or other workarounds. |
I was trying to build source-build on an arm64 machine. This issue affects that too. I really think we need to make Darc more flexible. It probably shouldn't be (indirectly) using native binaries without a simple way to plug a custom binary. |
You can try one of these:
I can look into making libgit2sharp fall back to the native library provided by the platform in case the one it has in the package don't work. |
I'm making a different change: libgit2/libgit2sharp#1714 tries out the other native libraries that come with LibGit2Sharp. That should solve the issue for x64 (new Fedora versions) and arm64 (any Fedora version).
We still may want to pursue this. |
Could you give this a try now that the BuildTools removal PR with the switch to the 3.0 SDK is in? That seemed to fix the problem for me for now - we'll still want to acquire Darc instead of building it but it would be lower priority. |
I can confirm that this fixes the problems for me on Fedora 30 x86_64. Edit: But not on |
3.0 is EOL. Support for new/unknown Linux distributions is being tracked by #297 |
Darc needs to know about the runtime-id in advance since it it needs to find a libgit2sharp for the current pltaform.
On Fedora 30, this fails:
The end of the output shows why:
The text was updated successfully, but these errors were encountered: