This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]