NightStrike wrote: > Is that why I get these messages while at the all-gmp stage: > > configure: WARNING: cannot check for properly working vsnprintf when > cross compiling, will assume it's ok Well, are you cross compiling? If gmp's configury wants to do a runtime check it's not going to be possible in a cross situation regardless of any other factors, so I don't see how this relates to an in-tree gmp build at all. > libtool: link: warning: undefined symbols not allowed in > none-pc-cygwin shared libraries I don't understand why you're even seeing this at all as the dir was configured with --disable-shared. When you see that message it means libtool will be creating only static libraries, which is what is supposed to happen here. Are you sure this is in a gmp or mpfr dir? > And these while at the all-mpfr stage: > > configure: WARNING: In the future, Autoconf will not detect cross-tools > whose name does not start with the host triplet. If you think this > configuration is useful to you, please write to autoconf@xxxxxxxx And this seems irrelevant too because toplevel explicitly passes down CC to the sub-configure so it shouldn't matter if autoconf can't guess CC correctly. If there are other variables for build tools that need to be passed down (e.g. CXX, AS, AR) that currently aren't then toplevel needs to be modified to do so, as it has all that information. Autoconf shouldn't need to guess. > Is it possible to address that in any way? Will Autoconf be changing > such that compiling gmp/mpfr in the gcc tree isn't possible? I don't really understand why you'd think that. Autoconf is a tool at the hand of the gcc developers, not the other way around. There is no way for changes in future autoconf versions to affect the gcc tree unless the entire tree is upgraded to that newer autoconf version. At the moment the tree is pinned to 2.59 and this is not likely to change often because changing it requires that all developers who might check in a patch that affects generated files must have the exact prescribed version installed on their machine. This is a hardship for a project with hundreds of developers. Even if autoconf behavior did change and even if the gcc tree did switch to a newer autoconf, it still doesn't follow that in-tree gmp/mpfr bootstrap would no longer be possible. File a PR, somebody would fix it. Toplevel has all the necessary information, so it really shouldn't matter whether the sub-configure can or can't detect the correct tools. I did a little archaeology on this warning and it's been around for about three and a half years (added 2004-03-19). The discussion is here: <http://lists.gnu.org/archive/html/autoconf-patches/2004-03/msg00014.html>. Already when the patch was proposed there were many false positives in the sense that technically any time build does not exactly equal host you are cross compiling, but sometimes even though they're different in the string-compare sense they're still compatible (or even the same platform), and so using unprefixed tools is correct. Therefore I don't see the warned behavior becoming reality any time soon. > Why > would you want to strip out the CPU optimizations anyway? If target > is known to the top-level configure (for instance, in my case, it's > x86_64-pc-mingw32), why can't that be passed down to the gmp/mpfr > configures? I don't know. You would have to ask the person that wrote the code. My guess is that the in-tree bootstrap of gmp and mpfr is meant as a kind of last-ditch option for people that for whatever reasons cannot get these libraries installed properly, so selecting the generic implementation guarantees their best chances of success. Also, gmp configury seems to have some nonstandard handling of $host detection based on characteristics of the build system and this may be a way of avoiding that. (It would obviously be unacceptable if someone configured with a generic $host like i686-pc-linux with the intention of running the resulting gcc on any generic x86, but found that it randomly gave invalid instruction faults because of being statically linked to a libgmp that detected that the build machine happened to have been a pentium4 and used the p4 specific implementation.) Brian
