On 2009/06/30 14:11, Thiago Macieira wrote: > Simon McVittie wrote: >> On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote: >>> We'll need an architecture key, which is composed by the host OS plus >>> at least the processor main type. >> Multiarch http://lackof.org/taggart/hacking/multiarch/ addresses this by >> taking the CPU and OS (or CPU and kernel+OS) from >> config.guess/config.sub, i.e. >> >> `/usr/share/misc/config.guess | cut -d - -f 1,3-`: >>> i386-linux >>> x86-64-linux >> i386-linux-gnu, x86_64-linux-gnu > > What's the "gnu" part good for? The important thing here is the kernel ABI > and the processor. (This is not a discussion of "Linux" vs "GNU/Linux") > > Unless there's a i386-linux-uclibc that we have to consider...
Well, yes, that's what 'gnu' here means: glibc. Might we come into a case where one system has the app compiled against glibc, and another system has the app compiled against another libc? Maybe, but again unlikely. (That actually would be a problem, since the main app would link against one libc, and the plugin linking against the other, with unpredictable symbol overriding going on.) How much do we care to support this case? Regardless, could still tack the C++ ABI on the end, whether or not you include the libc type. > We can argue as well that we don't want to solve that problem either. If > it works for the free operating systems (where GCC seems to be the rule), > we can be happy. There's certainly value to supporting other combinations, but I'm not so sure about the cost of doing so. I'm less concerned about the naming of the arch-specific dir (sure, throw all sorts of info in there if it's necessary; it's just a mostly-user-invisible identifier anyway), but worried about how apps on a single system that supports multiple arches would deal with looking things up when XDG_LIB_HOME is set. But maybe we can just punt in that case? Something like: "XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/. Implementations which wish to use this default will need to detect the machine architecture, operating system, and C++ ABI [etc.] at compile-time. If XDG_LIB_HOME is set to a particular value, the application shall use that value without regard to the arch-specific directory. Users who do not wish to rely on the default should take care to set this variable appropriately if they run applications on the same machine that are compiled for different architecture/OS/C++-ABI combinations." Or, we could go a different route and not define XDG_LIB_HOME at all, in favor of something like this: "XDG_LIBROOT_HOME [or some other name that distinguishes it] will default to $HOME/.local/lib/. Implementations must append $ARCH_OS_ABI_STRING to that value, which can usually be discovered at compile-time." This actually sounds like a decent route to take to me. The application (or library) that actually knows what arch/OS/ABI/toaster it was compiled for, can decide the arch-specific string, and the spec only needs to define the format of the string and provide examples. A user/sysadmin that wishes to set this won't have to worry about arch-clash issues. -brian _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg