On 09.05.2012 18:29, Paolo Bonzini wrote: > Il 09/05/2012 17:34, Matthias Klose ha scritto: >>>> So -print-multiarch is like --print-multi-os-directory? >> the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the >> latter >> the part after the `':', e.g. ../lib32 and i386-linux-gnu. > > Yes, of course. > >>>> What is the difference, and where is it documented? >> Not sure how it should be further documented. > > No idea, it is a new concept and people need to understand how it > relates to multilibbing for example, what shortcomings are addressed etc. > > I went through the Debian pages (only cursorily, I admit) and I found > nothing of this.
these are referenced from the http://wiki.debian.org/Multiarch/Tuples https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout http://err.no/debian/amd64-multiarch-3 http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for multiarch, and why Debian thinks that the existing approaches are not sufficient (having name collisions for different architectures or ad hoc names for new architectures like libx32). That may be contentious within the Linux community, but I would like to avoid this kind of discussion here. > Another question I have is related to usage of the option. Are you > supposed to look for libraries in the multilib directories too if the > compiler is multiarch-enabled? Debian/Ubuntu always use /lib for the default MULTIOSDIR, and this needs to be looked up in the future too. The use of locations like ../lib32 will be faded out over time, but I don't see any harm not to have looked up as well. > Or only in /lib/i386-linux-gnu? Which > one takes priority, multiarch or multiosdir? > > From the patch I can guess the intended search path is > /lib/MULTIARCH:/lib/MULTIOSDIR, but I'm not entirely sure about that and > it needs documentation. yes, this is the intended search path. I assume such kind of documentation shouldn't go into invoke.texi. >>>> Should it fail if multiarch support is not compiled in? >> All the -print options always succeed. I would prefer if it just prints the >> empty string if it is not configured (as it does now). > > Will the empty string be a valid output for a multiarch-enabled > compiler? For example "gcc --print-multi-os-directory" and "gcc > --print-multi-directory" on a bi-arch x86-64 compiler will never print > the empty string. Again, I guess the answer is no but I'm not sure. > > If the answer is no, returning the empty string is fine. The answer is no. If multiarch is enabled, then the string is always non-empty and should return a multiarch tuple as defined in http://wiki.debian.org/Multiarch/Tuples. Anything else should be considered an error. > If the answer is yes, and assuming the search path is > /lib/MULTIARCH:/lib/MULTIOSDIR, then programs need to know whether they > need to omit the /lib/MULTIARCH component of the search path. Unrelated, but why would programs hard code this path and not use something like this? gcc -v -E - </dev/null 2>&1 | grep ^LIBRARY_PATH Matthias
