RE: How to specify multiple OSDIRNAME suffixes for multilib (Multilib usage with MPX)?

["Terry Guo" <terry dot guo at arm dot com>]

> -----Original Message-----
> From: Ilya Enkovich [mailto:enkovich.gnu@gmail.com]
> Sent: Monday, August 12, 2013 4:37 PM
> To: Terry Guo
> Cc: GCC Development
> Subject: Re: How to specify multiple OSDIRNAME suffixes for multilib
> (Multilib usage with MPX)?
> 
> Hi Terry,
> 
> Thanks a lot for your reply! I suppose I have to introduce some new option
> like MULTILIB_COMPATIBLE to produce additional search locations for
> libraries. Does it sound reasonable? Any advice on implementation?
> 
> Thanks,
> Ilya
> 

Make sense to me. And I think the feature you mentioned can cover
MULTILIB_REUSE, so to keep things simple, I would prefer to unifying them
into one term, either MULTILIB_COMPATIBLE or MULTILIB_REUSE. I am ok with
both names.

In terms of implementation, I think gcc as a driver program only decides the
path to libraries based on command line options and multilib configuration,
the linker will finally search the libraries and link them together. When
MULTILIB_COMPATIBLE is provided, gcc can select more than one paths and pass
them to linker. When there is only one compatible library, the linker can
find it by searching all paths, the whole thing can work. But when there are
more than one compatible libraries spread in different paths, I am not sure
it works. You can try it out.

BR,
Terry

> 2013/8/12 Terry Guo <terry.guo@arm.com>:
> >
> >
> >> -----Original Message-----
> >> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf
> >> Of Ilya Enkovich
> >> Sent: Friday, August 09, 2013 8:37 PM
> >> To: GCC Development
> >> Subject: How to specify multiple OSDIRNAME suffixes for multilib
> >> (Multilib usage with MPX)?
> >>
> >> Hi,
> >>
> >> I'm currently trying to create multilib libraries compiled with MPX.
> >> The main difference with existing multilib variants on i386 target is
> >> that new targets (32/mpx, 64/mpx) are compatible with old variants
> >> (32, 64). Also we should not prevent user from using mpx if he does
> >> not have MPX variants for some libraries - legacy versions should be
> >> used instead. Thus we need to check several suffixes instead of one.
> >> E.g. for 64bit MPX binary we should firstly check ../lib64/mpx, then
> >> check ../lib64 and finally the default one.
> >>
> >> I looked at MULTILIB_REUSE and thought it might solve my problem
> >> according to documentation: "And for some targets it is better to
> >> reuse an existing multilib than to fall back to default multilib when
> >> there is no corresponding multilib." [1]. So I tried following
> >> declarations:
> >>
> >> MULTILIB_OSDIRNAMES+= m64/fmpx=../lib64/mpx MULTILIB_REUSE =
> >> m64=m64/fmpx
> >>
> >> But it appeared that only the first entry for some options set counts
> >> when multilibs are parsed in gcc.c and my reuse here is just ignored.
> >>
> >> Is it a wrong implementation of MULTILIB_REUSE or my wrong
> >> understanding of this option? Is there a way to implement mpx
> >> multilibs still allowing legacy ones when some mpx libs are missing?
> >>
> >> [1] http://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target-
> >> Fragment
> >>
> >> Thanks,
> >> Ilya
> >
> > Hi Ilya,
> >
> > Sorry for the later response. I am the author of MULTILIB_REUSE. So
> > far this feature is not flexible enough to meet your requirement. It
> > can't dynamically decide to choose m64/fmpx if such libraries are
> > there, then secondly choose m64 if m64/fmpx don't exist. This feature
> > only makes a static decision. The following statement:
> >  MULTILIB_REUSE = m64=m64/fmpx
> > means that when options m64 and fmpx are given, we should reuse
> > libraries for m64 always. And for this purpose, we also need:
> > MULTILIB_EXCEPTIONS = m64/fmpx to make sure libraries for "m64 fmpx"
> > won't be built.
> >
> > If m64/fmpx isn't excluded, the MULTILIB_REUSE will think the required
> > libraries are there and no need to reuse.
> >
> > IMHO, the way used by gcc to select multilib is based on string match
> > rather than detecting the existence of libraries. So the flexible way
> > like you wanted isn't supported yet.
> >
> > BR,
> > Terry
> >
> >
> >
> >