[Bug rust/113499] New: crab1 fails to link when configuring with --disable-plugin

[Bug rust/113499] New: crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

            Bug ID: 113499
           Summary: crab1 fails to link when configuring with
                    --disable-plugin
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rust
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

With --disable-plugin we probably elide -ldl but crab1 calls dlopen even when
plugin support is disabled leading to

[  949s]
/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/./prev-gcc/
-B/usr/x
86_64-suse-linux/bin/ -nostdinc++
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/abuild/rpmbuild/BUILD/gcc-
14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs

-I/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/l
ibstdc++-v3/include/x86_64-suse-linux 
-I/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include
 -I/home/abuild/rpmbuild/BUILD/
gcc-14.0.1+git8231/libstdc++-v3/libsupc++
-L/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/abuild/rpmbuild/BU
ILD/gcc-14.0.1+git8231/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-no-pie   -fmessage-length=0 -grecord-gcc-switches -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack
-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -g -fno-checking -gtoggle -fprofile-generate -DIN_GCC 
  -fno-exceptions -fno-rtti -fasynchronous
-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macro
s -Wno-overlength-strings   -DHAVE_CONFIG_H -no-pie -static-libstdc++
-static-libgcc  -L./../libgrust/libproc_macro_internal -o crab1 \
[  949s]       rust/rust-lang.o rust/rust-object-export.o rust/rust-linemap.o
rust/rust-diagnostics.o rust/rust-gcc.o rust/rust-token.o rust/rust-lex.o
rust/rust-cfg-parser.o rust/rust-
parse.o rust/rust-ast.o rust/rust-ast-formatting.o rust/rust-path.o
rust/rust-pattern.o rust/rust-ast-fragment.o rust/rust-ast-dump.o
rust/rust-ast-collector.o rust/rust-ast-visitor.o r
ust/rust-hir-dump.o rust/rust-session-manager.o rust/rust-compile.o
rust/rust-mangle.o rust/rust-compile-resolve-path.o rust/rust-macro-expand.o
rust/rust-cfg-strip.o rust/rust-expand-v
isitor.o rust/rust-ast-builder.o rust/rust-derive.o rust/rust-derive-clone.o
rust/rust-derive-copy.o rust/rust-proc-macro.o rust/rust-macro-invoc-lexer.o
rust/rust-proc-macro-invoc-lexe
r.o rust/rust-macro-substitute-ctx.o rust/rust-macro-builtins.o rust/rust-hir.o
rust/rust-hir-map.o rust/rust-attributes.o rust/rust-keyword-values.o
rust/rust-abi.o rust/rust-token-con
verter.o rust/rust-macro.o rust/rust-ast-lower.o rust/rust-ast-lower-base.o
rust/rust-ast-lower-pattern.o rust/rust-ast-lower-item.o
rust/rust-ast-lower-expr.o rust/rust-ast-lower-type.
o rust/rust-ast-lower-stmt.o rust/rust-rib.o
rust/rust-name-resolution-context.o rust/rust-default-resolver.o
rust/rust-toplevel-name-resolver-2.0.o rust/rust-early-name-resolver-2.0.o 
rust/rust-early-name-resolver.o rust/rust-name-resolver.o
rust/rust-ast-resolve.o rust/rust-ast-resolve-base.o
rust/rust-ast-resolve-item.o rust/rust-ast-resolve-pattern.o rust/rust-ast
-resolve-expr.o rust/rust-ast-resolve-type.o rust/rust-ast-resolve-path.o
rust/rust-ast-resolve-stmt.o rust/rust-ast-resolve-struct-expr-field.o
rust/rust-hir-type-check.o rust/rust-pri
vacy-check.o rust/rust-privacy-ctx.o rust/rust-reachability.o
rust/rust-visibility-resolver.o rust/rust-pub-restricted-visitor.o
rust/rust-privacy-reporter.o rust/rust-tyty.o rust/rust-
tyty-util.o rust/rust-tyty-call.o rust/rust-tyty-subst.o
rust/rust-typecheck-context.o rust/rust-tyty-bounds.o
rust/rust-hir-trait-resolve.o rust/rust-hir-trait-reference.o rust/rust-hi
r-type-check-item.o rust/rust-hir-type-check-type.o
rust/rust-hir-type-check-struct.o rust/rust-hir-type-check-pattern.o
rust/rust-hir-type-check-expr.o rust/rust-hir-type-check-stmt.o 
rust/rust-hir-type-check-enumitem.o rust/rust-hir-type-check-implitem.o
rust/rust-borrow-checker.o rust/rust-bir-builder-expr-stmt.o
rust/rust-bir-dump.o rust/rust-hir-dot-operator.o ru
st/rust-hir-path-probe.o rust/rust-type-util.o rust/rust-coercion.o
rust/rust-casts.o rust/rust-unify.o rust/rust-hir-type-check-base.o
rust/rust-autoderef.o rust/rust-substitution-mapp
er.o rust/rust-const-checker.o rust/rust-lint-marklive.o
rust/rust-lint-unused-var.o rust/rust-readonly-check.o
rust/rust-hir-type-check-path.o rust/rust-unsafe-checker.o rust/rust-comp
ile-intrinsic.o rust/rust-compile-pattern.o rust/rust-compile-fnparam.o
rust/rust-compile-proc-macro.o rust/rust-base62.o rust/rust-compile-item.o
rust/rust-compile-implitem.o rust/rust
-compile-stmt.o rust/rust-compile-expr.o rust/rust-compile-type.o
rust/rust-compile-block.o rust/rust-compile-struct-field-expr.o
rust/rust-constexpr.o rust/rust-compile-base.o rust/rus
t-tree.o rust/rust-compile-context.o rust/rust-export-metadata.o
rust/rust-imports.o rust/rust-import-archive.o rust/rust-extern-crate.o
rust/rust-builtins.o rust/rust-feature.o rust/ru
st-feature-gate.o rust/rust-ast-validation.o rust/rust-dir-owner.o
rust/rust-unicode.o rust/rust-punycode.o  i386-rust.o linux-rust.o attribs.o
libbackend.a main.o libcommon-target.a li
bcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
  ../libgrust/libproc_macro_internal/libproc_macro_internal.a -lisl -lmpc
