compiling mono 3.10.0 on Centos 6.6 fails - mono

I'm trying to compile a mono release 3.10.0 onto a clean Centos server. I'd rather not try the master, looks like it's build is failing every time I look at it.
So I tried to compile mono like this:
wget https://github.com/mono/mono/archive/mono-3.10.0.tar.gz
tar xvfz mono-3.10.0.tar.gz
cd mono-mono-3.10.0/
./autogen.sh
make get-monolite-latest
This is when I got an error about a missing monolite tarball (more info here: https://bugzilla.xamarin.com/show_bug.cgi?id=16687)
So I found a working url (according to previous link it should work with mono 3.10.0) for one so this is how I continued:
make get-monolite-latest monolite_url=http://storage.bos.xamarin.com/mono-dist-master/1b/1b41fd76350367453c8100f8bd0e7242105c6d39/monolite-111-latest.tar.gz
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/basic.exe
Anyway, this resulted in error:
/usr/local/src/mono-mono-3.10.0/mcs/class/lib/monolite/basic.exe: /usr/local/src/mono-mono-3.10.0/mcs/class/lib/monolite/basic.exe: cannot execute binary file
make[6]: *** [build/deps/basic-profile-check.exe] Error 126
*** The compiler '/usr/local/src/mono-mono-3.10.0/mcs/class/lib/monolite/basic.exe' doesn't appear to be usable.
*** Trying the 'monolite' directory.
Bootstrap compiler: Mono C# compiler version 3.6.1.0
./../jay/jay: 7 shift/reduce conflicts.
mkdir -p -- ../class/lib/basic/
make[7]: *** No rule to make target `../../external/ikvm/reflect/*.cs', needed by `../class/lib/basic/basic.exe'. Stop.
make[6]: *** [do-all] Error 2
make[5]: *** [all-recursive] Error 1
make[4]: *** [profile-do--basic--all] Error 2
make[3]: *** [profiles-do--all] Error 2
make[2]: *** [all-local] Error 2
make[2]: Leaving directory `/usr/local/src/mono-mono-3.10.0/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/mono-mono-3.10.0'
make: *** [all] Error 2
So, why "cannot execute binary file" and what can I do about it? I'm running as root so there shouldn't be any permission issues. Also:
# ls -la /usr/local/src/mono-mono-3.10.0/mcs/class/lib/monolite/
total 8048
drwxr-xr-x 2 root root 4096 Jun 2 2014 .
drwxr-xr-x 3 root root 4096 Jan 9 16:21 ..
-rwxr-xr-x 1 root root 298496 Jun 2 2014 Mono.Security.dll
-rwxr-xr-x 1 root root 126464 Jun 2 2014 System.Configuration.dll
-rwxr-xr-x 1 root root 283136 Jun 2 2014 System.Core.dll
-rwxr-xr-x 1 root root 131072 Jun 2 2014 System.Security.dll
-rwxr-xr-x 1 root root 1291264 Jun 2 2014 System.Xml.dll
-rwxr-xr-x 1 root root 1681408 Jun 2 2014 System.dll
-rwxr-xr-x 1 root root 1743360 Jun 2 2014 basic.exe
-rwxr-xr-x 1 root root 2631168 Jun 2 2014 mscorlib.dll
What's wrong here?
EDIT:
Some progress, I was able to achieve a almost-working mono installation. I needed to do the following steps:
git clone -b mono-3.10.0-branch https://github.com/mono/mono.git
git submodule init
git submodule update
./autogen.sh --with-ikvm-native=no
make get-monolite-latest monolite_url=http://storage.bos.xamarin.com/mono-dist-master/1b/1b41fd76350367453c8100f8bd0e7242105c6d39/monolite-111-latest.tar.gz
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/basic.exe
When cloning a 3.10.0 branch the clone is incomplete, some submodules are missing. You need to run git submodule init and git submodule update to get mono compiling.
These steps had mono compiling and installing without errors, but running .Net software is a whole different matter. I still get exceptions when trying to run my console application:
System.InvalidProgramException: Invalid IL code in System.ComponentModel.Composition.Hosting.DirectoryCatalog:.ctor (string): method body is empty.
Well, the compiling part of the question has been resolved so I guess this can be marked as answered.

Got mono compiling according to my edit in the question. I think I had messed something with either file permissions or the basic.exe had not been there in the first place.
The steps I gave in my edit got my installation working.

Related

CMake: Not to use /usr/lib64/libXmu.so

I am new to CMake and Geant4. I am trying to build a project using them.
Also, I am working in a remote cluster. When I cmake, there's no error. But when I do make the error I am getting is,
make[2]: *** No rule to make target '/usr/lib64/libXmu.so', needed by 'PRO_simulation'. Stop.
make[1]: *** [CMakeFiles/PRO_simulation.dir/all] Error 2
make: *** [all] Error 2
however,
ls -rt /usr/lib64/libXmu*
gives:
lrwxrwxrwx. 1 root root 15 Jan 11 2016 /usr/lib64/libXmu.so.6 -> libXmu.so.6.2.0
-rwxr-xr-x. 1 root root 109552 Nov 20 2015 /usr/lib64/libXmu.so.6.2.0
lrwxrwxrwx. 1 root root 16 Jan 11 2016 /usr/lib64/libXmuu.so.1 -> libXmuu.so.1.0.0
-rwxr-xr-x. 1 root root 19440 Nov 20 2015 /usr/lib64/libXmuu.so.1.0.0
Since its a remote cluster I cannot do a link with the name "libXmu.so" (After requesting the cluster authorities, still there's no use), but I can do the link to my local directory.
Now my question is what should I do in cmake such that, it will look for libXmu.so in my local directory instead of /usr/lib64/libXmu.so
First of all, this is a hack and by no means a proper solution, but you can link directly to a .so file: Link .so file to .cpp file via g++ compiling
Open CMakeLists.txt and remove all references to libXmu linking in target_link_libraries for all targets.
Add /home/user/path/to/libXmu.so to the cmake CXX or link flags. More information on how to do that can be found in: How do I add a linker or compile flag in a CMake file? or: Set CFLAGS and CXXFLAGS options using CMake
I would recommend that you first try something such as:
export CFLAGS=/home/user/path/to/libXmu.so
export CXXFLAGS=/home/user/path/to/libXmu.so
Before running cmake. If this fails, open CMakeLists.txt and try to find where extra CFLAGS and CXXFLAGS are defined and add the path to libXmu.so
Another thing that you can do is you can run make VERBOSE=1, which will show you the exact gcc/g++ command issued, copy it in a text editor and replace -lxmu with /home/user/path/to/libXmu.so
I hope at least one of those works.

Can not link libuuid when using CMake toolchain file to cross-compile Azure IoTHub SDK

I don't know how to write CMake toolchain-file properly to build Azure IoTHub SDK v1.2.10 successfully.
This is my command:
azure-iot-sdk-c/build_all/linux# ./build.sh --no-amqp --no-http --no_uploadtoblob --no-logging --toolchain-file mytoolchain.cmake
And here is the build result, ld cannot find -luuid:
Scanning dependencies of target iothub_convenience_sample
[ 69%] Building C object iothub_client/samples/iothub_convenience_sample/CMakeFiles/iothub_convenience_sample.dir/iothub_convenience_sample.c.o
[ 70%] Building C object iothub_client/samples/iothub_convenience_sample/CMakeFiles/iothub_convenience_sample.dir/__/__/__/certs/certs.c.o
[ 71%] Linking C executable iothub_convenience_sample
/usr/local/bin/compile_tool/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -luuid
collect2: ld returned 1 exit status
iothub_client/samples/iothub_convenience_sample/CMakeFiles/iothub_convenience_sample.dir/build.make:128: recipe for target 'iothub_client/samples/iothub_convenience_sample/iothub_convenience_sample' failed
make[2]: *** [iothub_client/samples/iothub_convenience_sample/iothub_convenience_sample] Error 1
CMakeFiles/Makefile2:1327: recipe for target 'iothub_client/samples/iothub_convenience_sample/CMakeFiles/iothub_convenience_sample.dir/all' failed
make[1]: *** [iothub_client/samples/iothub_convenience_sample/CMakeFiles/iothub_convenience_sample.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Below is my toolchain-file:
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER /usr/local/bin/compile_tool/arm-2010q1/bin/arm-none-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER /usr/local/bin/compile_tool/arm-2010q1/bin/arm-none-linux-gnueabi-g++)
# set OpenSSL path
SET(OPENSSL_SSL_LIBRARY /myspace/application/openssl/libssl.so)
SET(OPENSSL_CRYPTO_LIBRARY /myspace/application/openssl/libcrypto.so)
SET(OPENSSL_INCLUDE_DIR /myspace/application/openssl/include)
# I can use INCLUDE_DIRECTORIES to find uuid.h
INCLUDE_DIRECTORIES(/myspace/application/libuuid/include)
# But I can't link libuuid by setting CMAKE_FIND_ROOT_PATH... Why?
SET(CMAKE_FIND_ROOT_PATH /myspace/application/libuuid/lib)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
I've downloaded libuuid sources and built it into /myspace/application/libuuid/lib/:
root#my-pc:/myspace/application/libuuid/lib# ls -l
total 116
-rw-r--r-- 1 root root 63258 十一 9 13:57 libuuid.a
-rwxr-xr-x 1 root root 953 十一 9 13:57 libuuid.la
lrwxrwxrwx 1 root root 16 十一 9 13:57 libuuid.so -> libuuid.so.1.0.0
lrwxrwxrwx 1 root root 16 十一 9 13:57 libuuid.so.1 -> libuuid.so.1.0.0
-rwxr-xr-x 1 root root 41893 十一 9 13:57 libuuid.so.1.0.0
drwxr-xr-x 2 root root 4096 十一 9 13:57 pkgconfig
However, if I manually copy libuuid.so.1 and libuuid.so.1.0.0 to the path within my cross-compiler(/usr/local/bin/compile_tool/arm-2010q1/arm-none-linux-gnueabi/lib), it can successfully link libuuid.
So, I think there must be something wrong in my toolchain-file. I've tried to use CMAKE_EXE_LINKER_FLAGS, CMAKE_SHARED_LINKER_FLAGS, link_directories, and link_libraries, all of above failed.
I hope somebody can teach me how to improve my toolchain-file. Thanks!
PS. I don't want to modify Azure IoTHub sources in order to keep it unchanged and easy to maintain.
I have installed compiled libuuid library in cross compiler default path. I use aarch64-linux-gnu so default path will be /usr/aarch64-linux-gnu/

LLVm clang , Error: Invalid file format (bad magic) with -fprofile-instr-use

Flag "-fprofile-instr-use" generates error given below.
This issue occurs even if we build llvm,clang and compiler-rt using cmake or configure.
Please let me know your inputs to resolve this issue
error: Could not read profile: Invalid file format (bad magic)
Thanks,
Steps to reproduce this issue:
$ clang -O2 -fprofile-instr-generate hello.c -o c1.out
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
$ ./c1.out
Hello world
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
-rw-r--r-- 1 root root 104 Jul 11 10:10 default.profraw
$ clang -O2 -fprofile-instr-use=default.profraw hello.c -o c2.out
error: Could not read profile: Invalid file format (bad magic)
1 error generated.
Clang version (July 10th-2014 build from stage):
$ clang -v
clang version 3.5.0 (llvm.org/git/clang.git 5f9d646cba20f309bb69c6c358996d71912c54cd) (llvm.org/git/llvm.git dc90a3ab8ffc841a442888940635306de6131d2f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;#m64
Candidate multilib: 32;#m32
Selected multilib: .;#m64
OS: Ubuntu 14.04
LLVM configure: ../llvm/configure --enable-profiling --enable-optimized --enable-shared --disable-debug-runtime --enable-targets=x86
It turns out that step 3 outlined here: http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
is required even if you only have 1 output file you are using. "Combine profiles from multiple runs and convert the “raw” profile format to the input expected by clang" makes it sound like you should only do this if you have multiple profiles, but you need to do it unconditionally.

libcurl Invalid ELF header in new Arch Install

So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.

keyctl commands throw 'undefined symbol: dlopen' errors

I am running Centos 5.8 on a production server. I have an application that needs to use the keyctl command, but everytime the app calls (or I call) the command, I have some errors.
The first error was this:
root#server [~] keyctl show
segmentation fault
Then, I re-installed the keyutils binaries using yum. These are the keyutils packages I have on the server:
root#server [~]# rpm -qa | grep keyutils
keyutils-libs-1.2-1.el5
keyutils-libs-1.2-1.el5
keyutils-1.2-1.el5
keyutils-libs-devel-1.2-1.el5
And now, I have another different error:
root#server [~]# keyctl show
keyctl: symbol lookup error: /lib64/libkeyutils.so.1: undefined symbol: dlopen
I checked the libraries of keyctl, and libdl is not there.
root#server [~]# ldd /bin/keyctl
linux-vdso.so.1 => (0x00007fffcc5fd000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000033df000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d7ae00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d7aa00000)
All libraries that uses are fine.
root#server [~]# ls -al /lib64/libkeyutils*
-rwxr-xr-x 1 root root 9472 Jan 6 2007 /lib64/libkeyutils-1.2.so*
lrwxrwxrwx 1 root root 18 Nov 21 07:56 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.9*
-rwxr-xr-x 1 root root 34584 Jan 6 2007 /lib64/libkeyutils.so.1.9*
root#server [~]# ls -al /lib64/libdl*
-rwxr-xr-x 1 root root 23360 Aug 27 08:59 /lib64/libdl-2.5.so*
lrwxrwxrwx 1 root root 12 Nov 16 02:01 /lib64/libdl.so.2 -> libdl-2.5.so*
root#server [~]#
Have you ever seen this problem before? I tried run the same version on others distros and it works.
I would like to re-install this server, but I can't because it is a production server.
Is there a way I can add or link a shared library to a binary already linked to others .so libraries?
Look at: http://blog.solidshellsecurity.com/2013/02/08/sshd-spam-rootkit-lib64libkeyutils-so-1-9/
It appears that there is no such legitimate file as libkeyutils.so.1.9
It is a rootkit, the latest legitimate version of this library is libkeyutils.so.1.3 on CentOS 6.3 (final).
rm -f /lib64/libkeyutils.so.1.9
ldconfig
/etc/init.d/sshd restart
There's also a suspected (as of now) unpatched user escalation priviledge flaw in all CentOS and RedHat kernels: https://access.redhat.com/security/cve/CVE-2013-0871 and http://blog.configserver.com/index.php?itemid=716
You may also need to reinstall SSH:
https://serverfault.com/questions/476954/remove-shared-library-from-sshd
https://forums.cpanel.net/f185/sshd-rootkit-323962.html
LD_PRELOAD=/lib64/libdl-2.5.so keyctl show