Rask Ingemann Lambertsen wrote: >> Perhaps we should turn target-libgfortran off by default for mips*-elf*. > > No. There is a point in excercising the compiler: Testing. In most cases, > you don't find problems with the compiler until you try to compile something.
When building the compiler and its libraries, testing is of incidental benefit; the primary goal is to build things. :-) The testsuite is for testing things. It's great to know that gfortran works for other ELF targets. That means that there must be something a bit odd in the MIPS support somewhere, and I'm sure we can find it and fix it. Thanks for working on the gfortran configure script. I think it would be great to make that work like the libstdc++ script. > This hunk should be left out. And I would prefer that we don't revert the > patch until everything that builds with the patch also builds without the > patch. I don't think that's necessary -- unless these things built with previous releases, in which case I'd be very concerned about making a change that caused fewer things to build. Did this work in 4.2? I don't know, but I'm expecting that it did not? It sounds like we upgraded libtool, and that introduced link-time tests into libstdc++, which caused build failures. So you came up with the top-level patch, which then probably made it possible to build some of the other target libraries that didn't build before for bare metal because they had always depended on link-time tests. Is that correct? We should be conservative about making changes in assumptions. If we're going to change the assumption that target library configure scripts cannot rely on link-time tests when $with_newlib is set, then let's do that consciously. I think it's reasonable to take that position (even though it's not my preference), but I don't want to change the assumption quietly. And, I think libstdc++ is our canonical model of a run-time library; others should follow its lead, until/unless we consciously decide otherwise. I also don't want to see each architecture or run-time library doing things in different ways. GCC's biggest strength is its cross-platform nature; we undermine that every time we do things in slightly different ways within our own individual areas of concentration. I'm in no way criticizing you or your top-level patch. I understand completely why you did what you did and its benefits. But, I want to get everyone on the same page, and until that happens, I want to stick with how things have been in the past. > Additionally, I would prefer we call the option something else than > --with-newlib - suppose there's no newlib for the target. At least the AVR > uses something else. That might be a good idea -- I think we do need to know which C library is in use for at least some of the target libraries. I'm pretty sure that libstdc++ actually depends on --with-newlib meaning that you're using Newlib (rather than some other C library) in that it uses facilities in Newlib that aren't necessarily part of a standard C library. I could be wrong about that, though. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713