On 02.12.2015 13:29, Rainer Orth wrote:
Exactly: moving AM_ENABLE_MULTILIB up as Matthias suggested sets
cross_compiling=maybe for non-default multilibs early, which should
achieve the desired behaviour. All other libraries that invoke both
macros already do so in this order.
now committed.
2
On Tue, 1 Dec 2015 09:17:48, Ulrich Drepper wrote:
> On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
> > that might be another instance of
> > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
> > Does something like this help?
>
> No, same problem as before. This macro doesn't act
Sorry for replying so late: I'd been away from my mail for an extended
weekend.
Jeff Law writes:
> On 12/01/2015 07:17 AM, Ulrich Drepper wrote:
>> On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
>>> that might be another instance of
>>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064
On 12/01/2015 07:17 AM, Ulrich Drepper wrote:
On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
that might be another instance of
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
Does something like this help?
No, same problem as before. This macro doesn't actually generate any
c
On Tue, Dec 1, 2015 at 10:16 AM, Bernd Edlinger
wrote:
> Your host_alias looks wrong: isn't it equal to your build_alias ?
Yes. The goal is to basically build a native compiler but prevent it
from trying to run any binaries. There is no fine-grained way to tell
the configuration mechanism to ru
Hi,
~/gnu/gcc/configure --prefix=/usr --enable-bootstrap --enable-shared
--enable-host-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-in
On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
> that might be another instance of
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
> Does something like this help?
No, same problem as before. This macro doesn't actually generate any
code in configure.
(add gcc-patches)
On 12/01/2015 08:39 AM, Matthias Klose wrote:
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at the end.
This macro *should* work for cross-compiling but somehow
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
> Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at the end.
This macro *should* work for cross-compiling but somehow it doesn't
work. In libvtv/configure $cross
On 11/30/2015 05:25 PM, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 6:57 PM, Jeff Law wrote:
What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not
anything which obviously requires running the resulting code.
Without AC_USE_SYSTEM_EXTENSIONS one gets:
configure.ac:111:
On Mon, Nov 30, 2015 at 6:57 PM, Jeff Law wrote:
> What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not
> anything which obviously requires running the resulting code.
Without AC_USE_SYSTEM_EXTENSIONS one gets:
configure.ac:111: warning: AC_COMPILE_IFELSE was called before
A
On 11/28/2015 08:42 AM, Ulrich Drepper wrote:
After the Solaris vtv port was added my build of the x86 gcc with x32
support fails. The build is special since the kernel doesn't have x32
support and I cannot directly run x32 binaries (they are run in a kvm
kernel). This is used to work well by c
13 matches
Mail list logo
