Arch Linux

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Building dotnet with clang 4.0 and associated issues

It was suggested that we move the discussion from the dotnet AUR page to a forum thread, so here's one :-)

Here's again the steps to build I followed:

• Add 'openssl-1.0' to dependencies

• Prepend the corefx build command with:

  • CPLUS_INCLUDE_PATH=/usr/include/openssl-1.0

  • C_INCLUDE_PATH=/usr/include/openssl-1.0

• Append to the corefx build command:

  • cmakeargs -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0

  • cmakeargs -DOPENSSL_SSL_LIBRARY=/usr/lib/openssl-1.0/libssl.so

  • cmakeargs -DOPENSSL_CRYPTO_LIBRARY=/usr/lib/openssl-1.0/libcrypto.so

However, like @optlink and @phib I get a segfault when actually running dotnet.
I haven't had any luck issuing 'export COMPlus_INTERNAL_ThreadSuspendInjection=0' before running dotnet, then it segfaults when running 'dotnet new'.

Last edited by Pezo (2017-05-02 08:09:21)

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

It seems the crash is inside libssl.so.1.0.0, I can only reproduce it some of the time when starting dotnet from Eclipse.

HeresJonny

Member

Registered: 2017-05-02

Posts: 5

Re: Building dotnet with clang 4.0 and associated issues

I think the COMPlus_INTERNAL_ThreadSuspendInjection is a false lead, I compared the fix to the current 1.1.1 code and it already seems to be in place.

Issue: https://github.com/dotnet/coreclr/issues/6016
Fix: https://github.com/dotnet/coreclr/pull/6027/files

I've already torn the package apart getting it to compile with llvm 4.0 and openssl-1.0, so I may try to rebuild the package in debug mode and see if I can get a proper stack trace.

HeresJonny

Member

Registered: 2017-05-02

Posts: 5

Re: Building dotnet with clang 4.0 and associated issues

Also, I came up with a different method for using openssl-1.0:

openssl-10.patch:

--- old/src/Native/Unix/System.Security.Cryptography.Native/CMakeLists.txt      2017-02-22 11:42:11.000000000 -0500
+++ new/src/Native/Unix/System.Security.Cryptography.Native/CMakeLists.txt      2017-05-02 10:21:51.509451435 -0400
@@ -17,6 +17,11 @@
 
 find_package(OpenSSL REQUIRED)
 
+include_directories(
+  SYSTEM
+  ${OPENSSL_INCLUDE_DIR}
+)
+
 set(NATIVECRYPTO_SOURCES
     openssl.c
     pal_asn1.cpp

in PKGBUILD:
add to end of prepare():

  cd "${srcdir}/corefx-${pkgver}"                                                                                                                                                                                      
  patch -p1 < "${srcdir}/openssl-10.patch"

add to beginning of build():

  export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig
  export _OPENSSL_INCLUDEDIR=/usr/include/openssl-1.0/
  export _OPENSSL_LIBDIR=/usr/lib/openssl-1.0/

The exports could also be done with cmakeargs, but using these variables will allow cmake's find_package() to pick up the path of openssl-1.0, and only use the include path where needed.  Actually, I'm not sure if pkg-config is used or not, I just tried that one first.

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

I don't have a whole lot of evidence to go on at the moment but I believe the issue is related to curl. The version of curl on our systems is linked to openssl 1.1 and I remember reading somewhere that passing data structures between the two versions of openssl could cause problems. Linking to a version of curl that is also linked to openssl 1.0 might be something to try.

phib

Member

Registered: 2017-05-02

Posts: 4

Re: Building dotnet with clang 4.0 and associated issues

I could now reproduce what i did different. It was "export DOTNET_CLI_TELEMETRY_OPTOUT=1".

When i opt out of the diagnostics sending to Microsoft, i can create a new console and new mvc app, restore and run. When i OptIn (set it back to 0) it segmentation faults.
But as soon as i want to do something it uses something out of the internet (e.g. restoring a package from NuGet) i get that segmentation fault again.

phil@kif ~/test » export DOTNET_CLI_TELEMETRY_OPTOUT=0            
phil@kif ~/test » dotnet run                          
[1]    18566 segmentation fault (core dumped)  dotnet run
phil@kif ~/test » export DOTNET_CLI_TELEMETRY_OPTOUT=1  
phil@kif ~/test » dotnet run                          
Hello World!
phil@kif ~/test » 

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

Ok so I just tried building with libcurl-openssl-1.0 and appending CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so to the build command with no luck. However, export DOTNET_CLI_TELEMETRY_OPTOUT=1 solved the segfault issue. I'm thinking it's because the dotnet frontend no longer tries to make network requests. dotnet restore and the others still fail silently as before. I'm trying to locate the debug options for the CLI, I've seen them around somewhere before.

HeresJonny

Member

Registered: 2017-05-02

Posts: 5

Re: Building dotnet with clang 4.0 and associated issues

Interestingly, calling dotnet by itself will cause output, but any arguments at all will cause exit code 148.  Something to do with argument parsing maybe?

$ dotnet

Microsoft .NET Core Shared Framework Host

  Version  : 1.1.0
  Build    : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

Usage: dotnet [common-options] [[options] path-to-application]

Common Options:
  --help                           Display .NET Core Shared Framework Host help.
  --version                        Display .NET Core Shared Framework Host version.

Options:
  --fx-version <version>           Version of the installed Shared Framework to use to run the application.
  --additionalprobingpath <path>   Path containing probing policy and assemblies to probe for.

Path to Application:
  The path to a .NET Core managed application, dll or exe file to execute.

If you are debugging the Shared Framework Host, set 'COREHOST_TRACE' to '1' in your environment.

Use dotnet --help to get help with the SDK
$ dotnet --help
$ echo $?
148
$ dotnet --version
$ echo $?
148
$ dotnet restore
$ echo $?
148

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

Those commands all produce some sort of output here. I'm not sure why they're not for you.

HeresJonny

Member

Registered: 2017-05-02

Posts: 5

Re: Building dotnet with clang 4.0 and associated issues

What exit code does your silent-failing dotnet restore give you?

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

139

HeresJonny

Member

Registered: 2017-05-02

Posts: 5

Re: Building dotnet with clang 4.0 and associated issues

Well, I've got it mostly working now!  My first problem was that I assumed that the "dotnet" package was the source-equivalent of the "dotnet-bin" package, which I came from when openssl updated and it stopped working.  I had to install dotnet-cli and dotnet-sdk in order to have a full replacement.  I assume the rest of you are already at that point since your other commands are working.

My next problem was that apparently .NET projects are no longer using project.json and are now using msbuild .csproj files instead.  I had to run "dotnet migrate" before "dotnet restore" would work for my particular project.

I still have the crash with telemetry enabled, and I have a feeling it would crash if nuget had anything to update as well.  But at least restore, publish, and run are working for me now.  I'll keep digging and see if we can get this working the rest of the way.

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

That's good news HeresJonny. But when you say that dotnet restore is working for you do you mean it actually pulls in the packages? I thought it was working for me too but when I deleted ~/.nuget to verify I found that dotnet restore will act like it's working but is actually failing somewhere and not restoring any packages.

I've also been trying to elicit help from the dotnet team here: https://github.com/dotnet/corefx/issues/9855

phib

Member

Registered: 2017-05-02

Posts: 4

Re: Building dotnet with clang 4.0 and associated issues

@optlink how did you manage to build with the old curl version? I tried "CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so" but he still loaded the new ones.

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

@optlink how did you manage to build with the old curl version? I tried "CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so" but he still loaded the new ones.

I already tried the same thing but wasn't successful either.

Maybe this could be hardcoded in the PKGBUILD, since this path will be the same for every Arch install?
Instead of letting CMake search for curl I mean.

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

So, can anyone explain to me why Clang (and GCC) links to `libcurl.so.4` instead of `libcurl-openssl-1.0.so` even if I specify `-lcurl-openssl-1.0` on the command line?

I'm asking because I succeeded in getting CMake to link against `libcurl-openssl-1.0` but Clang seems to ignore that...

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

@optlink how did you manage to build with the old curl version? I tried "CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so" but he still loaded the new ones.

I already tried the same thing but wasn't successful either.

Maybe this could be hardcoded in the PKGBUILD, since this path will be the same for every Arch install?
Instead of letting CMake search for curl I mean.

This is the same behavior I experienced. I've read that cmake is using pkg-config under the hood and this could cause it to override the changes we specify. I guess the next step would be patching the cmake files.

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

This is the same behavior I experienced. I've read that cmake is using pkg-config under the hood and this could cause it to override the changes we specify. I guess the next step would be patching the cmake files.

Did you read my last post? I'm already at having CMake use the right library name when linking, but Clang seems to ignore that and links against `libcurl` anyway...

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

This is the same behavior I experienced. I've read that cmake is using pkg-config under the hood and this could cause it to override the changes we specify. I guess the next step would be patching the cmake files.

Did you read my last post? I'm already at having CMake use the right library name when linking, but Clang seems to ignore that and links against `libcurl` anyway...

I did but I'm not experiencing that issue.

Regardless, I have my build of dotnet working with a relatively simple project. dotnet restore and dotnet build work with results appearing in the bin directory. For some reason I had appended "CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so" when it should have been "cmakeargs -DCURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so". However, running dotnet build on a more complex project with a few dependencies fails to find many of them and errors out. I am not sure if that issue is even related to curl and openssl. I still get segfaults with telemetry enabled though.

phib

Member

Registered: 2017-05-02

Posts: 4

Re: Building dotnet with clang 4.0 and associated issues

Regardless, I have my build of dotnet working with a relatively simple project. dotnet restore and dotnet build work with results appearing in the bin directory. For some reason I had appended "CURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so" when it should have been "cmakeargs -DCURL_LIBRARIES=/usr/lib/libcurl-openssl-1.0.so". However, running dotnet build on a more complex project with a few dependencies fails to find many of them and errors out. I am not sure if that issue is even related to curl and openssl. I still get segfaults with telemetry enabled though.

It is working when he does not have to get something from the internet.
This is working for me:

phil@kif ~/mvc » dotnet new mvc
Content generation time: 280.8045 ms
The template "ASP.NET Core Web App" created successfully.
phil@kif ~/mvc » dotnet restore
  Restoring packages for /home/phil/mvc/mvc.csproj...
  Generating MSBuild file /home/phil/mvc/obj/mvc.csproj.nuget.g.props.
  Generating MSBuild file /home/phil/mvc/obj/mvc.csproj.nuget.g.targets.
  Writing lock file to disk. Path: /home/phil/mvc/obj/project.assets.json
  Restore completed in 1.14 sec for /home/phil/mvc/mvc.csproj.
  
  NuGet Config files used:
      /home/phil/.nuget/NuGet/NuGet.Config
  
  Feeds used:
      https://api.nuget.org/v3/index.json
phil@kif ~/mvc » dotnet run
Hosting environment: Production
Content root path: /home/phil/mvc
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
^CApplication is shutting down...

But as soon as i add some dependency to .csproj which he has to get from the NuGet-Api, it segfaultes. The other dependencys he already got when he extracts on the first run of dotnet. You'll find them all in ~./nuget/packages, thats why its working, he does not get something from the internet.

So i think the issue is still somewhere with curl

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

I did but I'm not experiencing that issue.

Wait, so your `/opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/System.Net.Http.Native.so` links against `libcurl-openssl-1.0.so` and not `libcurl.so`? Then we have yet another problem?

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

I did but I'm not experiencing that issue.

Wait, so your `/opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/System.Net.Http.Native.so` links against `libcurl-openssl-1.0.so` and not `libcurl.so`? Then we have yet another problem?

I checked the result of `ldd /opt/dotnet/shared/Microsoft.NETCore.App/1.1.1/System.Net.Http.Native.so` and no matter what I do I cannot get it to link against anything other than `libcurl.so.4`. Sorry for the confusion there.

I have tried everything from commenting out the relevant sections in `src/Native/Unix/System.Net.Http.Native/CMakeLists.txt` to hard-coding the location in various places. It will either not link to curl at all or to the one mentioned above.

optlink

Member

Registered: 2017-05-02

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

From my cmake output:

-- Found CURL: /usr/lib64/libcurl.so (found version "7.54.0") 
-- Found OpenSSL: /usr/lib/openssl-1.0/libssl.so;/usr/lib/openssl-1.0/libcrypto.so (found version "1.0.2k") 

with this build command:

CPLUS_INCLUDE_PATH=/usr/include/openssl-1.0 C_INCLUDE_PATH=/usr/include/openssl-1.0 ./src/Native/build-native.sh x64 release cmakeargs -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 cmakeargs -DOPENSSL_SSL_LIBRARY=/usr/lib/openssl-1.0/libssl.so cmakeargs -DOPENSSL_CRYPTO_LIBRARY=/usr/lib/openssl-1.0/libcrypto.so cmakeargs -DCURL_LIBRARIES=/usr/lib64/libcurl-openssl-1.0.so

So if OpenSSL is found correctly but not CURL despite the arguments passed it seems it's cmake and not clang that's the issue. Pezo, you said you had cmake finding the correct name already, any pointers?

Pezo

Member

From: Austria

Registered: 2015-04-08

Posts: 14

Re: Building dotnet with clang 4.0 and associated issues

Yeah sure, I patched the CMakeLists file to not search for curl, since CURL_LIBRARIES is the only thing needed. I use the same build command as you.

This is the patch:

diff --git a/src/Native/Unix/System.Net.Http.Native/CMakeLists.txt b/src/Native/Unix/System.Net.Http.Native/CMakeLists.txt
index 515bdb6..c8d3426 100644
--- a/src/Native/Unix/System.Net.Http.Native/CMakeLists.txt
+++ b/src/Native/Unix/System.Net.Http.Native/CMakeLists.txt
@@ -1,9 +1,9 @@
 project(System.Net.Http.Native)
 
-find_package(CURL)
-if(NOT CURL_FOUND)
-    message(FATAL_ERROR "!!! Cannot find libcurl and System.Net.Http.Native cannot build without it. Try installing libcurl4-openssl-dev (or the appropriate package for your platform) !!!")
-endif(NOT CURL_FOUND)
+#find_package(CURL)
+#if(NOT CURL_FOUND)
+#    message(FATAL_ERROR "!!! Cannot find libcurl and System.Net.Http.Native cannot build without it. Try installing libcurl4-openssl-dev (or the appropriate package for your platform) !!!")
+#endif(NOT CURL_FOUND)
 
 if(CMAKE_STATIC_LIB_LINK)
     find_library(CURL_STATIC_LIB NAMES libcurl.a)

BTW, I tried linking the offending SO manually, that's when I saw that neither GCC nor Clang would use the alternate libcurl, but when I don't specify any libcurl then there's some error at runtime.

Last edited by Pezo (2017-05-03 17:35:02)

TioDuke

Member

Registered: 2009-08-06

Posts: 24

Re: Building dotnet with clang 4.0 and associated issues

I managed to get System.Net.Http.Native linked against libcurl-openssl-1.0.

Here"s what I did :

1) I had to change libcurl-openssl-1.0 so that the libraries get installed inside /usr/lib/openssl-1.0 without being renamed :

# Maintainer: Michael Straube <straubem@gmx.de>
# Contributor: Maxime Gauduin <alucryd@archlinux.org>
# Contributor: Piotr Balcerowski <piotr@balcerowski.org>

pkgname=libcurl-openssl-1.0
pkgver=7.54.0
pkgrel=1
pkgdesc='An URL retrieval library (build against openssl-1.0)'
arch=('i686' 'x86_64')
url='https://curl.haxx.se'
license=('MIT')
depends=('curl' 'glibc' 'krb5' 'openssl-1.0' 'libpsl' 'zlib' 'libssh2.so')
options=('strip')
source=("https://curl.haxx.se/download/curl-${pkgver}.tar.gz")
sha256sums=('a84b635941c74e26cce69dd817489bec687eb1f230e7d1897fc5b5f108b59adf')

build() {
  cd curl-${pkgver}

  export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig

  ./configure \
    --prefix='/usr' \
    --disable-ldap \
    --disable-ldaps \
    --disable-manual \
    --enable-ipv6 \
    --enable-threaded-resolver \
    --with-gssapi \
    --with-random='/dev/urandom' \
    --with-ca-bundle='/etc/ssl/certs/ca-certificates.crt' --libdir=/usr/lib/openssl-1.0

  sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
  make -C lib
}

package() {
  cd curl-${pkgver}

  make -C lib DESTDIR="${pkgdir}" install

  rm "${pkgdir}"/usr/lib/openssl-1.0/libcurl.{a,la}

  install -dm 755 "${pkgdir}"/usr/share/licenses
  ln -s curl "${pkgdir}"/usr/share/licenses/${pkgname}
}

2) In dotnet's package, patch CMakeLists file to not search for curl following Pezo's instructions

3) Finally modify ./src/Native/build-native.sh x64 release line to include the following cmake argument:

cmakeargs -DCURL_LIBRARIES=/usr/lib/openssl-1.0/libcurl.so

And it links against libcurl-openssl-1.0. I tested with telemetry on and it seems to work fine. Good luck.

---

[img]http://boincstats.com/signature/-1/user/2670943/sig.png[/img]