These are chat archives for rust-lang/rust

27th
Apr 2019
Paul Delafosse
@oknozor
Apr 27 12:10
Hello rust, I having trouble here :
---- type_sys::type_visitor::tests::should_push_while_statement stdout ----
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Scope { functions: [], vars: {}, childs: [Loop(LoopScope { condition: [true], inner: Scope { functions: [], vars: {"x": [Hello]}, childs: [], exp: [] } })], exp: [] }`,
 right: `Scope { functions: [], vars: {}, childs: [Loop(LoopScope { condition: [true], inner: Scope { functions: [], vars: {"x": [Hello]}, childs: [], exp: [] } })], exp: [] }`', src/type_sys/type_visitor.rs:261:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
I really don't see any difference here, I am missing something stupid ?
Kris
@VersBinarii
Apr 27 12:21
@oknozor dunno exactly what you're doing but do the struct needs to implement Eq and PartialEq maybe?
Paul Delafosse
@oknozor
Apr 27 12:22
they does
I think if they were not implementing them compilation would fail anyway, right ?
Paul Delafosse
@oknozor
Apr 27 12:51
I just found out what was going wrong: I made my own implementation on PartialEq and I completely forgot about it, i've not been working on this project for a while. Really sorry...
laurent bernabé
@loloof64
Apr 27 14:28
Hi everyone ! I am facing an issue with my compiled program and the GlibC library. I explain
As in my computer I've the glibc 2.27 installed (64bit system), my program compiles with the GlibC 2.27
Meanwhile, I would like to be able to target systems which have not yet switched or updated to GlibC more than 2.23
Is that possible, or must the end-user mandatory updates its packages ?
Denis Lisov
@tanriol
Apr 27 14:31
One way people use for this is building the program in a container/VM based on the distribution/release you target.
laurent bernabé
@loloof64
Apr 27 14:32
Thanks indeed :smile:
I did it the other way around !
First build on my host, then test on my guest system
Denis Lisov
@tanriol
Apr 27 14:34
When I had this problem last time, I was cross-compiling, so just downgraded the "target" glibc version in my system, which could be done independently from the native one.
laurent bernabé
@loloof64
Apr 27 14:34
Yes, that's seem better to me :slight_smile:
Denis Lisov
@tanriol
Apr 27 14:35
Another possible option, depending on your requirements, could be using the musl-based targets to avoid the glibc dep altogether...
laurent bernabé
@loloof64
Apr 27 14:35
What's the musl command ?
Thank you very much :smile:
Exactly what I needed :smile:
Denis Lisov
@tanriol
Apr 27 14:38
Note that you may have some trouble with musl if you depend on C libraries other than glibc or need to support plugins built separately.
laurent bernabé
@loloof64
Apr 27 14:38
Such as imgui-rs ?
Looks this one does not have much dependencies : should be fine
Thank you very much for your suggestions : you make my task very easier :smile:
laurent bernabé
@loloof64
Apr 27 14:47

When I had this problem last time, I was cross-compiling, so just downgraded the "target" glibc version in my system, which could be done independently from the native one.

Did you processed by changing the Cargo.toml (imgui-sys cannot compile with musl) ?

Here my current version of dependencies in Cargo.toml
[dependencies]
imgui = "0.0.23"
glium = "0.23.0"
imgui-winit-support = "*"
imgui-glium-renderer = "0.0.23"
Denis Lisov
@tanriol
Apr 27 14:49
No, that's something you do with your package manager, not Cargo. The simplest option is probably to build on your guest (in my case it was a low-power ARM device, so compiling there could be painful)
laurent bernabé
@loloof64
Apr 27 14:49
Thanks, I'll do with older version of my OS.
The only drawback I may then encounter, is for keeping the end-result as a 64 bit application
(I am using Oracle VM VirtualBox 6.0)
octave99
@octave99
Apr 27 15:00
I have implemented From trait on typeA for typeB. My function in another module returns typeB, so I am able to return typeA.into(). Is there someway to have the compiler infer the type without me inferring it every time using into()
Akos Vandra
@axos88
Apr 27 15:39
@octave99 no
You can specify the input parameter as Into<TypeB>, and then call the conversion within the function, but it won't be totally automatic
Denis Lisov
@tanriol
Apr 27 15:41
What's the actual problem? Normally, if both types are known, value.into() is enough and you don't have to write down the types every time.
octave99
@octave99
Apr 27 16:54
@tanriol Was wondering if value can be returned like return value; instead of return value.into(). I think the answer is no, as @axos88 mentioned.
Akos Vandra
@axos88
Apr 27 21:42
Hey guys, can anyone help me on why cargo seems to be producing libarary instead of an executable?
cargo build --target arm-unknown-linux-gnueabihf

file target/arm-unknown-linux-gnueabihf/debug/project
target/arm-unknown-linux-gnueabihf/debug/project: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=799badfedf7cddbb2a061a2a6163894589d0ae56, for GNU/Linux 3.2.0, stripped
[target.arm-unknown-linux-gnueabihf]

linker = "/usr/bin/arm-linux-gnueabihf-gcc-sysroot"
ar = "/usr/bin/arm-linux-gnueabihf-ar"

rustflags = [
  "-C", "link-arg=-s",
#  "-C", "link-arg=-march=armv6",
#  "-C", "target-cpu=arm1176jzf-s",
]
the gcc-sysroot just adds a --sysroot before invoking gcc
arm-linux-gnueabihf-gcc-sysroot -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 8.3.0-6ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 8.3.0 (Ubuntu/Linaro 8.3.0-ubuntu1
Denis Lisov
@tanriol
Apr 27 21:48
It's a good idea to check whether that's actually a library - IIRC, "LSB shared object" (maybe in old file versions) could actually mean an executable.
Specifically, a PIE executable is technically a shared object, and old file versions (before 5.36 or 5.34) did not mention the difference.
Akos Vandra
@axos88
Apr 27 21:51
yeah, it was a pie exec
just turned it off, however it's still not running
gives a weird error too
 ./tst 
./tst: line 1: syntax error: unexpected word (expecting ")")
file target/arm-unknown-linux-gnueabihf/debug/tst
target/arm-unknown-linux-gnueabihf/debug/tst: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=630b544caa03cfdc17f65dea61e280981cb1dae9, for GNU/Linux 3.2.0, stripped
(the file was ran on the host, not the target)
Denis Lisov
@tanriol
Apr 27 21:53
Are you trying to run an ARM executable on an x86(_64) host without configured emulation?
Akos Vandra
@axos88
Apr 27 21:53
:)
no
on the target (raspberry pi) ldd says
root@doorlock-400ba3d:~> ldd tst 
    libdl.so.2 => /lib/libdl.so.2 (0xa6fe8000)
    librt.so.1 => /lib/librt.so.1 (0xa6fd0000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xa6fa2000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xa6f6f000)
    libc.so.6 => /lib/libc.so.6 (0xa6e05000)
    /lib/ld-linux-armhf.so.3 (0x74aaa000)
so i'm a bit puzzled... ldd reckognizes it as a dynamic executable, but when running it's getting confused
Denis Lisov
@tanriol
Apr 27 21:55
And it does have executable permission set, correct?
Akos Vandra
@axos88
Apr 27 21:55
checking
but it was green is ls
yeah
-rwxr-xr-x    1 root     root        157376 Apr 27 23:50 tst
Denis Lisov
@tanriol
Apr 27 22:01
Looks weird. This is in /root, so no surprises like noexec, correct?
Akos Vandra
@axos88
Apr 27 22:08
yeah
it's an embedded linux, so very bare bone
this is the cargo new's hello world
if I compile a C hello world with the same compiler, that works
Denis Lisov
@tanriol
Apr 27 22:09
Hmmm... what distribution does it have onboard?
Is your cross toolchain the one for your distribution or something else?
Akos Vandra
@axos88
Apr 27 22:13
It's called nard linux
hmmm
the linker is different though
akos@akos-workstation:~/projects/rust/tst$ file target/arm-unknown-linux-gnueabihf/debug/tst
target/arm-unknown-linux-gnueabihf/debug/tst: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=0112b3c98058b6b778b368ec31011fd52d145ddf, for GNU/Linux 3.2.0, stripped
akos@akos-workstation:~/projects/rust/tst$ file ./a.out
./a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, BuildID[sha1]=6d362b616fa1d82487429f7ca765f51f16181726, for GNU/Linux 3.2.0, not stripped
sorry interpreter
-Wl,--as-needed -Wl,-z,noexecstack -L /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.10c5hzjcmprnr20e.rcgu.o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.10u55jc1h73mrh8z.rcgu.o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.1e42d9s7m62wvwmp.rcgu.o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.2e8c2jpto0vj57bm.rcgu.o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.33asz11aj12cinoo.rcgu.o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.4kqtslv982df8fek.rcgu.o -o /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113 /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps/tst-8ea58e9ea21c7113.1n4n3nao9x4ngqjl.rcgu.o -Wl,--gc-sections -pie -Wl,-zrelro -Wl,-znow -nodefaultlibs -L /home/akos/projects/rust/tst/target/arm-unknown-linux-gnueabihf/debug/deps -L /home/akos/projects/rust/tst/target/debug/deps -L /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib -Wl,--start-group -Wl,-Bstatic /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd-42431e74081a30a8.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libpanic_abort-0326c542cecbee9e.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libbacktrace_sys-8dcce133820ce36b.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libunwind-550595cd0e8605f6.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_demangle-616d93738996b317.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liblibc-0bdc7ca6876dfe08.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liballoc-5f6229b11bb8dfe3.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_std_workspace_core-74acf7fdf307aa94.rlib /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcore-08e0675cab0aedce.rlib -Wl,--end-group /home/akos/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcompiler_builtins-ccce53ba085ea72e.rlib -Wl,-Bdynamic -ldl -lrt -lpthread -lgcc_s -lc -lm -lrt -lpthread -lutil -lutil -s -march=armv6 -no-pie
these are the arguments to the linker when linking the rust code
Akos Vandra
@axos88
Apr 27 22:19
nah, they are symlinked to the same thing:
lrwxrwxrwx    1 root     root            10 Apr 27 22:53 /lib/ld-linux-armhf.so.3 -> ld-2.29.so
lrwxrwxrwx    1 root     root            10 Apr 27 22:53 /lib/ld-linux.so -> ld-2.29.so
lrwxrwxrwx    1 root     root            10 Apr 27 22:53 /lib/ld-linux.so.2 -> ld-2.29.so
lrwxrwxrwx    1 root     root            10 Apr 27 22:53 /lib/ld-linux.so.3 -> ld-2.29.so
might be an isse with my glibc, because I tried upgrading it, I guess it's not working correctly....
but then again the system shouldn't boot
and shouldn't load the C hello world either
Denis Lisov
@tanriol
Apr 27 22:23
I'd try stracing the start attempt to know the exact error.
Akos Vandra
@axos88
Apr 27 22:33
no strace :(