Re: fatal error: gnu/stubs-32.h: No such file
Jonathan Wakely writes: > On 31 July 2013 20:44, Matthias Klose wrote: >> if you mention distribution specific packages, please add the ones needed for >> some distributions. For Debian/Ubuntu this would be g++-multilib if the >> architecture is multilib'ed, g++ otherwise. > That's not the package that provides gnu/stubs-32.h, is it? I thought > it was something like libc6-dev-i386? Please correct > http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h if I'm wrong. gcc-multilib and g++-multilib depend on all the various packages that you need to have. They will, among other things, install libc6-dev-i386. For example, on a current wheezy system, you will see the following dependency chain: gcc-multilib -> gcc-4.7-multilib -> libc6-dev-i386 but also various other things like lib32gcc1. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts
Arnaud Charlet writes: > That's wrong. The above is > $(LN_S) /full/path/to/a_file a_dir > which is quite different from > $(LN_S) a_file a_dir > and will work equally well with ln or ln -s or cp -p. This is not historically portable for ln -s. Passing in a directory as the second argument to ln and expecting that to be equivalent to ln -s /path/to/file /path/to/directory/file (in other words, to use the basename of the first argument) was originally behavior one could only rely on with GNU utilities. I remember modifying software to remove that assumption when porting to various versions of UNIX. Since then, the behavior you're relying on has been adopted by POSIX, and I think all or nearly all of the UNIX vendors have implemented it in their own versions of ln, so these days you may no longer care. But there definitely were UNIX systems where this didn't work and would result in an error saying that a_dir already exists. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
