From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 0859E3858CDB; Mon, 15 Apr 2024 06:21:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0859E3858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713162079;
	bh=vZSzuzGzENpgOQ1qJs1Ai5QgEyoer7BTtyoVkySEDSw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Tw8bkyvL7i1lAs6mg46CttAzjiczNp1VjO7pl/asbx5pEHPmc6maps7svbIVix4t8
	 /VxXmEavXez2TAkxeJliJnAX6qaOFhnPrgrFaXLxCz0y8FK52RDDf2oVFA6sOUK1L2
	 wYzF9RADMeKwRALMqdcwN7SB3Ory4wVh0PrjQ4eQ=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-rust@gcc.gnu.org
Subject: [Bug rust/113499] crab1 fails to link when configuring with
 --disable-plugin
Date: Mon, 15 Apr 2024 06:21:16 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rust
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113499-35322-iSLJevs0Rv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113499-35322@http.gcc.gnu.org/bugzilla/>
References: <bug-113499-35322@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-rust.gcc.gnu.org>

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

--- 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 re=
quire
> > > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the la=
tter's
> > > not available we have to auto-disable Rust language front end if enab=
led
> > > '--enable-languages=3Dall' vs. raise a 'configure'-time error if enab=
led via
> > > explicit '--enable-languages=3Drust'?
> >=20
> > 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?
> >=20
> > Being able to dlopen() is something different.
>=20
> 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().
>=20
> 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=3D"$LIBS"
LIBS=3D
AC_SEARCH_LIBS(dlopen, dl)=20
DL_LIB=3D"$LIBS"
LIBS=3D"$save_LIBS"
AC_SUBST(DL_LIB)

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

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