-lmpfr -lgmp   -lz 
[  950s] /usr/x86_64-suse-linux/bin/ld: rust/rust-proc-macro.o: in function
`Rust::load_macros_array(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >)':
[  950s] rust-proc-macro.cc:(.text+0xf5f): undefined reference to `dlopen'
[  950s] /usr/x86_64-suse-linux/bin/ld: rust-proc-macro.cc:(.text+0x11b1):
undefined reference to `dlsym'
[  950s] /usr/x86_64-suse-linux/bin/ld: rust-proc-macro.cc:(.text+0x13eb):
undefined reference to `dlerror'
[  950s] /usr/x86_64-suse-linux/bin/ld: rust/rust-proc-macro.o: in function
`bool Rust::register_callback<ProcMacro::BridgeState,
ProcMacro::BridgeState>(void*, ProcMacro::BridgeState, 
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>, ProcMacro::BridgeState)':
[  950s]
rust-proc-macro.cc:(.text._ZN4Rust17register_callbackIN9ProcMacro11BridgeStateES2_EEbPvT_NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEET0_[_ZN4Rust17register_callbackIN9P
rocMacro11BridgeStateES2_EEbPvT_NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEET0_]+0x34):
undefined reference to `dlsym'
[  950s] /usr/x86_64-suse-linux/bin/ld: rust/rust-proc-macro.o: in function
`bool Rust::register_callback<ProcMacro::Literal
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
 std::allocator<char> > const&, bool&), ProcMacro::Literal
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, bool&)>(void*, ProcMacro::Literal 
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, bool&), std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, Proc
Macro::Literal (*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, bool&))':
[  950s]
rust-proc-macro.cc:(.text._ZN4Rust17register_callbackIPFN9ProcMacro7LiteralERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERbESD_EEbPvT_S8_T0_[_ZN4Rust17register_callbackIPFN9ProcMacro7LiteralERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERbESD_EEbPvT_S8_T0_]+0x34):
undefined reference to `dlsym'
[  950s] /usr/x86_64-suse-linux/bin/ld: rust/rust-proc-macro.o: in function
`bool Rust::register_callback<ProcMacro::TokenStream
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, bool&), ProcMacro::TokenStream
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, bool&)>(void*, ProcMacro::TokenStream
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, bool&), std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, ProcMacro::TokenStream
(*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, bool&))':
[  950s]
rust-proc-macro.cc:(.text._ZN4Rust17register_callbackIPFN9ProcMacro11TokenStreamERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERbESC_EEbPvT_S8_T0_[_ZN4Rust17register_callbackIPFN9ProcMacro11TokenStreamERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERbESC_EEbPvT_S8_T0_]+0x34):
undefined reference to `dlsym'
[  951s] collect2: error: ld returned 1 exit status
[  951s] make[3]: *** [../../gcc/rust/Make-lang.in:212: crab1] Error 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note it might also be because the failing build is using glibc-2.31, IIRC
newer glibc might include libdl directly (at least that's the case for
libpthreads ...)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-09
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Re-confirmed.  Can be reproduced both on a glibc 2.31 and glibc 2.38 system
with

