https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|gcc_lib_dir is missing from |gcc_lib_dir is missing from
|libgccjit's search path |libgccjit's search path
| |when driver is not
| |installed
--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Log of our chat about this on IRC:
<doko> dmalcolm: so the driver has to be present to use libgccjit?
<dmalcolm> doko: if you call gcc_jit_context_set_bool_use_external_driver
(ctxt, 1) it does; it defaults to using an internal driver though iirc
* dmalcolm checks
<dmalcolm> yup
<doko> dmalcolm: looking at https://paste.ubuntu.com/p/Sz2hJ8rKZX/ the
external driver is called despite explicitly calling
gcc_jit_context_set_bool_use_external_driver (ctxt, 0); at least that's how I
interpret the debug output
<dmalcolm> doko: I don't think it is. I see calls that invoke_driver is
calling invoke_embedded_driver
<dmalcolm> s/calls //
<doko> dmalcolm: no, https://paste.ubuntu.com/p/KZV5jJQNRf/ this is with the
x86_64-linux-gnu-gcc-9 removed
<dmalcolm> bother
<dmalcolm> doko: maybe try passing gcc_jit_context_add_command_line_option
(ctxt, "-v") or similar to get a more verbose output from the embedded driver
<dmalcolm> s/passing/calling/
<dmalcolm> doko: sorry, gcc_jit_context_add_driver_option, I meant to say
<doko> dmalcolm: https://paste.ubuntu.com/p/vRKRqXy65Y/ this is clearly output
from the external driver ...
<doko> or maybe I'm misunderstanding what the internal driver is, if it calls
the external one
<dmalcolm> doko: the "internal driver" is gcc.o linked inside libgccjit.so
It's the same code as the regular "gcc" binary, but called as a function. The
log shows it calling "invoke_embedded_driver"
<dmalcolm> doko: so yes, it looks remarkably like as if it had fork&exec-ed
gcc, but it's running that code in-process
<doko> dmalcolm: ok, but why do I see these errors, when I remove the external
driver?
<dmalcolm> doko: good question
<dmalcolm> doko: I see in that log:
<dmalcolm> COMPILER_PATH=
<dmalcolm>
LIBRARY_PATH=/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/lib/:/usr/lib/
<dmalcolm> doko: does that change when reinstalling the external driver?
<dmalcolm> doko: presumably you're not uninstalling the .o and libs it's
looking for, right? I'm assuming this is just a "choosing the right directory
to look in" issue
<doko> dmalcolm: yes, just removing the driver, nothing else. See
https://paste.ubuntu.com/p/T7J9DDDTqW/ look at COMPILER_PATH and LIBRARY_PATH
<dmalcolm> doko: interesting. It's also calling collect2 vs calling ld
<doko> that explains why it succeeds without the driver, and manually setting
LIBRARY_PATH
<dmalcolm> doko: looking at gcc.c I see various places using gcc_exec_prefix
where it's locating things relative to the driver binary
<dmalcolm> doko: I think make_relative_prefix is looking for the driver based
on PATH
<dmalcolm> doko: when the driver binary is present, the gcc.c code finds its
directory, via get_relative_prefix, and sets gcc_exec_prefix and
gcc_libexec_prefix, I think
<dmalcolm> doko: when the driver binary is not in PATH, it doesn't find it, and
those vars don't get set up
<dmalcolm> doko: does it work if you set GCC_EXEC_PREFIX in the environment?
presumably to /usr/lib/gcc/x86_64-linux-gnu/9/ or somesuch
<doko> dmalcolm: yes
<dmalcolm> doko: I wonder if we can get it work by having it look relative to
the .so, rather than relative to the driver
<dmalcolm> doko: oh, that's not going to work; make_relative_prefix looks for
the thing on the PTH
<dmalcolm> PATH, even
<doko> dmalcolm: yep, that's what I just found as well
<dmalcolm> doko: I think the pertinent comment here is:
<dmalcolm> /* From this point onward, gcc_exec_prefix is non-null if the
toolchain
<dmalcolm> is relocated. The toolchain was either relocated using
GCC_EXEC_PREFIX
<dmalcolm> or an automatically created GCC_EXEC_PREFIX from
<dmalcolm> decoded_options[0].arg. */
<dmalcolm> doko: and the logic for the latter depends on locating
decoded_options[0].arg
<dmalcolm> doko: by finding it on PATH
<doko> ... which doesn't cover libgccjit's use case
<doko> dmalcolm: should libgccjit set GCC_EXEC_PREFIX in the environment when
it's not set?
<dmalcolm> doko: perhaps. But it's good to be relocatable. I'm not sure what
the value it would set it to should be
<dmalcolm> doko: is there a way for a .so to ask: what location am I linked
from?
<dmalcolm> (analogous to how the driver binary is querying PATH to try to find
where it's been run from)
<doko> dmalcolm: /proc/self/maps ?
<dmalcolm> gahh
<dmalcolm> doko: that could work, but sounds like a portability nightmare
<dmalcolm> doko: if this is a purely packaging thing, can we ignore
relocatability for this use-case, and hardcode where the installation path will
be?
<dmalcolm> doko: then have libgccjit set GCC_EXEC_PREFIX to the correct
(hardcoded) path for packaged builds
<doko> dmalcolm: +1, otherwise I would have to add a gcc dependency tp
libgccjit0
<dmalcolm> doko: in Fedora we have a gcc dep for libgccjit
<doko> yes, that's the other option
<doko> dmalcolm: when adding that, where should this go?
<dmalcolm> doko: totally untested:
https://paste.fedoraproject.org/paste/sPA97QW4RkS5LHPjGAcxFg
<dmalcolm> doko: (plus it needs a comment explaining why we're doing it)
<doko> dmalcolm: ok, I'll look into that tomorrow
<dmalcolm> doko: or just add the dep :)
