Cannot build on Ubuntu 18.04 TLS #29289
Comments
|
Have you tried updating to 1.0.0-beta-63127-02? |
|
@tmat this comes bundled with RepoToolset in other repositories where I'm also hitting this hence I can't update the individual package. |
|
The default version can be overridden by specifying |
|
That does not fix it. How can I disable source link entirely until we find a wokr around here? Completely blocked at the moment. |
|
This should do |
|
Is OpenSSL installed on that machine? |
|
@bording Any idea? |
|
It's possible that there are some issues with the bundled native library that gets chosen for Ubuntu 18.04. I might need to update the package to include an 18.04-specific lib. I'll have to test a few things and see if that's the problem. |
Ah, yeah that's going to be the problem. I think Ubuntu 18.04 updated the version of curl they ship, so we're going to need a new lib built against 18.04's curl. |
|
Can libgit2 bundle the curl library? |
|
It's unfortunate that OS updates like these break it. |
|
I guess the benefit is that we get security fixes for "free", so bundling is not ideal. |
|
Still, it would be good if it could be more resilient against updates. |
That would be a call I can't make. @ethomson would be the person to ask that. In general, I know that the idea of bundling other libraries is frowned on, especially things that have security concerns, OpenSSL for example. |
|
Another workaround for now would be to make sure libcurl3 is installed. Looks like 18.04 only includes libcurl4 by default. |
This is not likely something that would break because of an update, but a whole new major version of a distro. |
|
In the case libgit2 can't be loaded is it possible to have the task fail with a warning instead of a hard error? I wouldn't have shippable binaries but at least I'd be able to continue coding until the fix was available.
This worries me about. Consider servicing. It's common that we must build old repositories on significantly newer operating systems. Are we putting ourselves in a position that in order to service our binaries we first have to update our toolsets? |
As you mentioned - we wouldn't want to put people in a position where libgit2 was shipping a vulnerable version of OpenSSL. It's not obvious to users that we would be shipping SSL libraries ourselves and that they need to update it. I'm dismayed by this situation, though. We're continuing to bundle more native binaries, increasing the size of the package and the complexity of our native loaders - all to support minor differences in the distributions of OpenSSL. Taking a step back, I see three options:
|
|
@ethomson Option 2 certainly sounds like the best choice to me! Getting rid of any additional native dependencies that libgit2 has drastically simplifies things. |
|
@tmat I won't have time to dig into this any time soon, regrettably. I'm completely booked for the next two weeks. I should have some time after labor day. |
|
I might have some time this weekend to start looking at it. |
|
Thanks! |
|
@tmat Unfortunately, I haven't had time to get to it yet. |
|
@bording Any eta? More and more folks are running into this issue with SourceLink :( |
|
Nothing new to report yet, hopefully soon! |
|
@bording Any updates? It's been a while... |
|
Work has begun! libgit2/libgit2sharp.nativebinaries#77 |
|
Very nice! |
|
@tmat While waiting for the real fix (removing the native dependencies on curl and OpenSSL) to be ready, I've gone ahead and pushed up LibGit2Sharp 0.26.0-preview-0062 that has an |
|
From the 3 options @ethomson listed, is option 1, a |
|
@rvdginste libgit2 no longer takes a dependency on libcurl. The latest 0.26.0-preview packages don't require it. In addition, some work began on option #2 mentioned above, using the .NET HTTP stack: libgit2/libgit2sharp#1618. I'm working on a libgit2 release so I haven't had much time to work on this. Removing networking entirely is not impossible, of course, but has rather limited use. I'd encourage you to try one of the latest LibGit2Sharp package. Producing some bespoke non-networking version is possible, but not particularly satisfying. Most importantly, LibGit2Sharp is chronically underfunded with contributors, so it's unlikely to make any progress in the near future. |
|
@ethomson Thanks for explaining. I will try the binaries of the 0.26.0-preview packages and check whether those work for me. Update: I tried with those binaries, but they also do not work out-of-the-box for me. The RID for my system is "debian-x64". In Microsoft.Build.Tasks.Git this is not provided, and it falls back on the binaries for "linux-x64", which do not work on my system. The binaries for "debian.9-x64" that are provided, do work. Is there a way to override the to-be-used RID? |
|
I had this same issue on Ubuntu 18 LTS with 2.2;
(mentioned above) fixed it for now. |
|
Source Link does no longer depend on a native library, so this shouldn't be a problem anymore. |
tmat
added
the
Resolution-Fixed
* See: dotnet/roslyn#29289
- Was causing issues building on ubuntu 18.04 dotnet/roslyn#29289
When I attempt to execute the build scripts which publish, as does test.sh, I get the following error
Repro Steps:
./build.sh --restore --build --testCC @tmat
The text was updated successfully, but these errors were encountered: