Failed to initialize CoreCLR, HRESULT: 0x80131500 #2018

Closed
murali2020kris opened this Issue Mar 23, 2016 · 70 comments

Comments

Projects
None yet
@murali2020kris

Steps to reproduce

  1. Download https://dotnetcli.blob.core.windows.net/dotnet/beta/Binaries/Latest/dotnet-dev-centos-x64.latest.tar.gz
  2. Unpack tar file
  3. Set DOTNET_HOME as unzipped folder. [usr/share/dotnet]
  4. Change permission settings for unzipped folder dotnet
  5. run dotnet -version

Expected behavior

Should give version number

Actual behavior

Gives error message Failed to initialize
Failed to initialize CoreCLR, HRESULT: 0x80131500

Environment data

dotnet --version output:
Failed to initialize CoreCLR, HRESULT: 0x80131500

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Mar 24, 2016

Contributor

Have you installed dependent packages like icu and libunwind?

Contributor

ellismg commented Mar 24, 2016

Have you installed dependent packages like icu and libunwind?

@murali2020kris

This comment has been minimized.

Show comment
Hide comment
@murali2020kris

murali2020kris Mar 24, 2016

@ellismg Thank you so much. icu was missing. It works now.

@ellismg Thank you so much. icu was missing. It works now.

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Mar 24, 2016

Contributor

Glad to hear it!

Contributor

ellismg commented Mar 24, 2016

Glad to hear it!

@ellismg ellismg closed this Mar 24, 2016

@Bundas

This comment has been minimized.

Show comment
Hide comment
@Bundas

Bundas May 17, 2016

Hey, I have the same error. I have icu and libundwind installed. What else could be the problem?

I am running Ubuntu 16.04 @ellismg @murali2020kris

Bundas commented May 17, 2016

Hey, I have the same error. I have icu and libundwind installed. What else could be the problem?

I am running Ubuntu 16.04 @ellismg @murali2020kris

@decompiled

This comment has been minimized.

Show comment
Hide comment
@decompiled

decompiled May 18, 2016

@Bundas I am also having the same issue with 16.04 with icu and libundwind.

@Bundas I am also having the same issue with 16.04 with icu and libundwind.

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg May 18, 2016

Contributor

Support for 16.04 will come at RTM.

Contributor

ellismg commented May 18, 2016

Support for 16.04 will come at RTM.

@vstoykov

This comment has been minimized.

Show comment
Hide comment
@vstoykov

vstoykov May 19, 2016

I also has the same problem. I'm trying it on Fedora 23 (downloaded Centos binaries).

I know that Fedora is not listed in supported distributions but I just wanted to try. Probably the reason for error is the same as for Ubuntu 16.04 (version of the icu is newer in Fedora 23 and Ubuntu 16.04, compared to Debian 8, CentOS 7 and Ubuntu 14.04)

I also has the same problem. I'm trying it on Fedora 23 (downloaded Centos binaries).

I know that Fedora is not listed in supported distributions but I just wanted to try. Probably the reason for error is the same as for Ubuntu 16.04 (version of the icu is newer in Fedora 23 and Ubuntu 16.04, compared to Debian 8, CentOS 7 and Ubuntu 14.04)

@robert-sandor

This comment has been minimized.

Show comment
Hide comment
@robert-sandor

robert-sandor May 25, 2016

For Ubuntu 16.04, installing libicu52 from trusty-security seems to fix the problem.

For Ubuntu 16.04, installing libicu52 from trusty-security seems to fix the problem.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 19, 2016

For Fedora you can copy necessary libs from: ftp://195.220.108.108/linux/centos/7.2.1511/os/x86_64/Packages/libicu-50.1.2-15.el7.x86_64.rpm package to your /lib/lib64

ghost commented Jun 19, 2016

For Fedora you can copy necessary libs from: ftp://195.220.108.108/linux/centos/7.2.1511/os/x86_64/Packages/libicu-50.1.2-15.el7.x86_64.rpm package to your /lib/lib64

@capote

This comment has been minimized.

Show comment
Hide comment
@capote

capote Jun 27, 2016

Any ideas for this in OpenSUSE Leap? I've installed the package icu and libicu52_1 and get this same issue.

capote commented Jun 27, 2016

Any ideas for this in OpenSUSE Leap? I've installed the package icu and libicu52_1 and get this same issue.

@icebreaker

This comment has been minimized.

Show comment
Hide comment
@icebreaker

icebreaker Jun 27, 2016

You can find out what is missing by running:

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'

Replace /opt/dotnet with the directory you "un-tarred" the tar ball to.

You can find out what is missing by running:

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'

Replace /opt/dotnet with the directory you "un-tarred" the tar ball to.

@capote

This comment has been minimized.

Show comment
Hide comment
@capote

capote Jun 27, 2016

Thanks @icebreaker

It appears I'm still missing libicu53 (seems unavailable for Leap, though I have libicu52) and liblldb.so.3.5.0 (I have 3.7.0 installed)

Are these particular versions required?

capote commented Jun 27, 2016

Thanks @icebreaker

It appears I'm still missing libicu53 (seems unavailable for Leap, though I have libicu52) and liblldb.so.3.5.0 (I have 3.7.0 installed)

Are these particular versions required?

@kamathba

This comment has been minimized.

Show comment
Hide comment
@kamathba

kamathba Jun 27, 2016

Same problem on Fedora 24, with the following library versions:
libunwind-1.1-11.fc24.x86_64
libicu-56.1-4.fc24.x86_64

Same problem on Fedora 24, with the following library versions:
libunwind-1.1-11.fc24.x86_64
libicu-56.1-4.fc24.x86_64

@capric8416

This comment has been minimized.

Show comment
Hide comment
@capric8416

capric8416 Jun 28, 2016

openSUSE Tumbleweed:
sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
liblldb.so.3.5.0 => not found # liblldb.so.3.8 found
libicuuc.so.53.1 => not found # libicuuc.so.57.1 found
libicui18n.so.53.1 => not found # libicui18n.so.57.1 found
liblttng-ust.so.0 => not found # not found

openSUSE Tumbleweed:
sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
liblldb.so.3.5.0 => not found # liblldb.so.3.8 found
libicuuc.so.53.1 => not found # libicuuc.so.57.1 found
libicui18n.so.53.1 => not found # libicui18n.so.57.1 found
liblttng-ust.so.0 => not found # not found

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 28, 2016

kamathba, on fedora 24 you need libicu from fedora 23. Try that package: mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm

ghost commented Jun 28, 2016

kamathba, on fedora 24 you need libicu from fedora 23. Try that package: mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm

@3rdey3

This comment has been minimized.

Show comment
Hide comment
@3rdey3

3rdey3 Jun 28, 2016

Arch Linux

$ sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
/opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so)
    libicuuc.so.52 => not found
    libicui18n.so.52 => not found
    liblldb-3.6.so => not found
    liblttng-ust.so.0 => not found

$ pacman -Q icu libunwind curl 
icu 57.1-1
libunwind 1.1-3
curl 7.49.1-1

3rdey3 commented Jun 28, 2016

Arch Linux

$ sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
/opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so)
    libicuuc.so.52 => not found
    libicui18n.so.52 => not found
    liblldb-3.6.so => not found
    liblttng-ust.so.0 => not found

$ pacman -Q icu libunwind curl 
icu 57.1-1
libunwind 1.1-3
curl 7.49.1-1

@capote

This comment has been minimized.

Show comment
Hide comment
@capote

capote Jun 28, 2016

Okay, I don't think it's so productive if we all just post our missing dependencies here. We need to find out if they require those particular versions for every distribution, or if a specific version per distribution is needed, or if it simply doesn't work on some distributions (I don't think I've seen a successful OpenSUSE or Arch install yet). Any ideas?

capote commented Jun 28, 2016

Okay, I don't think it's so productive if we all just post our missing dependencies here. We need to find out if they require those particular versions for every distribution, or if a specific version per distribution is needed, or if it simply doesn't work on some distributions (I don't think I've seen a successful OpenSUSE or Arch install yet). Any ideas?

@watzon

This comment has been minimized.

Show comment
Hide comment
@watzon

watzon Jun 28, 2016

Had the same problem running Kali linux. Turned out that I had a newer version of libicu and libicu-dev installed (v55 I believe) and dotnet wanted version 52. All I had to do was go to the debian repos and find libicu52 and libicu52-dev and install them

watzon commented Jun 28, 2016

Had the same problem running Kali linux. Turned out that I had a newer version of libicu and libicu-dev installed (v55 I believe) and dotnet wanted version 52. All I had to do was go to the debian repos and find libicu52 and libicu52-dev and install them

@vanthome

This comment has been minimized.

Show comment
Hide comment
@vanthome

vanthome Jun 29, 2016

Gentoo User here. I have 57.1 of libicu installed. @iDev0urer did downgrading to 55.x help in your case?

Gentoo User here. I have 57.1 of libicu installed. @iDev0urer did downgrading to 55.x help in your case?

@heavendragon

This comment has been minimized.

Show comment
Hide comment
@heavendragon

heavendragon Jun 29, 2016

Opensuse 42.1 finally success after install libicu from this https://software.opensuse.org/package/libicu53_1
but still failed to initialize code, error "Segmentation fault" during dotnet new, dotnet restore(Opensuse 42.1, kernel 4.6.x)
No problem on kernel 4.1.21-14-default

heavendragon commented Jun 29, 2016

Opensuse 42.1 finally success after install libicu from this https://software.opensuse.org/package/libicu53_1
but still failed to initialize code, error "Segmentation fault" during dotnet new, dotnet restore(Opensuse 42.1, kernel 4.6.x)
No problem on kernel 4.1.21-14-default

@capote

This comment has been minimized.

Show comment
Hide comment
@capote

capote Jun 29, 2016

@heavendragon Interesting; I installed the rpm from that link (and its one dependency for which it asked) and it runs fine for me. dotnet new, restore, and run all worked as expected. Getting into this some more tomorrow.

(also on Opensuse 42.1, much earlier kernel though)

capote commented Jun 29, 2016

@heavendragon Interesting; I installed the rpm from that link (and its one dependency for which it asked) and it runs fine for me. dotnet new, restore, and run all worked as expected. Getting into this some more tomorrow.

(also on Opensuse 42.1, much earlier kernel though)

@watzon

This comment has been minimized.

Show comment
Hide comment
@watzon

watzon Jun 29, 2016

@vanthome I downgraded to v52 and now it works. At the very least I'm not getting that error when typing dotnet --help and dotnet --version anymore. I haven't tried doing anything else with it yet

watzon commented Jun 29, 2016

@vanthome I downgraded to v52 and now it works. At the very least I'm not getting that error when typing dotnet --help and dotnet --version anymore. I haven't tried doing anything else with it yet

@tgoncuoglu

This comment has been minimized.

Show comment
Hide comment
@tgoncuoglu

tgoncuoglu Jun 30, 2016

here are some specifics: OS is Fedora 24 with libunwind/libicu installed (f24 has icu at version 56.1 and libunwind at version 1.11). I'm getting above mentioned error. Downgrading to f23 libicu is not an option because of dependencies involved: qt5-qtbase, among others. No can do. So in the end, it seems dotnet requires a specific icu version, ie v52.

here are some specifics: OS is Fedora 24 with libunwind/libicu installed (f24 has icu at version 56.1 and libunwind at version 1.11). I'm getting above mentioned error. Downgrading to f23 libicu is not an option because of dependencies involved: qt5-qtbase, among others. No can do. So in the end, it seems dotnet requires a specific icu version, ie v52.

@kamathba

This comment has been minimized.

Show comment
Hide comment
@kamathba

kamathba Jun 30, 2016

I was able to get it working on Fedora 24 by building/installing libicu v52 from source and installing liblldb /libunwind using yum

I was able to get it working on Fedora 24 by building/installing libicu v52 from source and installing liblldb /libunwind using yum

@sphildreth

This comment has been minimized.

Show comment
Hide comment
@sphildreth

sphildreth Jul 2, 2016

On Fedora 24 I installed ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm and "dotnet -version" worked.

On Fedora 24 I installed ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm and "dotnet -version" worked.

@mickaelistria

This comment has been minimized.

Show comment
Hide comment
@mickaelistria

mickaelistria Jul 20, 2016

Another way to get it running on Fedora 24 and other distros using too recent ICU (provided to me by @scela)

  1. download libicu-54.1-5.fc23.x86_64.rpm from wherver ( eg http://mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm )
  2. open it with archive manager, go to ./usr/lib64 and extract all the .so files to ~/oldicu
  3. now execute: LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet instead of invoking directly dotnet.

This has the advantage of not forcing installation of older icu (which can lead to other issues for package requiring newer icu). Also I imagine this would work with any Linux distribution facing this issue. You can also tweak your .bashrc to define alias dotnet=LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet, but since alias aren't inherited, it's not working when running scripts, so one had to use source script.sh instead of ./script.sh if they want to take advantage of their alias.

Another way to get it running on Fedora 24 and other distros using too recent ICU (provided to me by @scela)

  1. download libicu-54.1-5.fc23.x86_64.rpm from wherver ( eg http://mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm )
  2. open it with archive manager, go to ./usr/lib64 and extract all the .so files to ~/oldicu
  3. now execute: LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet instead of invoking directly dotnet.

This has the advantage of not forcing installation of older icu (which can lead to other issues for package requiring newer icu). Also I imagine this would work with any Linux distribution facing this issue. You can also tweak your .bashrc to define alias dotnet=LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet, but since alias aren't inherited, it's not working when running scripts, so one had to use source script.sh instead of ./script.sh if they want to take advantage of their alias.

@mrmeek

This comment has been minimized.

Show comment
Hide comment
@mrmeek

mrmeek Jul 20, 2016

I was able to dotnet new, restore, and run on OpenSUSE 42.1 by downloading and installing the dependency for libicu53_1: https://software.opensuse.org/package/libicu53_1-ledata (this just copies libicudt531.dat to/usr/share/icu/53.1), and using the technique mickaelistria described such that I can leave the default 52_1 install alone. Thanks mickaelistria!

BTW, Kernel v4.1.20-11-default

mrmeek commented Jul 20, 2016

I was able to dotnet new, restore, and run on OpenSUSE 42.1 by downloading and installing the dependency for libicu53_1: https://software.opensuse.org/package/libicu53_1-ledata (this just copies libicudt531.dat to/usr/share/icu/53.1), and using the technique mickaelistria described such that I can leave the default 52_1 install alone. Thanks mickaelistria!

BTW, Kernel v4.1.20-11-default

@molaie

This comment has been minimized.

Show comment
Hide comment
@molaie

molaie Aug 11, 2016

for debian stretch users, there is more than just libicu52.
I added this line to sources.list (/etc/apt/sources.list)
deb http://ftp.de.debian.org/debian/ jessie main
then :
apt-get update
finally:
apt-get -t jessie install libicu52
apt-get install libssl1.0.0
in this point, the command by @icebreaker gives this output:

    root@yspdebian:~# find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'`

    liblldb-3.6.so => not found

    liblttng-ust.so.0 => not found

finally, work is done by :
apt-get install liblttng-ust0 and apt-get install liblldb-3.6

and now, i have this error:

ahmad@yspdebian:~/oldicu$ dotnet new
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4369 ms
Expanding 0%Segmentation fault

version is:

ahmad@yspdebian:~/oldicu$ dotnet --version
1.0.0-preview2-003121

and

ahmad@yspdebian:~/oldicu$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     debian
 OS Version:  
 OS Platform: Linux
 RID:         debian.-x64

molaie commented Aug 11, 2016

for debian stretch users, there is more than just libicu52.
I added this line to sources.list (/etc/apt/sources.list)
deb http://ftp.de.debian.org/debian/ jessie main
then :
apt-get update
finally:
apt-get -t jessie install libicu52
apt-get install libssl1.0.0
in this point, the command by @icebreaker gives this output:

    root@yspdebian:~# find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'`

    liblldb-3.6.so => not found

    liblttng-ust.so.0 => not found

finally, work is done by :
apt-get install liblttng-ust0 and apt-get install liblldb-3.6

and now, i have this error:

ahmad@yspdebian:~/oldicu$ dotnet new
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4369 ms
Expanding 0%Segmentation fault

version is:

ahmad@yspdebian:~/oldicu$ dotnet --version
1.0.0-preview2-003121

and

ahmad@yspdebian:~/oldicu$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     debian
 OS Version:  
 OS Platform: Linux
 RID:         debian.-x64

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Aug 11, 2016

Contributor

There was a bug in 1.0.0 that manifested itself in this way on newer kernels (IIRC it was 4.6.0+) . We fixed the bug see (dotnet/coreclr#6027) but I don't think the fix has flowed to any of the binary packages.

We will release this fix as part of a 1.0.1 release, but we don't know the exact date of that release yet. If you want to try the following, it should probably address your issue.

  1. Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.debian.8-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4
  2. Unzip it to some folder (otherwise it will litter files over whatever folder you extract it in).
  3. copy all the files in runtimes/debian.8-x64/native/ to /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/ (replacing the versions that already exist there).

Give it another whirl after this.

Contributor

ellismg commented Aug 11, 2016

There was a bug in 1.0.0 that manifested itself in this way on newer kernels (IIRC it was 4.6.0+) . We fixed the bug see (dotnet/coreclr#6027) but I don't think the fix has flowed to any of the binary packages.

We will release this fix as part of a 1.0.1 release, but we don't know the exact date of that release yet. If you want to try the following, it should probably address your issue.

  1. Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.debian.8-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4
  2. Unzip it to some folder (otherwise it will litter files over whatever folder you extract it in).
  3. copy all the files in runtimes/debian.8-x64/native/ to /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/ (replacing the versions that already exist there).

Give it another whirl after this.

@molaie

This comment has been minimized.

Show comment
Hide comment
@molaie

molaie Aug 12, 2016

dotnet new is done, but this time, i have error in dotnet restore.
for the first time it does the job, but then in dotnet run, i have segfault.
and now, both of them ( restore and run ) gave segfault.

molaie commented Aug 12, 2016

dotnet new is done, but this time, i have error in dotnet restore.
for the first time it does the job, but then in dotnet run, i have segfault.
and now, both of them ( restore and run ) gave segfault.

@brandon-arnold brandon-arnold referenced this issue in PowerShell/PowerShell Aug 19, 2016

Open

Fedora RPM #1882

@cgountanis

This comment has been minimized.

Show comment
Hide comment
@cgountanis

cgountanis Aug 23, 2016

Followed instructions for openSUSE (although looks like leap is newer than instuctions) and I get the same error Failed to initialize CoreCLR, HRESULT: 0x80131500 even when doing --version. Can the instructions be updated, not really going to spend time trying a million different options.

cgountanis commented Aug 23, 2016

Followed instructions for openSUSE (although looks like leap is newer than instuctions) and I get the same error Failed to initialize CoreCLR, HRESULT: 0x80131500 even when doing --version. Can the instructions be updated, not really going to spend time trying a million different options.

@tchaloupka tchaloupka referenced this issue in kostya/benchmarks Aug 24, 2016

Merged

Add .Net Core tests #102

@jamasu

This comment has been minimized.

Show comment
Hide comment
@jamasu

jamasu Sep 1, 2016

mrmeek could you explain how you followed the instructions in detail?
I downloaded and installed libicu53 but still getting the errors. I am using openSuse Leap 42.1

jamasu commented Sep 1, 2016

mrmeek could you explain how you followed the instructions in detail?
I downloaded and installed libicu53 but still getting the errors. I am using openSuse Leap 42.1

@cgountanis

This comment has been minimized.

Show comment
Hide comment
@cgountanis

cgountanis Sep 1, 2016

Personally I just gave up ain't nobody got time for that.

Personally I just gave up ain't nobody got time for that.

@jamasu

This comment has been minimized.

Show comment
Hide comment
@jamasu

jamasu Sep 1, 2016

we just have to wait for a new release with the bugfix i suppose?

jamasu commented Sep 1, 2016

we just have to wait for a new release with the bugfix i suppose?

@jamasu

This comment has been minimized.

Show comment
Hide comment
@jamasu

jamasu Sep 1, 2016

aah, i actually made it work now, just runned sudo zypper remove icu, which removes 52.1 then sudo zypper install icu which installs 53.1 and just like that it works :)

jamasu commented Sep 1, 2016

aah, i actually made it work now, just runned sudo zypper remove icu, which removes 52.1 then sudo zypper install icu which installs 53.1 and just like that it works :)

@cgountanis

This comment has been minimized.

Show comment
Hide comment
@cgountanis

cgountanis Sep 1, 2016

Great news! Thanks for sharing.

Great news! Thanks for sharing.

@EtienneBruines

This comment has been minimized.

Show comment
Hide comment
@EtienneBruines

EtienneBruines Oct 19, 2016

Same goes for Ubuntu 16.10 with libicu52 installed :-(

Same goes for Ubuntu 16.10 with libicu52 installed :-(

@kevcunnane kevcunnane referenced this issue in Microsoft/vscode-mssql Nov 17, 2016

Closed

mssql: SQL Tools Service component could not start #370

@GBatault

This comment has been minimized.

Show comment
Hide comment
@GBatault

GBatault Nov 21, 2016

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

GBatault commented Nov 21, 2016

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

@nibbles-

This comment has been minimized.

Show comment
Hide comment
@nibbles-

nibbles- Nov 22, 2016

Just upgraded to Fedora25 (libicu 57.1) and now it is broken again

Just upgraded to Fedora25 (libicu 57.1) and now it is broken again

@TheRealPiotrP

This comment has been minimized.

Show comment
Hide comment
@TheRealPiotrP

TheRealPiotrP Nov 23, 2016

Collaborator

@DustinCampbell can you comment on

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

@ellismg any updates on this issue? Seems like it's still affecting a bunch of folks...

Collaborator

TheRealPiotrP commented Nov 23, 2016

@DustinCampbell can you comment on

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

@ellismg any updates on this issue? Seems like it's still affecting a bunch of folks...

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Nov 23, 2016

Contributor

any updates on this issue? Seems like it's still affecting a bunch of folks...

We took fixes for vNext (they didn't make it in for 1.1) that should help here. Basically we added a mode where we can compile in a way such that we'll "roll forward" to newer ICUs. I believe the plan is to cut over to that mode as the default before vNext for the binaries that we build and distribute.

In the mean time, you can install an older version of libicu or if it's possible to override the version of the CLI that VSCode uses to use a local copy of .NET Core, we have scripts that will let you rebuild the relevant native components.

When I last looked, it was unclear if VSCode was deploying their stuff as shared framework apps or standalone. Either way, we can do the rebuilds. If VS Code is just using the shared framework, we have scripts now that can automate the rebuilding. If they publish their tools standalone, then folks will have to rebuild "by hand".

There may also be problems with some other native components (specifically Crypto and HTTP) but you hit the ICU issues first, since globalization is used early in app startup.

Contributor

ellismg commented Nov 23, 2016

any updates on this issue? Seems like it's still affecting a bunch of folks...

We took fixes for vNext (they didn't make it in for 1.1) that should help here. Basically we added a mode where we can compile in a way such that we'll "roll forward" to newer ICUs. I believe the plan is to cut over to that mode as the default before vNext for the binaries that we build and distribute.

In the mean time, you can install an older version of libicu or if it's possible to override the version of the CLI that VSCode uses to use a local copy of .NET Core, we have scripts that will let you rebuild the relevant native components.

When I last looked, it was unclear if VSCode was deploying their stuff as shared framework apps or standalone. Either way, we can do the rebuilds. If VS Code is just using the shared framework, we have scripts now that can automate the rebuilding. If they publish their tools standalone, then folks will have to rebuild "by hand".

There may also be problems with some other native components (specifically Crypto and HTTP) but you hit the ICU issues first, since globalization is used early in app startup.

@DustinCampbell

This comment has been minimized.

Show comment
Hide comment
@DustinCampbell

DustinCampbell Nov 23, 2016

Member

@GBatault: If I understand, you have a script that sets LD_LIBRARY_PATH and launches 'dotnet'? If so, putting this script on your path and naming it 'dotnet' should get various commnads in VS Code that depend on the .NET CLI working.

Member

DustinCampbell commented Nov 23, 2016

@GBatault: If I understand, you have a script that sets LD_LIBRARY_PATH and launches 'dotnet'? If so, putting this script on your path and naming it 'dotnet' should get various commnads in VS Code that depend on the .NET CLI working.

@GBatault

This comment has been minimized.

Show comment
Hide comment
@GBatault

GBatault Nov 23, 2016

@DustinCampbell Tanks for the trick : So what I did today : I use my .bashrc to add an alias : dotnet='LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet'

But still the error on launching VS Code :
The .NET CLI tools cannot be located. .NET Core debugging will not be enabled. Make sure .NET CLI tools are installed and are on the path.

GBatault commented Nov 23, 2016

@DustinCampbell Tanks for the trick : So what I did today : I use my .bashrc to add an alias : dotnet='LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet'

But still the error on launching VS Code :
The .NET CLI tools cannot be located. .NET Core debugging will not be enabled. Make sure .NET CLI tools are installed and are on the path.

@DustinCampbell

This comment has been minimized.

Show comment
Hide comment
@DustinCampbell

DustinCampbell Nov 23, 2016

Member

@gregg-miskelly: do you have any ideas?

Member

DustinCampbell commented Nov 23, 2016

@gregg-miskelly: do you have any ideas?

@gregg-miskelly

This comment has been minimized.

Show comment
Hide comment
@gregg-miskelly

gregg-miskelly Nov 24, 2016

@GBatault I don't know enough about how node spawns processes to say for sure if bash aliases will apply or not. Did you try starting VS Code from a bash prompt with the alias set? I would imagine you could at least make a dotnet file which is really a bash script that could work.

For reference, all the debugger does is run dotnet --info (see link).

gregg-miskelly commented Nov 24, 2016

@GBatault I don't know enough about how node spawns processes to say for sure if bash aliases will apply or not. Did you try starting VS Code from a bash prompt with the alias set? I would imagine you could at least make a dotnet file which is really a bash script that could work.

For reference, all the debugger does is run dotnet --info (see link).

@GBatault

This comment has been minimized.

Show comment
Hide comment
@GBatault

GBatault Nov 24, 2016

@gregg-miskelly Tanks, seems to work like this : Create a srcipt shell to launch VS Code with : LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH code

GBatault commented Nov 24, 2016

@gregg-miskelly Tanks, seems to work like this : Create a srcipt shell to launch VS Code with : LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH code

@TheRealPiotrP TheRealPiotrP added this to the Discussion milestone Nov 28, 2016

9034725985 added a commit to kusl/aspnetcore that referenced this issue Jan 15, 2017

add another line for gitlab ci config
dotnet/cli#2018 (comment)

Signed-off-by: kushal <kushaldeveloper@gmail.com>

@volviq volviq referenced this issue Jan 30, 2017

Closed

Build RPMs #4866

@TingluoHuang TingluoHuang referenced this issue in Microsoft/vsts-agent Feb 16, 2017

Closed

Agent fails to configure on Ubuntu 16.10 #797

@tamashiketsu

This comment has been minimized.

Show comment
Hide comment
@tamashiketsu

tamashiketsu Feb 22, 2017

I'm currently struggling with a ICU installation, these libs are missing:

-       liblttng-ust.so.0 => not found
- 	libicuuc.so.50 => not found
- 	libicui18n.so.50 => not found
- 	libcrypto.so.10 => not found
- 	libssl.so.10 => not found
- 	liblldb.so => not found
- 	liblttng-ust.so.0 => not found
- 	libicuuc.so.50 => not found
- 	libicui18n.so.50 => not found
- 	liblldb.so => not found
- 	libcrypto.so.10 => not found
- 	libssl.so.10 => not found

And when I try to install any of them

Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package liblttng-ust.so.0
E: Couldn't find any package by glob 'liblttng-ust.so.0'
E: Couldn't find any package by regex 'liblttng-ust.so.0'

tamashiketsu commented Feb 22, 2017

I'm currently struggling with a ICU installation, these libs are missing:

-       liblttng-ust.so.0 => not found
- 	libicuuc.so.50 => not found
- 	libicui18n.so.50 => not found
- 	libcrypto.so.10 => not found
- 	libssl.so.10 => not found
- 	liblldb.so => not found
- 	liblttng-ust.so.0 => not found
- 	libicuuc.so.50 => not found
- 	libicui18n.so.50 => not found
- 	liblldb.so => not found
- 	libcrypto.so.10 => not found
- 	libssl.so.10 => not found

And when I try to install any of them

Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package liblttng-ust.so.0
E: Couldn't find any package by glob 'liblttng-ust.so.0'
E: Couldn't find any package by regex 'liblttng-ust.so.0'
@pichardoJ

This comment has been minimized.

Show comment
Hide comment
@pichardoJ

pichardoJ Feb 28, 2017

For Fedora 25 I got it working with this new copr repo.

For Fedora 25 I got it working with this new copr repo.

@jp7677 jp7677 referenced this issue in tpokorra/lbs-mono-fedora Mar 27, 2017

Open

MSBuild 15 #22

@acastaner

This comment has been minimized.

Show comment
Hide comment
@acastaner

acastaner Apr 14, 2017

Downloaded version 1.0.4 (also tried with 1.1), followed all the instructions from https://www.microsoft.com/net/core#linuxfedora (although I'm using Fedora 25) and I get the same error:

[acastaner@localhost ~]$ dotnet --version
Failed to initialize CoreCLR, HRESULT: 0x80131500

I'm apparently missing dependencies

[acastaner@localhost ~]$ find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
	libicuuc.so.56 => not found
	libicui18n.so.56 => not found
	liblldb.so.3.8.0 => not found

So it seems that contrary to the statements in this issue the problem seems to still exist? Is there a planned fix rather than the provided workarounds?

acastaner commented Apr 14, 2017

Downloaded version 1.0.4 (also tried with 1.1), followed all the instructions from https://www.microsoft.com/net/core#linuxfedora (although I'm using Fedora 25) and I get the same error:

[acastaner@localhost ~]$ dotnet --version
Failed to initialize CoreCLR, HRESULT: 0x80131500

I'm apparently missing dependencies

[acastaner@localhost ~]$ find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
	libicuuc.so.56 => not found
	libicui18n.so.56 => not found
	liblldb.so.3.8.0 => not found

So it seems that contrary to the statements in this issue the problem seems to still exist? Is there a planned fix rather than the provided workarounds?

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Apr 14, 2017

Contributor

It is fixed in master now, if you download 2.0 nightlies from dotnet/cli things should work.

There are no plans to back port the changes to 1.0 or 1.1.

Contributor

ellismg commented Apr 14, 2017

It is fixed in master now, if you download 2.0 nightlies from dotnet/cli things should work.

There are no plans to back port the changes to 1.0 or 1.1.

@gforceg

This comment has been minimized.

Show comment
Hide comment
@gforceg

gforceg Apr 24, 2017

@ellismg, when does 2.0 drop? I'd like to use a version of the CLI that is recommended for production environments. I'd also like to develop on Fedora 25.

How do I find out where the CLI is looking for these libs? I wonder if I can make a symlink to the (newer) versions I have installed.

gforceg commented Apr 24, 2017

@ellismg, when does 2.0 drop? I'd like to use a version of the CLI that is recommended for production environments. I'd also like to develop on Fedora 25.

How do I find out where the CLI is looking for these libs? I wonder if I can make a symlink to the (newer) versions I have installed.

@gforceg

This comment has been minimized.

Show comment
Hide comment
@gforceg

gforceg Apr 24, 2017

@ellismg, I figured it out. Yay!

Downloaded libicu version 56 for fedora 24 (https://fedora.pkgs.org/24/fedora-x86_64/libicu-56.1-4.fc24.x86_64.rpm.html)

I unzipped the .rpm file and copied the library files into /lib64. All works! I need to learn how to download files w/o installing them via dnf... if that's even a thing. I don't like the idea of downloading the libs from a 3rd party website.

gforceg commented Apr 24, 2017

@ellismg, I figured it out. Yay!

Downloaded libicu version 56 for fedora 24 (https://fedora.pkgs.org/24/fedora-x86_64/libicu-56.1-4.fc24.x86_64.rpm.html)

I unzipped the .rpm file and copied the library files into /lib64. All works! I need to learn how to download files w/o installing them via dnf... if that's even a thing. I don't like the idea of downloading the libs from a 3rd party website.

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Apr 24, 2017

Contributor

@ellismg, when does 2.0 drop? I'd like to use a version of the CLI that is recommended for production environments. I'd also like to develop on Fedora 25.

The Roadmap says Q3 of this year.

How do I find out where the CLI is looking for these libs? I wonder if I can make a symlink to the (newer) versions I have installed.

To answer the question, although I now see you've fixed the issue, CoreCLR just does normal probing like any other application would to find these libraries, so that will usually be configured with ldconfig. The problem with making a symlink (vs downloading the libraries as you did) is that ICU decorates function exports with a version number (so instead of an export named "foo" on ICU 51 and 52 it's named "foo_51" and "foo_52" on the two versions) so you need to install a matching version.

.NET Core 1.1 does support Fedora 24 in production, so that's always an option if you need to stick with Fedora and also want to be in a supported place. I would encourage you to kick the ties on some of the newer 2.0 builds, while we still have time to address any feedback you'll find.

Contributor

ellismg commented Apr 24, 2017

@ellismg, when does 2.0 drop? I'd like to use a version of the CLI that is recommended for production environments. I'd also like to develop on Fedora 25.

The Roadmap says Q3 of this year.

How do I find out where the CLI is looking for these libs? I wonder if I can make a symlink to the (newer) versions I have installed.

To answer the question, although I now see you've fixed the issue, CoreCLR just does normal probing like any other application would to find these libraries, so that will usually be configured with ldconfig. The problem with making a symlink (vs downloading the libraries as you did) is that ICU decorates function exports with a version number (so instead of an export named "foo" on ICU 51 and 52 it's named "foo_51" and "foo_52" on the two versions) so you need to install a matching version.

.NET Core 1.1 does support Fedora 24 in production, so that's always an option if you need to stick with Fedora and also want to be in a supported place. I would encourage you to kick the ties on some of the newer 2.0 builds, while we still have time to address any feedback you'll find.

@knocte

This comment has been minimized.

Show comment
Hide comment
@knocte

knocte May 9, 2017

thanks @mmisztal1980 , that has solved the issue for me in Ubuntu 16.04.

knocte commented May 9, 2017

thanks @mmisztal1980 , that has solved the issue for me in Ubuntu 16.04.

@gideondsouza

This comment has been minimized.

Show comment
Hide comment
@gideondsouza

gideondsouza May 21, 2017

Ok, this still exists for me on Fedora 25. I have libicu and I have libunwind. When I installed them with dnf it says it's already installed.

Any clues or pointers?

Ok, this still exists for me on Fedora 25. I have libicu and I have libunwind. When I installed them with dnf it says it's already installed.

Any clues or pointers?

@mickaelistria

This comment has been minimized.

Show comment
Hide comment
@mickaelistria

mickaelistria May 22, 2017

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg May 22, 2017

Contributor

@gideondsouza Which version of the CLI are you trying to install?

Contributor

ellismg commented May 22, 2017

@gideondsouza Which version of the CLI are you trying to install?

@gforceg

This comment has been minimized.

Show comment
Hide comment
@gforceg

gforceg May 22, 2017

@gideondsouza I'm also running Fedora 25, but I had to install the version of libicu used by Fedora 24 for the CLI to work. (libicu v 56).

gforceg commented May 22, 2017

@gideondsouza I'm also running Fedora 25, but I had to install the version of libicu used by Fedora 24 for the CLI to work. (libicu v 56).

@bernardbr bernardbr referenced this issue in OmniSharp/omnisharp-vscode May 30, 2017

Open

Cannot debug a C# application #1526

@daddykotex

This comment has been minimized.

Show comment
Hide comment
@daddykotex

daddykotex Jun 16, 2017

On Ubuntu 16.04, I had:

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
	libicuuc.so.52 => not found
	libicui18n.so.52 => not found
	liblldb-3.6.so => not found
	libicuuc.so.52 => not found
	libicui18n.so.52 => not found
	liblldb-3.6.so => not found

so I did:

sudo echo "deb http://security.ubuntu.com/ubuntu trusty-security main" >> /etc/apt/sources.list
sudo apt-get update && sudo apt-get install libicu52 liblldb-3.6

And could:

dotnet --info.NET Command Line Tools (1.0.4)

Product Information:
 Version:            1.0.4
 Commit SHA-1 hash:  af1e6684fd

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /opt/dotnet/sdk/1.0.4

daddykotex commented Jun 16, 2017

On Ubuntu 16.04, I had:

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
	libicuuc.so.52 => not found
	libicui18n.so.52 => not found
	liblldb-3.6.so => not found
	libicuuc.so.52 => not found
	libicui18n.so.52 => not found
	liblldb-3.6.so => not found

so I did:

sudo echo "deb http://security.ubuntu.com/ubuntu trusty-security main" >> /etc/apt/sources.list
sudo apt-get update && sudo apt-get install libicu52 liblldb-3.6

And could:

dotnet --info.NET Command Line Tools (1.0.4)

Product Information:
 Version:            1.0.4
 Commit SHA-1 hash:  af1e6684fd

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /opt/dotnet/sdk/1.0.4

@jleclanche jleclanche referenced this issue in dotnet/core-setup Jul 11, 2017

Closed

Debian stretch packages? #2811

@nitisht nitisht referenced this issue in minio/minio-dotnet Aug 1, 2017

Merged

Modify functional tests for Mint #150

@agrcrobles

This comment has been minimized.

Show comment
Hide comment
@agrcrobles

agrcrobles Aug 8, 2017

On Ubuntu 16.04 I ended up symlinking libicuuc.so.52 libicui18n.so.52 from opt to usr/lib as a workaround, I am still looking for a better way to do it though.

On Ubuntu 16.04 I ended up symlinking libicuuc.so.52 libicui18n.so.52 from opt to usr/lib as a workaround, I am still looking for a better way to do it though.

@sunnystormy

This comment has been minimized.

Show comment
Hide comment
@sunnystormy

sunnystormy Aug 11, 2017

Is there a reason dotnet Core isn't being built with the latest packages from Debian? libicu52 and liblldb-3.6, for example, are several generations behind. I don't want to have to necro old packages just to get this to run.

--EDIT--

Everything works if you download it from the main github page here. It doesn't work if you download it using the commands from the https://www.microsoft.com/net/core#linuxdebian website. Perhaps that should be updated?

sunnystormy commented Aug 11, 2017

Is there a reason dotnet Core isn't being built with the latest packages from Debian? libicu52 and liblldb-3.6, for example, are several generations behind. I don't want to have to necro old packages just to get this to run.

--EDIT--

Everything works if you download it from the main github page here. It doesn't work if you download it using the commands from the https://www.microsoft.com/net/core#linuxdebian website. Perhaps that should be updated?

@knocte

This comment has been minimized.

Show comment
Hide comment
@knocte

knocte Aug 21, 2017

Perhaps that should be updated?

@sunnystormy what should be updated? Maybe you want to create a PR since this issue is marked as closed (not sure why though).

knocte commented Aug 21, 2017

Perhaps that should be updated?

@sunnystormy what should be updated? Maybe you want to create a PR since this issue is marked as closed (not sure why though).

@sunnystormy

This comment has been minimized.

Show comment
Hide comment
@sunnystormy

sunnystormy Aug 21, 2017

@knocte Good point. I'll create a new ticket with the contents of the second part of my post.

@knocte Good point. I'll create a new ticket with the contents of the second part of my post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment