These are chat archives for rust-lang/rust

7th
May 2019
dharric
@dharric
May 07 00:49
hello was wondering if people had been able to find freelance rust work
Georg Semmler
@weiznich
May 07 17:21
I'm back with yet another ABI related question. Still trying to play around with some (wasm-) FFI related stuff I asking myself if it's possible to write a generic dealloc function for returned ptr's. So I came up with this, but I'm quite unsure if I don't exploit some implementation defined behavior somewhere. (Especially as part of the myfree function, where I use some placeholder type for the inner value. If I try that in a real environment it seems to work that way...)
Denis Lisov
@tanriol
May 07 17:45
Pretty sure you do. Your placeholder type definitely has incorrect alignment (it has an alignment of 1 instead of at least 4/8) and may have incorrect size if it requires padding (some types, IIUC, may require 16 byte alignment even on i386, not sure about wasm32 but won't be surprised). A defensively written allocator can ignore both problems, but technically an allocator can try using this information.
Georg Semmler
@weiznich
May 07 18:17
In which part of the function this would be a problem? While calling the attached destructor function or while freeing the pointer itself?
I don't see how the alignment may come in play here? Probably between destructor function pointer and the size field? That would be quite easy to workaround, because I just need to change the size field to store the full type size than, right?
Denis Lisov
@tanriol
May 07 18:25
When freeing. The Rust's allocator API provides the allocator with a Layout that describes both the type size and its alignment. For example, the allocator may allocate memory from different arenas based on the requested alignment. If it also looks at the alignment when freeing memory, you may trick it into trying to free memory from the wrong arena, which may cause UB.
Georg Semmler
@weiznich
May 07 18:42
That sound like I should just store that layout as part of the ReturnPtr type. After that I don't need to mess with constructing the right box there, because I can just call std::alloc::dealloc right?
Additionally: The first part of the myfree function with calling that attached function pointer with a "wrong" type is sound?
Drasko DRASKOVIC
@drasko
May 07 19:25
drasko@Marx:~/rust/uedge$ cargo install cargo-edit
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing cargo-edit v0.3.1
 Downloading env_proxy v0.2.0
 Downloading pad v0.1.5                                                         
 Downloading serde v1.0.91                                                      
 Downloading error-chain v0.12.0                                                
 Downloading cargo_metadata v0.6.4                                              
 Downloading serde_json v1.0.39                                                 
 Downloading semver v0.9.0                                                      
 Downloading toml_edit v0.1.3                                                   
error: failed to compile `cargo-edit v0.3.1`, intermediate artifacts can be found at `/tmp/cargo-installj2DY6X`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/home/drasko/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-1.1.0/Cargo.toml`

Caused by:
  editions are unstable

Caused by:
  feature `edition` is required

this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["edition"]` to enable this feature
Any ideas how to install this crate?
Denis Lisov
@tanriol
May 07 19:26
How about rustup update before installing it?
Ingvar Stepanyan
@RReverser
May 07 19:26
sounds like you have pretty old version of cargo
Drasko DRASKOVIC
@drasko
May 07 19:27
let me try
That worked
thanks a lot!
Drasko DRASKOVIC
@drasko
May 07 20:22
cargo build is not passing cross-compiler info to the cmake
I can see "-DCMAKE_C_COMPILER=/usr/bin/cc" used
Even though I called build with STAGING_DIR=~/openwrt/staging_dir cargo build --target mips-unknown-linux-musl --release -vvv
Denis Lisov
@tanriol
May 07 20:22
May be crate-specific. What crate are we talking about?
Drasko DRASKOVIC
@drasko
May 07 20:23
paho-mqtt
It's actually paho-mqtt-sys that fails
it uses Cmake
Drasko DRASKOVIC
@drasko
May 07 20:28
how to pass the flags to underlaying Cmake?
Denis Lisov
@tanriol
May 07 20:32
Not sure whether cmake uses these variables at all :-) also, have you set up the cross-compiler in the cargo config correctly?
Drasko DRASKOVIC
@drasko
May 07 20:32
I did
matrixbot
@matrixbot
May 07 20:32
bspeice If this is a one-off issue, maybe change the CC environment variable? Otherwise, there's not much to be done besides changing the build.rs script for the underlying sys crate, as that's what's actually driving cmake: https://github.com/eclipse/paho.mqtt.rust/blob/master/paho-mqtt-sys/build.rs#L134
Drasko DRASKOVIC
@drasko
May 07 20:32
everything else is compiled correctly
Denis Lisov
@tanriol
May 07 20:33
Well, I've tried compiling it and for me the correct cross-compiler was called.
"everything else is compiled correctly" might mean that you don't depend on other C code that has to be compiled :-)
Drasko DRASKOVIC
@drasko
May 07 20:35
strange
I see that when I change CC this affects the build
@tanriol which cross-compiler did you use?
Denis Lisov
@tanriol
May 07 20:37
Don't have any MIPS ones at hand, tested on --target=arm-unknown-linux-gnueabihf
Drasko DRASKOVIC
@drasko
May 07 20:47
Interesting, with ARM cross-compiler it works
with MIPS one - no
Denis Lisov
@tanriol
May 07 21:13
Looks like the cc crate is missing the mips/musl targets.
Drasko DRASKOVIC
@drasko
May 07 21:13
it's more lib paho issue
Looks like MIPS is not supported, but I am adding my MIPS CMAKE toolchain file
now stuck with OpenSSL stuff
David Raifaizen
@craftytrickster
May 07 21:26
Is there a way to get the proccess name of your program on windows?
on linux, i know i can use libc
matrixbot
@matrixbot
May 07 21:41
bspeice Should be possible. OpenProcess (Rust, MSDN) will give you a handle, and then GetModuleBaseName (or GetModuleFileName) should be able to tell you what the executable name is (Rust, MSDN). Note that I'm mostly translating instructions from this SO answer to Rust.
Drasko DRASKOVIC
@drasko
May 07 23:12
Any idea how to pass ENV variable to an underlying build?
matrixbot
@matrixbot
May 07 23:13
bspeice Should be possible using .cargo/config
Drasko DRASKOVIC
@drasko
May 07 23:16
huh...
but how?
I have tried
CARGO_CFG_OPENSSL_SEARCH_PATH=/home/drasko/openwrt/staging_dir/target-mips_24kc_musl/usr CMAKE_TOOLCHAIN_FILE=/home/drasko/rust/uedge/toolchain.mips.cmake STAGING_DIR=~/openwrt/staging_dir cargo build --target mips-unknown-linux-musl --release -vvv
That did no work...
matrixbot
@matrixbot
May 07 23:17
bspeice Right, my recommendation is to add those variables to the .cargo/config file instead of setting them when calling cargo.
bspeice What's likely going on is that cargo is clearing out the environment variables to make builds more stable.
Drasko DRASKOVIC
@drasko
May 07 23:18
under which tag they should be put?
let me check
In ~/.cargo/config or in the ./.cargo/config?
matrixbot
@matrixbot
May 07 23:19
bspeice ./.cargo/config
Drasko DRASKOVIC
@drasko
May 07 23:19
can you please give the example of the format?
matrixbot
@matrixbot
May 07 23:20
bspeice Yep, I'm looking one up now to make 100% sure.
Drasko DRASKOVIC
@drasko
May 07 23:20
:+1:
matrixbot
@matrixbot
May 07 23:23

bspeice In the mean time, if you modify that file to be:

CARGO_CFG_OPENSSL_SEARCH_PATH=/home/drasko/openwrt/staging_dir/target-mips_24kc_musl/usr
CMAKE_TOOLCHAIN_FILE=/home/drasko/rust/uedge/toolchain.mips.cmake
STAGING_DIR=~/openwrt/staging_dir

What happens?

Drasko DRASKOVIC
@drasko
May 07 23:24
What do you mean?
I mean - I see no difference in what you pasted here
and what i tried before
matrixbot
@matrixbot
May 07 23:25
bspeice Right, but put it in ./.cargo/config, rather than on the command line.
Drasko DRASKOVIC
@drasko
May 07 23:25
ah, OK
let me try
matrixbot
@matrixbot
May 07 23:25
bspeice The theory is that Cargo is modifying the environment before invoking anything.
Drasko DRASKOVIC
@drasko
May 07 23:27
drasko@Marx:~/rust/uedge$ cargo build --target mips-unknown-linux-musl --release -vvv
error: could not load Cargo configuration

Caused by:
  could not parse TOML configuration in `/home/drasko/rust/uedge/.cargo/config`

Caused by:
  could not parse input as TOML

Caused by:
  unexpected character found: `/` at line 1
Well.. normal
it expects TOML
matrixbot
@matrixbot
May 07 23:27
bspeice Oh dang, that was unexpected.
bspeice Still working on that example run.
bspeice Ah, appears I led you down the wrong path, Cargo doesn't modify the environment.
matrixbot
@matrixbot
May 07 23:42
bspeice So are the environment variables not showing up/being used incorrectly? It seems like Cargo isn't doing anything funny, those variables should be passed to the child processes. The only thing I can recommend otherwise would be to export CMAKE_TOOLCHAIN_FILE=... for example to try and work around this.
Drasko DRASKOVIC
@drasko
May 07 23:44
Some are passed
like CMAKE ones
but OPENSSL_SEARCH_PATH is not
matrixbot
@matrixbot
May 07 23:48
bspeice Ah, now I understand. Because OPENSSL_SEARCH_PATH is a CMake define, not an environment variable I think you're correct, there's not a way to pass it in without changing the build.rs file.