Nim: Compiled binary includes full path to internal nim files

[daniel-j]

Compiling any program causes a long filesystem path outside my project to be included in the final binary. I have tried the following flags and it still gets included:
-d:release --listFullPaths:off --excessiveStackTrace:off --opt:size

Example

echo "Hello World!"

$ nim c -d:release --listFullPaths:off --excessiveStackTrace:off --opt:size helloworld.nim

Current Output

$ strings helloworld | grep toolchains
../../../home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim

Expected Output

(empty)

Possible Solution

Additional Information

• Nim version 0.20.0 (e7471cebae2a404f3e4239f199f5a0c422484aac) installed with choosenim
• Operating System: Arch Linux
• This line in fatal.nim seems related to the issue (someone on irc pointed out).
• irc log: https://irclogs.nim-lang.org/24-06-2019.html#17:04:10

[dizzyliam]

Does this result in unexpected behavior if the linked files are no longer available?

[daniel-j]

No, it's probably just for debugging. I just don't want my username etc to be included in the final binary.

[dizzyliam]

Does it do the same thing when you compile with the release flag? If not, then that should be an easy feature/patch to implement.

[dizzyliam]

Sorry, I misread your issue. I'll have a look when I next can. Exited to start contributing!

[daniel-j]

Thanks!

[dizzyliam]

Is anyone able to test this on a not arch-based distro?

[dom96]

I doubt this is arch-specific. Yeah, we need a way to prevent these paths making their way into the binary.

[dom96]

This should indeed be a fairly easy PR, probably just need to check one of these flags in a specific place. If fatal.nim is the only filename making its way in there then it might be even easier.

[dizzyliam]

I'm looking at the code in compiler/msgs.nim that is responsible for checking the flags and deciding what file path to use. Maybe it is an edgecase in the lines that process the full path? I'll be freed up in about an hour, so I'll start troubleshooting then.

[daniel-j]

On the project I'm working on I get this in debug:

/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/io.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/iterators.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/alloc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/gc_common.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/avltree.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/gc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/osalloc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/mmdisp.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/cellsets.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/strmantle.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim

If I add -d:release I get the following:

/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim

--listFullPaths:off turns some of the paths into relative (debug):

/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/io.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/iterators.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/alloc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/gc_common.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/avltree.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/gc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/osalloc.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/mmdisp.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/cellsets.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/strmantle.nim
/home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim
../../../../home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim
../../../../home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/gc.nim

Both -d:release and --listFullPaths:off:

../../../../home/djazz/.choosenim/toolchains/nim-0.20.0/lib/system/fatal.nim

[dizzyliam]

The problem here is on 210 of msgs.nim:
result = if relPath.count("..") > 2: absPath else: relPath
If the number of directories back the file is (relatively), is more than two, then it will compile with the full and absolute path. I personally, can't see a reason for this, so I'll make a pull request removing it.

[dizzyliam]

F-ed that one up because of a stupid mistake. My bad; trying again now...

[juancarlospaco]

Can --opt:size make those empty string :grey_question:
Or any other flag to not even include the relative paths...

[dizzyliam]

That might be a good idea.

[SolitudeSF]

how is that a good idea? --opt:size has nothing to do with that. size of the binary is completely unrelated to leaking build paths.

[juancarlospaco]

I agree with @SolitudeSF
But I dont see other flag, unless we change the existing ones, what about:

• --listFullPaths:off :arrow_right: Empty string everywhere
• --listFullPaths:relative :arrow_right: Relative path everywhere
• --listFullPaths:on:arrow_right: Full path everywhere

[alaviss]

--listFullPaths is a switch for compiler messages. Previously #9766 accidentally make this switch affects codegen, which I've fixed in #11583.

The problem now only resides in how the compiler use these paths. Paths of modules outside the project being compiled used during codegen is always relative, but can leak easily with ../../home/<snip>/system.nim.

A way to "fix" this is to apply extractFilename() on paths outside of the current project, or we do some magic to shorten them to <project name>/module.nim.

I think to remove all paths --stacktrace:off can be extended to do so (it's odd why that flag doesn't get rid of stack trace altogether).

[doongjohn]

I can still find full path in a binary file with -d:release --excessiveStackTrace:off is this intended? or am I missing something?

[alaviss]

It doesn't come from Nim, but from the miniz C source code:

https://github.com/h3rald/nim-miniz/blob/b47edf871f2c780b72dcce7da232ef5afee57d56/src/libminiz.c#L1907

You can compile with --passC:-DNDEBUG to disable assertions within miniz.