../src/configure --enable-languages=rust --disable-bootstrap --disable-plugin

See GCC_ENABLE_PLUGIN which adjusts 'pluginlibs' but also causes symbols to
be exported from the executable.  You need to figure what you need.  For
example the 'jit' frontend also requires this (--enable-host-shared), but
IIRC it doesn't require -ldl

Some hosts may not support dynamically loading things.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Re-confirmed.  Can be reproduced both on a glibc 2.31 and glibc 2.38 system
> with

It does work with glibc 2.38, so only glibc 2.31 fails this (and possibly other
OS).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/Rust-GCC
                   |                            |/gccrs/issues/2890
                 CC|                            |cohenarthur at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
If I understood Arthur correctly, GCC/Rust is going to effectively require
'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's not
available we have to auto-disable Rust language front end if enabled
'--enable-languages=all' vs. raise a 'configure'-time error if enabled via
explicit '--enable-languages=rust'?

Related is also <https://github.com/Rust-GCC/gccrs/issues/2890> "Don't
hard-code `-ldl -lpthread` for `format_args`".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #4)
> If I understood Arthur correctly, GCC/Rust is going to effectively require
> 'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's
> not available we have to auto-disable Rust language front end if enabled
> '--enable-languages=all' vs. raise a 'configure'-time error if enabled via
> explicit '--enable-languages=rust'?

Not sure - --enable-plugin is not about dlopen, it's about exporting all
GCCs internal symbols for use by a dlopened shared module.  Is the
macro processing requiring this or is it rather self-contained?

Being able to dlopen() is something different.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[cohenarthur at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #6 from Arthur Cohen <cohenarthur at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Thomas Schwinge from comment #4)
> > If I understood Arthur correctly, GCC/Rust is going to effectively require
> > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's
> > not available we have to auto-disable Rust language front end if enabled
> > '--enable-languages=all' vs. raise a 'configure'-time error if enabled via
> > explicit '--enable-languages=rust'?
> 
> Not sure - --enable-plugin is not about dlopen, it's about exporting all
> GCCs internal symbols for use by a dlopened shared module.  Is the
> macro processing requiring this or is it rather self-contained?
> 
> Being able to dlopen() is something different.

No, it does not require this and is rather self contained. Macro expansion
needs to be able to dlopen() compiled Rust libraries, which contain a specific
type of function our frontend calls as a macro. So we always need to dlopen().

Is there anything similar in other frontends? If so, how does it work on such
platforms which do not support dlopen()?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #7 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > Re-confirmed.  Can be reproduced both on a glibc 2.31 and glibc 2.38 system
> > with
> 
> It does work with glibc 2.38, so only glibc 2.31 fails this (and possibly
> other OS).

In Glibc 2.34 libdl was merged into libc, thus it only fails with Glibc < 2.34.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Arthur Cohen from comment #6)
> (In reply to Richard Biener from comment #5)
> > (In reply to Thomas Schwinge from comment #4)
> > > If I understood Arthur correctly, GCC/Rust is going to effectively require
> > > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's
> > > not available we have to auto-disable Rust language front end if enabled
> > > '--enable-languages=all' vs. raise a 'configure'-time error if enabled via
> > > explicit '--enable-languages=rust'?
> > 
> > Not sure - --enable-plugin is not about dlopen, it's about exporting all
> > GCCs internal symbols for use by a dlopened shared module.  Is the
> > macro processing requiring this or is it rather self-contained?
> > 
> > Being able to dlopen() is something different.
> 
> No, it does not require this and is rather self contained. Macro expansion
> needs to be able to dlopen() compiled Rust libraries, which contain a
> specific type of function our frontend calls as a macro. So we always need
> to dlopen().
> 
> Is there anything similar in other frontends? If so, how does it work on
> such platforms which do not support dlopen()?

I'm not aware of other frontends absolutely requiring dlopen(), but the
Modula-2 frontend uses a plugin for some extended diagnostics (but that
requires a "real" plugin, with exporting symbols from GCC).

I'm not aware of any abstraction for host shared module opening (to cover
windows for example), I suppose in the end we need to have such a thing
(like libiberty pex_* for execve/wait).  Maybe there's functionality in
gnulib for this.

For now I suggest to look for dlopen(), there's

# Some systems need dlopen
save_LIBS="$LIBS"
LIBS=
AC_SEARCH_LIBS(dlopen, dl) 
DL_LIB="$LIBS"
LIBS="$save_LIBS"
AC_SUBST(DL_LIB)

in gcc/configure.ac, so adding DL_LIB to the crab1 link should possibly
suffice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.