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

2024-03-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

Thomas Schwinge  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  ---
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  "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

2024-03-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499

--- Comment #5 from Richard Biener  ---
(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.