On 29.03.2012 22:23, Wietse Venema wrote: [] > Perhaps you can suggest a way for makedefs to parse out the CPU > type from "uname -whatever" and use that in the library search?
This isn't about uname. Uname may return one thing, yet postfix may be building for entirely another -- that's the main motivation behind multiarch. There, the only reasonable thing to do is to try to link an executable - _provided_ that we need to actually verify the two libs in question. But on any modern linux system - and I really mean this, since stuff for libc5 (pre-glibc linux) isn't interesting anymore except of for some historical reasons, and other implementations of libc on linux (uclibc, dietlibc) have -lnsl -lresolv. So the best fix for this stuff is - in my opinion anyway - just assume that -lnsl -lresolv is always there and add it unconditionally on linux2 or linux3. Note again that linux _kernel_ version has very little to do with C library features present. Besides, gcc --print-search-dirs (as already used in makedefs) includes all necessary multiarch directories already. So I'm not really sure why the OP have this problem to start with. Here's the content of SEARCHDIRS variable from makedefs script on my 32bit system: /lib /lib/i386-linux-gnu /usr/lib /usr/lib/i386-linux-gnu and here's how it looks like when setting CC="gcc -m64" before invoking makedefs: /lib /lib64 /lib/x86_64-linux-gnu /usr/lib /usr/lib64 /usr/lib/x86_64-linux-gnu > The reason I ask this is that it makes little sense to hard-code > all possible architecture names in this script. That'd be wrong, because some of these libs wont work on current arch directly anyway, and may be unrelated to the postfix build. Thanks, /mjt