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

Linux: corerun can not find libcoreclr.so (undefined symbol CHAIN_SUCCESS_COUNTER) #3901

Closed
piot opened this issue Feb 5, 2015 · 13 comments
Closed

Comments

@piot
Copy link

piot commented Feb 5, 2015

$ ./build.sh

...which builds amd64 debug by default:

$ cd binaries/Product/amd64/debug
$ touch fake_file.txt
$ ./corerun -c . fake_file.txt
dlopen failed to open the libcoreclr.so with error /home/peter/coreclr/binaries/Product/amd64/debug/libcoreclr.so: undefined symbol: CHAIN_SUCCESS_COUNTER  

It produces the same error, even if a valid executable is placed instead of fake_file.txt.

The files libcoreclr.so and libmscordaccore.soare present in the same directory, and should be found by dlopen?

distro: Ubuntu 14.10
clang: 3.5.0-4ubuntu2
gcc: 4.9.1
cmake: 2.8.12.2

@shahid-pk
Copy link
Contributor

just run this...
./corerun fate_file.txt
you should get this error
ExecuteAssembly failed - status: 0x80004005

@janvorli
Copy link
Member

janvorli commented Feb 5, 2015

The dlopen error indicates the libcoreclr.so was not built correctly. The symbol is defined in one of the assembler files and should be defined. I need to figure out what's going on here.
@piot - did you have a chance to try what I've suggested to you in #3868 ?

@piot
Copy link
Author

piot commented Feb 5, 2015

@janvorli I'm testing it now

@shahid-pk
Copy link
Contributor

I can not reproduce this even by using your method. For me the libcoreclr.so does load.
./corerun -c . fate_file.txt
gives me this again which is fine because we do not have mscorlib.dll on unix/linux
ExecuteAssembly failed - status: 0x80004005

not to mention fate_file.txt is not an assembly also but it should at least give you this error.

@piot
Copy link
Author

piot commented Feb 5, 2015

Commencing CoreCLR Repo build
Checking pre-requisites...
Commencing build of native components for amd64/debug
Invoking cmake with arguments: /home/peter/coreclr DEBUG
Detected Linux x86_64
Assembler files: /home/peter/coreclr/src/vm/amd64/jithelpers_fastwritebarriers.S;/home/peter/coreclr/src/vm/amd64/jithelpers_slow.S;/home/peter/coreclr/src/vm/amd64/jithelpers_fast.S;/home/peter/coreclr/src/vm/amd64/getstate.S;/home/peter/coreclr/src/vm/amd64/calldescrworkeramd64.S;/home/peter/coreclr/src/vm/amd64/unixasmhelpers.S;/home/peter/coreclr/src/vm/amd64/theprestubamd64.S;/home/peter/coreclr/src/vm/amd64/virtualcallstubamd64.S

...

No visible warnings or errors.

Install the project...
-- Install configuration: "DEBUG"
-- Installing: /home/peter/coreclr/binaries/Product/amd64/debug/./corerun
-- Installing: /home/peter/coreclr/binaries/Product/amd64/debug/./libmscordaccore.so
-- Installing: /home/peter/coreclr/binaries/Product/amd64/debug/./libcoreclr.so
Repo successfully built.
Product binaries are available at /home/peter/coreclr/binaries/Product/amd64/debug
$ ls -la binaries/Product/amd64/debug/
total 89480
drwxrwxr-x 2 peter peter     4096 Feb  5 22:57 .
drwxrwxr-x 3 peter peter     4096 Feb  5 22:57 ..
-rwxr-xr-x 1 peter peter   107264 Feb  5 21:00 corerun
-rw-r--r-- 1 peter peter 91498872 Feb  5 21:00 libcoreclr.so
-rw-r--r-- 1 peter peter     6408 Feb  5 21:06 libmscordaccore.so

@e00dan
Copy link

e00dan commented Feb 5, 2015

Same here:

[...]
[100%] Built target corerun
Install the project...
-- Install configuration: "DEBUG"
-- Installing: /home/kuzi/clr/coreclr/binaries/Product/amd64/debug/./corerun
-- Installing: /home/kuzi/clr/coreclr/binaries/Product/amd64/debug/./libmscordaccore.so
-- Installing: /home/kuzi/clr/coreclr/binaries/Product/amd64/debug/./libcoreclr.so
Repo successfully built.
Product binaries are available at /home/kuzi/clr/coreclr/binaries/Product/amd64/debug
me:~/clr/coreclr$ ls
all.locproj          clr.native.targets     LICENSE.TXT
binaries             clr.props              NuGet.config
build.cmd            clr.targets            oacr.cfg
build.proj           CMakeLists.txt         partition.settings.targets
build.sh             dac.cmake              PATENTS.TXT
ci.cmd               dac.props              README.md
clr.coreclr.props    dir.props              src
clr.defines.targets  dirs.proj              tests
clr.desktop.props    dir.traversal.targets
me:~/clr/coreclr$ cd binaries
me:~/clr/coreclr/binaries$ ls
CMake  intermediates  Logs  Product
me:~/clr/coreclr/binaries$ cd Product
me:~/clr/coreclr/binaries/Product$ ls
amd64
me:~/clr/coreclr/binaries/Product$ cd a*
me:~/clr/coreclr/binaries/Product/amd64$ ls
debug
me:~/clr/coreclr/binaries/Product/amd64$ cd debug
me:~/clr/coreclr/binaries/Product/amd64/debug$ ls
corerun  libcoreclr.so  libmscordaccore.so
me:~/clr/coreclr/binaries/Product/amd64/debug$ touch fake_file.txt 
me:~/clr/coreclr/binaries/Product/amd64/debug$ ./corerun -c . fake_file.txt
dlopen failed to open the libcoreclr.so with error /home/kuzi/clr/coreclr/binaries/Product/amd64/debug/libcoreclr.so: undefined symbol: CHAIN_SUCCESS_COUNTER
me:~/clr/coreclr/binaries/Product/amd64/debug$ 

Ubuntu 14.10.
clang: Version: 1:3.5-23ubuntu1
gcc: Version: 4:4.9.1-4ubuntu2
cmake: Version: 2.8.12.2-0ubuntu6

@OtherCrashOverride
Copy link

I also get this behavior on Ubuntu 14.10 64bit

The symbol is indeed undefined as shown by readelf command.

readelf -s libcoreclr.so
...
28625: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND CHAIN_SUCCESS_COUNTER

@janvorli
Copy link
Member

janvorli commented Feb 6, 2015

@piot @OtherCrashOverride @kuzirashi Maybe there is a problem with the fact that the CHAIN_SUCCESS_COUNTER is defined in the assembler source this way:
CHAIN_SUCCESS_COUNTER = g_dispatch_cache_chain_success_counter
And later on, it is accessed using PREPARE_EXTERNAL_VAR CHAIN_SUCCESS_COUNTER, rsi
Which adds the @GOTPCREL suffix to the symbol.
Could one of you try to replace the line 13 in the src/vm/virtualcallstubamd64.S file by
#define CHAIN_SUCCESS_COUNTER g_dispatch_cache_chain_success_counter
And see if it fixes the issue for you? Maybe the version of the assembler on your machines treat the symbols defined with = differently.

@OtherCrashOverride
Copy link

I am trying the change in coreclr/src/vm/amd64/virtualcallstubamd64.S (note the different path)

@janvorli
Copy link
Member

janvorli commented Feb 6, 2015

@OtherCrashOverride I am sorry for the wrong path, the one you are using is the right one.

@OtherCrashOverride
Copy link

That appears to correct it: for this test I now get the expected
ExecuteAssembly failed - status: 0x80004005

readelf shows no CHAIN_SUCCESS_COUNTER symbol preset
(note: a clean build was not done in the interest of time)

@janvorli
Copy link
Member

janvorli commented Feb 6, 2015

Great! Thanks a lot for testing it. I will check in the fix in a minute.

@janvorli
Copy link
Member

janvorli commented Feb 6, 2015

@OtherCrashOverride Fix is in as dotnet/coreclr#109

@janvorli janvorli closed this as completed Feb 6, 2015
trylek referenced this issue in trylek/coreclr Sep 22, 2019
I fulltext-searched CoreCLR source code and I have found almost no
conditional checks for Windows. I ended up using _WINNT_
and it seems to work.

Thanks

Tomas
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants