perhaps an -L flag is missing? error doesn't print -L flags given or any other info

[kornelski]

I keep running into this problem:

1. I write a build script that seems to work fine (no panics) and outputs -L flags that I hope are correct

2. Something isn't right and Cargo tells me

   error: could not find native static library foo, perhaps an -L flag is missing?

To me information printed by Cargo, even in verbose mode, is insufficient to diagnose the problem.

• Cargo doesn't tell me if it got any -L flags at all.
  I could try to guess if it got flags by searching the long noisy " Running rustc…" lines, but the paths are usually based on random-looking expansion of OUT_DIR (e.g. I see different hash in paths when I add panic!() to my script and I don't know if that's normal), so I don't really know what paths I'm looking at. Due to Request not to suppress the output of build script #1106 it's a pain to find that out.
• Cargo doesn't tell me what files it expected to find.

It would be so much nicer if Cargo had message such as:

Can't link native library foo wanted by foo-sys. Expected to find libfoo.so in these directories:

• /foo/lib (set by foo/build.rs) (this directory doesn't exist)
• /usr/lib/bar (set by bar.sh) (found libfoo.a, but not libfoo.so)

[alexcrichton]

I don't think that we'll get to quite that level of fidelity with an error message because this error is being generated by the compiler, not by Cargo itself, but I'd believe that it could certainly improve!

[m13253]

I think it is important to break the glass to see what's happening inside.

Sometimes the first step goes (falsely) successful, but it caused later steps to fail.
The error report mechanism is not always smart to find out the direct cause of the error (or debuggers would retire).

So, debugging the whole build process needs to be possible.
For example, add a logging mode to print as much as information (command lines, environments, inputs/outputs) during each step.
Or a way to invoke GDB to debug the build script.

[kornelski]

GDB in Rust part of the build script wouldn't help me much, since my Rust build scripts are:

fn main() {
    if !std::io::Command::new("./src/build.sh")
        .stdout(::std::io::process::InheritFd(1))
        .stderr(::std::io::process::InheritFd(2))
        .status().unwrap().success() {
        panic!("Script failed");
    }
}

[m13253]

But I'm sorry to say that Cargo is eating up all std{in,out,err}. (#1106)
So it is no use doing InheritFd.

I saw you discussing on #1106 .
But I need more reasons to prove the significance of not eating stderr with --verbose.

[kornelski]

But I need more reasons to prove the significance of not eating stderr with --verbose.

But what is the reason for eating it? So far I've seen "it looks clean!". So to me it's

• Pro: it looks neat!
• Con: I can't develop working Cargo packages!

I feel like Cargo is highly "opinionated" and its opinions completely don't match mine. On every step I'm fighting around it :(

I want to use "printf debugging", without stopping the program, since it's easy and works with entire toolchain that I'm using. I can't imagine how could I possibly use GDB to debug the mountain of crap scripts that autotools spits out.

Since pure Rust build scripts are supposed to be the right way, I've tried that. I gave up after my 4-line bash script started to exceed 100 Rust lines.

[m13253]

I want to use "printf debugging", without stopping the program, since it's easy and works with entire toolchain that I'm using. I can't imagine how could I possibly use GDB to debug the mountain of crap scripts that autotools spits out.

You can achieve your goal by:

1. Start an XTerm to print out things (or AllocConsole on Windows). But this degrades user experiences.
2. Write to /proc/$PARENT_PID/fd/2 as stderr (or OpenProcess + DuplicateHandle combination on Windows). This tweak works perfectly as if no restrictions were there.

Maybe we can make a helper library to do what we want to do without modifying Cargo.

[alexcrichton]

@pornel you may want to weigh in on #1106 to see some various tradeoffs when dealing with the output of build scripts.

[kornelski]

@alexcrichton I've done that: #1106 (comment)

[alexcrichton]

Gah sorry! Thanks for weighing in though :)

[stale]

As there hasn't been any activity here in a while would someone (the author, a team member, or any interested party) be able to summarise the current state, perhaps making explicit:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!