On 25/08/2008, Dave Curtis <[EMAIL PROTECTED]> wrote: > > That makes sense from a cross-compile standpoint. The target for the > executable is not necessarily the same architecture that the compiler is > running on. > > Of course, the binary should be configured for the execution target. But > remember that configure is running on the compile machine, which may not be > the execution target. It probably makes sense for configure to *default* to > the features available on the machine running the configure script, with > user overrides to allow setting tweaks for a different target. It does not > make sense for configure to be checking for compiler features, it should be > checking for machine features. > > This raises the question of when SSE and SSE2 are enabled by gcc's > configure script. I've not looked into it or thought about the philosophy, > but it certainly makes sense to allow the compiler to emit SSE and SSE2 even > when compiling on machines that don't support them in order to enable > cross-compile. But for the common scenario of one user with one machine > with all builds self-hosted, then it would seem like turning off SSE and > SSE2 in gcc's configure script saves some headaches. Did you build your gcc > compilers yourself for these tests or use pre-built packages? >
Hello, I probably wasn't clear enough - it was BRL-CAD's configure that I needed to alter and not GCC's. I built the gcc compiler on the RedHat 7.3 system, and used the operating system supplied gcc on the modern Linux and the FreeBSD 6.2 systems. I do agree that gcc, if specifically requested to do so, should be able to output opcodes that don't execute on the machine that the program was compiled on - I believe that the burden lies on the script calling gcc to select the correct compiler options if it wishes to override the gcc defaults. > BTW -- detection of SSE and SSE2 (among other things) is covered at the low > level by Intel Application Note 485. I suspect configure primitives already > exist to check for SSE and SSE2 -- I'm far from being a configure guru. > Thanks. Although I'm not about to start hacking on configure.ac :-), I've downloaded the document out of interest. Simon. -- Simon Clubley [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ BRL-CAD Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-users
