On Fri, Aug 23, 2013 at 01:45:14AM +0930, Alan Modra wrote: > On Thu, Aug 22, 2013 at 10:06:48AM -0400, David Edelsohn wrote: > > What is the purpose of the change to MULTILIB_OSDIRNAMES? Why the > > addition of m64= and m32=? A secondary tmake file is not always set to > > post-process those macros, AFAICT. > > That m64= is the newer syntax that specifies a mapping from a > MUTLILIB_OPTIONS selection. And, yes, without another tmake file this > gives us exactly the same result as before. > > I needed to use the new syntax to specify the correct os dirs when > adding cross-endian multilibs.
Without another tmake file it really is exactly the same as before. old, after applying "make" string gunk MULTILIB_OPTIONS = m64/m32 MULTILIB_OSDIRNAMES = ../lib64 ../lib new MULTILIB_OPTIONS = m64/m32 MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib Either way, -m64 objects use ../lib64 and -m32 ../lib. new with le multilib MULTILIB_OPTIONS = m64/m32 mlittle MULTILIB_OSDIRNAMES = m64=../lib64 m32=../lib m64.mlittle=../lib64le m32.mlittle=../lible Trying to do the same with the old syntax isn't possible, because you must specify 3 elements in MULTILIB_OSDIRNAMES to match the combinations given in MULTILIB_OPTIONS, then the multilib machinery mashes them together. For instance MULTILIB_OPTIONS = m64/m32 le MULTILIB_OSDIRNAMES = ../lib64 ../lib le results in -m64 code to ../lib64 -m32 code to ../lib -m64 -mlittle code to le -m32 -mlittle code to ../lible The reason you don't get ../lib64le for -m64 -mlittle is related to -m64 being the default, -m64 is therefore omitted when compiling, and just the "le" string used for the os multilib dir. -- Alan Modra Australia Development Lab, IBM
