* Steven G. Johnson wrote on Sat, Jun 06, 2009 at 06:40:26PM CEST:
>>> That's why I suggested something like powerpc64-ibm-bluegene, or
>>> possibly powerpc64-ibm-bluegene-{version} if a version can be
>>> detected and is useful.
>>
>> Whoops, that should be powerpc, not powerpc64; all of the Bl
Hi Steven,
* Steven G. Johnson wrote on Sat, Jun 06, 2009 at 05:42:23PM CEST:
> How do the autoconf developers feel about my proposed solution, which
> should allow --host to work normally on BlueGene?
Sounds fairly safe, although it's not a show-stopper to not have it.
Cheers,
Ralf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[moving to autoconf-patches, replies can drop autoconf]
According to jens.schmid...@arcor.de on 4/29/2009 3:40 AM:
> Hi.
Hi Jens, and sorry it has taken me so long to respond to your suggestions.
> There it says in section "Limitation of Shell Built
On Sat, 6 Jun 2009, Steven G. Johnson wrote:
It seems much more reasonable to use the documented --host method
for cross-compiling (plus specifying CC etcetera since
supercomputers use nonstandard compiler names and often give the
user a choice among several compilers), the same as cross-compi
Christian Rössel wrote:
So, all packages that you might potentially want to cross-compile onto
supercomputers, from guile to libpng to fftw, are supposed to add this
macro to their configure.ac files?
Of course not. Many applications doesn't mean all applications.
But then I fail to see th
Steven G. Johnson schrieb:
Christian Rössel wrote:
Therefore I'm not sure if my macro will be general enough to be
included in config.guess. But a macro
AC_SET_HOST_FOR_CROSS_COMPILE_SUPERCOMPUTERS will be useful for many
applications.
So, all packages that you might potentially want to cros
Christian Rössel wrote:
I don't think that this is a workaround.
Being documented and a workaround are not mutually exclusive: just
because it is documented that you can override a check doesn't mean that
it is okay if the check doesn't work the way it is supposed to. You
could use the same
Steven G. Johnson schrieb:
Christian Rössel wrote:
Therefore I usually specify --host *and* --build if I want to cross
compile. If $host != $build, configure sets cross_compiling to yes
Ah yes, that is an easier workaround than hacking the configure script.
Hi Steven,
I don't think that th
Steven G. Johnson wrote:
Steven G. Johnson wrote:
That's why I suggested something like powerpc64-ibm-bluegene, or
possibly powerpc64-ibm-bluegene-{version} if a version can be detected
and is useful.
Whoops, that should be powerpc, not powerpc64; all of the BlueGene
machines apparently run
Steven G. Johnson wrote:
That's why I suggested something like powerpc64-ibm-bluegene, or
possibly powerpc64-ibm-bluegene-{version} if a version can be detected
and is useful.
Whoops, that should be powerpc, not powerpc64; all of the BlueGene
machines apparently run 32-bit PowerPC 4xx process
Steven G. Johnson wrote:
It matters not as the host alias you pass to --host, but definitely for
macros like those from Libtool which decide things based on $host. In
the other thread, powerpc-bgp-linux seemed like a sensible thing. But
This doesn't make sense to me, because the compute nodes
Ralf Wildenhues wrote:
One simple but a bit ugly workaround would be to
./configure cross_compiling=yes
This doesn't work. The configure script ignores any pre-existing value
of cross_compiling.
How effective and efficient would such a test be? IOW, are we sure
writing to a file is suff
Ralf Wildenhues wrote:
* Christian Rössel wrote on Sat, Jun 06, 2009 at 08:52:31AM CEST:
at the moment I'm just thinking of an external macro that sets $host if
it is not set by the user. Depending on $cpu and $os of the build system
you check for some special directories (e.g. /bgsys for Blu
Christian Rössel wrote:
Therefore I usually specify --host *and* --build if I want to cross
compile. If $host != $build, configure sets cross_compiling to yes
Ah yes, that is an easier workaround than hacking the configure script.
However, this doesn't change the fact that there is a bug: aut
Hi, I noticed a failure of the "checking whether we are cross
compiling" on BlueGene/L, where it erroneously decides that it is
*not* cross-compiling when in fact it *is*. I'm willing to submit a
patch for this (my copyright assignment is on file), but first I
wanted to get some feedback f
* Christian Rössel wrote on Sat, Jun 06, 2009 at 08:52:31AM CEST:
> at the moment I'm just thinking of an external macro that sets $host if
> it is not set by the user. Depending on $cpu and $os of the build system
> you check for some special directories (e.g. /bgsys for Blue Gene/P).
> Usua
16 matches
Mail list logo
