Description
Rust Generated code worked on CentOS but but *fail on VMware Esxi hypervisor.
Some of the code portion does work on the same machine. explained in detail below.
c and rust libc works fine while rust std::fs panicked at 'Unable to open' "Function not implemented".
//rust libc
unsafe {
let fd = libc::open(filename.as_ptr(), libc::O_RDONLY);
let mut fp = libc::fopen(filename.as_ptr(), r.as_ptr());
libc::fgets(buff.as_mut_ptr(), 255, fp);
//println!("{}", str::from_utf8(buff).unwrap());
// println!("{:?}", &buff[..]); // this works
libc::printf(buff[..].as_ptr() as *const i8);
//let s = CString::new(buff.as_ptr()).expect("Invalid name");
//libc::printf(b"2: %s\n", buff.as_ptr() as *const i8 );
//libc::printf("%s\n", buff);
libc::close(fd);
}// c code
#include <stdio.h>
main() {
FILE *fp;
char buff[255];
fp = fopen("/var/log/vmkernel.log", "r");
fscanf(fp, "%s", buff);
printf("1 : %s\n", buff );
fgets(buff, 255, (FILE*)fp);
printf("2: %s\n", buff );
fgets(buff, 1255, (FILE*)fp);
printf("3: %s\n", buff );
fgets(buff, 1255, (FILE*)fp);
printf("4: %s\n", buff );
fclose(fp);
} //the output
[root@v25:/tmp/b] RUST_BACKTRACE=1 ./4
Hello, world3!
Hello from a thread!
1 2 3 4 5 hello.txt z
process exited with: exit code: 0
Child's id is 486267
"5"
"4"
"3"
"2"
"1"
"z"
"hello.txt"
thread 'main' panicked at 'Unable to open the file: Error { repr: Os { code: 38, message: "Function not implemented" } }', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868
stack backtrace:
1: 0x37b79246c - <unknown>
2: 0x37b796b0e - <unknown>
3: 0x37b796714 - <unknown>
4: 0x37b796f4b - <unknown>
5: 0x37b796de4 - <unknown>
6: 0x37b796d09 - <unknown>
7: 0x37b796c97 - <unknown>
8: 0x37b7bcd5d - <unknown>
9: 0x37b789262 - <unknown>
10: 0x37b78a79f - <unknown>
11: 0x37b79eaca - <unknown>
12: 0x37b797456 - <unknown>
13: 0x3bc46b8cc - <unknown>
14: 0x37b788e78 - <unknown>
1 2 3 4 5 hello.txt z
// full example
extern crate libc;
use std::ffi::CString;
use std::fs::File;
use std::str;
use std::io::BufReader;
use std::io::prelude::*;
fn main() {
let filename = CString::new("/var/log/vmkernel.log").unwrap();
let r = CString::new("r").unwrap();
let mut buff = [0i8; 255];
// libc works
unsafe {
let fd = libc::open(filename.as_ptr(), libc::O_RDONLY);
let mut fp = libc::fopen(filename.as_ptr(), r.as_ptr());
libc::fgets(buff.as_mut_ptr(), 255, fp);
//println!("{}", str::from_utf8(buff).unwrap());
// println!("{:?}", &buff[..]); // this works
libc::printf(buff[..].as_ptr() as *const i8);
//let s = CString::new(buff.as_ptr()).expect("Invalid name");
//libc::printf(b"2: %s\n", buff.as_ptr() as *const i8 );
//libc::printf("%s\n", buff);
libc::close(fd);
}
// c also work
// #include <stdio.h>
// main() {
// FILE *fp;
// char buff[1255];
// fp = fopen("/var/log/vmkernel.log", "r");
// fscanf(fp, "%s", buff);
// printf("1 : %s\n", buff );
// fgets(buff, 1255, (FILE*)fp);
// printf("2: %s\n", buff );
// fgets(buff, 1255, (FILE*)fp);
// printf("3: %s\n", buff );
// fgets(buff, 1255, (FILE*)fp);
// printf("4: %s\n", buff );
// fclose(fp);
// }
// Using std::fs. problem;
//this thread 'main' panicked at 'Unable to open the file: Error { repr: Os { code: 38, message: "Function not implemented" } }', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:868 stack backtrace:
let file = File::open("/var/log/vmkernel.log");
let mut buf_reader = BufReader::new(file);
let mut contents = String::new();
buf_reader.read_to_string(&mut contents)?;
println!("{}", &contents);
}If it's interesting, I found more issues in rust, also in those cases I compared it to c++ which successfully worked.
Please note - in centos OS the same rust and c are working only when taking it to Esxi OS there a valid problem.
For example:
c and c++ stdout, threads, system working. in rust only stdout (prints) worked "out of the box".
As said c and c++ and libs just work "out of the box", rust from the other hand forced me to do tweaks libc and compile it static and etc. The current status:
- Using stdout (println!) worked on 6.0 and 6.5 version without and effort from my side.
- using std::thread complained panicked missing glibc_2.14 and didn't work while c++ did. Now this works partiality - mainly on esx6.5.
- std::process now works on 6.5 with the tweaks below while c++ worked almost with 0% effort from my side.
Compiltion info:
VMware Esxi hypervisor version 6.5 with libc 2.12 (dev machine was centos 6 - compiled from cantos 6 as target x86_64-unknown-linux-musl and x86_64-unknown-linux-gnu.
target x86_64-unknown-linux-musl also from cantos7 which has libc2.17.
Let me know if more info can help. I will try more if there some kind of workaround and I will update.