CyberShadow/btdu

GCC bug with btdu

Opened this issue · 6 comments

I tried to use gdc (gcc d compiler), however it failed. It seems to be a bug in gcc(*). I was able to compile btdu with LLVM's ldc, which worked good.

To use another compiler than dmd, I used rhe following:

dub build --compiler=ldc2 -b release

It is interesting that ldc2 made a much smaller binary.

-rwxr-xr-x 1 forza forza  19M Aug 15 23:17 btdu.dmd*
-rwxr-xr-x 2 forza forza 4,2M Sep 30 23:15 btdu.ldc2*
-rwxr-xr-x 2 forza forza 5,7M Sep 30 23:33 btdu.ldc2.O3-lto*

(*) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650

Thanks!

BTW, the likely reason why the LDC-produced binaries are smaller is that, by default and unlike DMD, it links to the runtime and standard library dynamically.

That makes sense. I couldn’t make a static version eith ldc2. I suspect that I also need static versions of the library. It's of course not a problem as I compile for my own system.

 DFLAGS="-O3 --flto=full --static" dub build --compiler=ldc2 --combined -f -b release
    Starting Performing "release" build using ldc2 for x86_64.
    Building btdu 0.5.1+commit.100.g76b07f9: building configuration [application]
     Linking btdu
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lncursesw: No such file or directory
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ltinfow: No such file or directory
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lphobos2-ldc: No such file or directory
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ldruntime-ldc: No such file or directory
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
Error ldc2 failed with exit code 1.

Yes. Note that the CI builds static/LTO versions of everything. You can request to just link the static standard library / runtime with -link-defaultlib-shared=false.

I see there was a commit in GCC that addressed the issue. Does it still occur?

I see there was a commit in GCC that addressed the issue. Does it still occur?

In which version of gcc is included? I am still on gcc-13.3.1.

❯ dub build --compiler=gdc -b release
    Starting Performing "release" build using gdc for x86_64.
  Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
    Building btdu 0.5.1+commit.106.ga327b19: building configuration [application]
source/btdu/sample.d: In function ‘__lambda3’:
source/btdu/sample.d:325:22: internal compiler error: in build_deref, at d/d-codegen.cc:1651
  325 |                 Root result;
      |                      ^
0x1291186 internal_error(char const*, ...)
        ???:0
0x129126d fancy_abort(char const*, int, char const*)
        ???:0
0x1aeb14c declare_local_var(VarDeclaration*)
        ???:0
0x134fae1 build_decl_tree(Dsymbol*)
        ???:0
0x1360af0 build_expr(Expression*, bool, bool)
        ???:0
0x1376c5a build_expr_dtor(Expression*)
        ???:0
0x1ae8a59 build_function_body(FuncDeclaration*)
        ???:0
0x134fae1 build_decl_tree(Dsymbol*)
        ???:0
0x1360af0 build_expr(Expression*, bool, bool)
        ???:0
0x1360af0 build_expr(Expression*, bool, bool)
        ???:0
0x1376c5a build_expr_dtor(Expression*)
        ???:0
0x1ae8a59 build_function_body(FuncDeclaration*)
        ???:0
0x134fae1 build_decl_tree(Dsymbol*)
        ???:0
0x1360af0 build_expr(Expression*, bool, bool)
        ???:0
0x1380706 convert_for_argument(Expression*, Parameter*)
        ???:0
0x137a526 d_build_call(TypeFunction*, tree_node*, tree_node*, Array<Expression*>*)
        ???:0
0x1360af0 build_expr(Expression*, bool, bool)
        ???:0
0x1376c5a build_expr_dtor(Expression*)
        ???:0
0x1ae8a59 build_function_body(FuncDeclaration*)
        ???:0
0x134fae1 build_decl_tree(Dsymbol*)
        ???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
Error gdc failed with exit code 1.

Ah, looks like it's in 14.1.