This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 18 Nov 2010 14:36:23 +0000
- Subject: [Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
- Auto-submitted: auto-generated
- References: <bug-46516-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-18 14:36:00 UTC ---
We (for another group of "we") agreed that that's the wrong approach.
Current suggestion my Matz:
15:20 < richi> I wonder why/how it works for libgomp
15:21 < matz> That is included via %:include in the linker_command_spec. That
comes after the multilib paths are ready.
15:21 < matz> But there's (currently) no hook for frontends to include anything
into link_command_spec.
[...]
15:29 < matz> Add a new (frontend-driver) macro: LANG_LINK_LIBS (or something).
In gcc.c handle it similar to STACK_SPLIT_SPEC. (#ifndef -> then empty). In
fortran frontend header #define it to
'%:include(libgfortran.spec)%lib_gfortran)'. in libgfortran.spec don't define
'lib:' but 'lib_gfortran:' (look at libgomp.spec).
15:30 < matz> Similar to STACK_SPLIT_SPEC includes adding it to
LINK_COMMAND_SPEC.
15:31 < matz> And then hack long enough until everything works. But at least
that way libgfortran.spec will be found in the multilib dirs.