Re: problem with parallel make

Re: problem with parallel make

[Ulrich Weigand]

Josef Zlomek wrote:

>> This is more believable.  The problem is probably caused by the config.cache
>> shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
>> thing there, we'll fall apart later in libffi.
>
>Yes, that will be the reason.

>> In any case, please post the configure and make commands you are using,
>> including any environment variables.
>
>../configure --enable-checking --enable-languages=c,c++,objc,f77
>make -j2 bootstrap 

Does it work with --enable-serial-configure ?

Without this flag, I've had all sorts of weird problems with parallel
bootstrap; apparently access to the shared config.cache is not properly
synchronized between configures running in parallel ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

"Ulrich Weigand" <weigand@i1.informatik.uni-erlangen.de> writes:

> Josef Zlomek wrote:
>
>>> This is more believable.  The problem is probably caused by the config.cache
>>> shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
>>> thing there, we'll fall apart later in libffi.
>>
>>Yes, that will be the reason.
>
>>> In any case, please post the configure and make commands you are using,
>>> including any environment variables.
>>
>>../configure --enable-checking --enable-languages=c,c++,objc,f77
>>make -j2 bootstrap 
>
> Does it work with --enable-serial-configure ?

Never heard about that flag before ;-).

> Without this flag, I've had all sorts of weird problems with parallel
> bootstrap; apparently access to the shared config.cache is not properly
> synchronized between configures running in parallel ...

Using that flag it failed even with make -j4 on one of my systems
where it worked before :-(

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: problem with parallel make

[Daniel Jacobowitz]

On Mon, Oct 20, 2003 at 09:55:38PM +0200, Ulrich Weigand wrote:
> Josef Zlomek wrote:
> 
> >> This is more believable.  The problem is probably caused by the config.cache
> >> shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
> >> thing there, we'll fall apart later in libffi.
> >
> >Yes, that will be the reason.
> 
> >> In any case, please post the configure and make commands you are using,
> >> including any environment variables.
> >
> >../configure --enable-checking --enable-languages=c,c++,objc,f77
> >make -j2 bootstrap 
> 
> Does it work with --enable-serial-configure ?
> 
> Without this flag, I've had all sorts of weird problems with parallel
> bootstrap; apparently access to the shared config.cache is not properly
> synchronized between configures running in parallel ...

More likely, the particular order serial-configure forces happens to
work and the one that is being chosen by make doesn't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

Daniel Jacobowitz <drow@mvista.com> writes:

> On Mon, Oct 20, 2003 at 09:55:38PM +0200, Ulrich Weigand wrote:
>> Josef Zlomek wrote:
>> 
>> >> This is more believable.  The problem is probably caused by the config.cache
>> >> shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
>> >> thing there, we'll fall apart later in libffi.
>> >
>> >Yes, that will be the reason.
>> 
>> >> In any case, please post the configure and make commands you are using,
>> >> including any environment variables.
>> >
>> >../configure --enable-checking --enable-languages=c,c++,objc,f77
>> >make -j2 bootstrap 
>> 
>> Does it work with --enable-serial-configure ?
>> 
>> Without this flag, I've had all sorts of weird problems with parallel
>> bootstrap; apparently access to the shared config.cache is not properly
>> synchronized between configures running in parallel ...
>
> More likely, the particular order serial-configure forces happens to
> work and the one that is being chosen by make doesn't.

Might be - but what can be done to fix this?  We shouldn't forbid make
-j2 on some platforms...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Daniel Jacobowitz <drow@mvista.com> writes:

> > ../configure --enable-checking --enable-languages=c,c++,objc,f77
> > make -j2 bootstrap 

> Then, if CC needs -m64 in order to emit 64-bit code, how is 32-bit code
> being built or -m64 being specified?  There's something you're not
> telling me :)

This is a bi-arch compiler:

- 64-bit code is generated by default, so no need for -m64.
- -m32 is needed for 32-bit code and enabled by default.

It's really just those two commands.  GCC is clever enough to add -m32
itself for x86_64 (see config/i386/t-linux64)

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: problem with parallel make

[Josef Zlomek]

> > > This is more believable.  The problem is probably caused by the config.cache
> > > shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
> > > thing there, we'll fall apart later in libffi.
> > 
> > Yes, that will be the reason.
> > 
> > > You mean libf2c,
> > > though, don't you?
> > 
> > Yes.
> > 
> > > In any case, please post the configure and make commands you are using,
> > > including any environment variables.
> > 
> > ../configure --enable-checking --enable-languages=c,c++,objc,f77
> > make -j2 bootstrap 
> 
> Then, if CC needs -m64 in order to emit 64-bit code, how is 32-bit code
> being built or -m64 being specified?

When using multilibs (which is default for x86-64, and probably for
other 64/32 bi-architectures) the 32-bit libraries are compiled with
"-m32". The "-m32" is missing in ac_cv_prog_CC

Josef

Re: problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Josef Zlomek <zlomekj@suse.cz> writes:

>> In any case, please post the configure and make commands you are using,
>> including any environment variables.
>
> ../configure --enable-checking --enable-languages=c,c++,objc,f77
> make -j2 bootstrap 

Just one note: This seems to be specific to bi-arch (or perhaps
multi-arch) systems!

Cheers,
Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: problem with parallel make

[Daniel Jacobowitz]

On Mon, Oct 20, 2003 at 09:21:57PM +0200, Josef Zlomek wrote:
> > > 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> > > 
> > >         * aclocal.m4: Include acx.m4 and no-executables.m4.
> > >         (libiberty_AC_FUNC_STRNCMP): Use AC_LIBOBJ.
> > >         (LIB_AC_PROG_CC): Remove.
> > >         * configure.in: Update AC_PREREQ to 2.57.  Use GCC_NO_EXECUTABLES.
> > >         Use AC_PROG_CC and set ac_libiberty_warn_cflags instead of using
> > >         LIB_AC_PROG_CC.  Use AC_LIBOBJ.  Call AC_ISC_POSIX later, only if
> > >         performing link tests.
> > >         * configure: Regenerated.
> > > 
> > > I am wondering how libiberty change could affect build failure in libffi:
> > > 
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lsystem.o' is incompatible with i386:x86-64 output
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lflush.o' is incompatible with i386:x86-64 output
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lftell.o' is incompatible with i386:x86-64 output
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lfseek.o' is incompatible with i386:x86-64 output
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Laccess.o' is incompatible with i386:x86-64 output
> > > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lbesj0.o' is incompatible with i386:x86-64 output
> > 
> > This is more believable.  The problem is probably caused by the config.cache
> > shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
> > thing there, we'll fall apart later in libffi.
> 
> Yes, that will be the reason.
> 
> > You mean libf2c,
> > though, don't you?
> 
> Yes.
> 
> > In any case, please post the configure and make commands you are using,
> > including any environment variables.
> 
> ../configure --enable-checking --enable-languages=c,c++,objc,f77
> make -j2 bootstrap 

Then, if CC needs -m64 in order to emit 64-bit code, how is 32-bit code
being built or -m64 being specified?  There's something you're not
telling me :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem with parallel make

[Josef Zlomek]

> > 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> > 
> >         * aclocal.m4: Include acx.m4 and no-executables.m4.
> >         (libiberty_AC_FUNC_STRNCMP): Use AC_LIBOBJ.
> >         (LIB_AC_PROG_CC): Remove.
> >         * configure.in: Update AC_PREREQ to 2.57.  Use GCC_NO_EXECUTABLES.
> >         Use AC_PROG_CC and set ac_libiberty_warn_cflags instead of using
> >         LIB_AC_PROG_CC.  Use AC_LIBOBJ.  Call AC_ISC_POSIX later, only if
> >         performing link tests.
> >         * configure: Regenerated.
> > 
> > I am wondering how libiberty change could affect build failure in libffi:
> > 
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lsystem.o' is incompatible with i386:x86-64 output
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lflush.o' is incompatible with i386:x86-64 output
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lftell.o' is incompatible with i386:x86-64 output
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lfseek.o' is incompatible with i386:x86-64 output
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Laccess.o' is incompatible with i386:x86-64 output
> > /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lbesj0.o' is incompatible with i386:x86-64 output
> 
> This is more believable.  The problem is probably caused by the config.cache
> shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
> thing there, we'll fall apart later in libffi.

Yes, that will be the reason.

> You mean libf2c,
> though, don't you?

Yes.

> In any case, please post the configure and make commands you are using,
> including any environment variables.

../configure --enable-checking --enable-languages=c,c++,objc,f77
make -j2 bootstrap 

Josef

Re: problem with parallel make

[Daniel Jacobowitz]

On Mon, Oct 20, 2003 at 09:00:55PM +0200, Josef Zlomek wrote:
> > > >> building with multilibs on x86_64-linux-gnu I get a build failure with
> > > >> a parallel make (-j2 -l7) on my dual Opteron system:
> > > >> /usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
> > > >>  i386:x86-64 output
> > > >
> > > > The bug only apperas when -j2 is used, with -j4 it is gone. I expect when more
> > > > processes are used something gets build soon enough.
> > > >
> > > > Following patch caused or exposed it.
> > > >
> > > > 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> > > >
> > > >         * configure.in: Set RAW_CXX_FOR_TARGET if unset.
> > > >         * configure: Regenerated.
> > > >
> > > > Josef
> > > 
> > > Thanks for tracking this down.  Daniel and Nathanael, do you have any
> > > ideas on how to fix this?
> > 
> > It must be an exposed rather than created... RAW_CXX_FOR_TARGET used to
> > be left unset, which would cause build failures in my environment.  I
> > can't see how this could cause -m32 to disappear, especially not from
> > CC.
> 
> I'm sorry I identified the wrong patch.
> According to binary search it should be this patch from libiberty/:
> 
> 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * aclocal.m4: Include acx.m4 and no-executables.m4.
>         (libiberty_AC_FUNC_STRNCMP): Use AC_LIBOBJ.
>         (LIB_AC_PROG_CC): Remove.
>         * configure.in: Update AC_PREREQ to 2.57.  Use GCC_NO_EXECUTABLES.
>         Use AC_PROG_CC and set ac_libiberty_warn_cflags instead of using
>         LIB_AC_PROG_CC.  Use AC_LIBOBJ.  Call AC_ISC_POSIX later, only if
>         performing link tests.
>         * configure: Regenerated.
> 
> I am wondering how libiberty change could affect build failure in libffi:
> 
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lsystem.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lflush.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lftell.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lfseek.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Laccess.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lbesj0.o' is incompatible with i386:x86-64 output

This is more believable.  The problem is probably caused by the config.cache
shared by libiberty and libffi; if autoconf 2.57 is putting the wrong
thing there, we'll fall apart later in libffi.  You mean libf2c,
though, don't you?

In any case, please post the configure and make commands you are using,
including any environment variables.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem with parallel make

[Josef Zlomek]

> > >> building with multilibs on x86_64-linux-gnu I get a build failure with
> > >> a parallel make (-j2 -l7) on my dual Opteron system:
> > >> /usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
> > >>  i386:x86-64 output
> > >
> > > The bug only apperas when -j2 is used, with -j4 it is gone. I expect when more
> > > processes are used something gets build soon enough.
> > >
> > > Following patch caused or exposed it.
> > >
> > > 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> > >
> > >         * configure.in: Set RAW_CXX_FOR_TARGET if unset.
> > >         * configure: Regenerated.
> > >
> > > Josef
> > 
> > Thanks for tracking this down.  Daniel and Nathanael, do you have any
> > ideas on how to fix this?
> 
> It must be an exposed rather than created... RAW_CXX_FOR_TARGET used to
> be left unset, which would cause build failures in my environment.  I
> can't see how this could cause -m32 to disappear, especially not from
> CC.

I'm sorry I identified the wrong patch.
According to binary search it should be this patch from libiberty/:

2003-08-27  Daniel Jacobowitz  <drow@mvista.com>

        * aclocal.m4: Include acx.m4 and no-executables.m4.
        (libiberty_AC_FUNC_STRNCMP): Use AC_LIBOBJ.
        (LIB_AC_PROG_CC): Remove.
        * configure.in: Update AC_PREREQ to 2.57.  Use GCC_NO_EXECUTABLES.
        Use AC_PROG_CC and set ac_libiberty_warn_cflags instead of using
        LIB_AC_PROG_CC.  Use AC_LIBOBJ.  Call AC_ISC_POSIX later, only if
        performing link tests.
        * configure: Regenerated.

I am wondering how libiberty change could affect build failure in libffi:

/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lsystem.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lflush.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lftell.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lfseek.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Laccess.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `libE77/.libs/Lbesj0.o' is incompatible with i386:x86-64 output

Josef

Re: problem with parallel make

[Daniel Jacobowitz]

On Sat, Oct 18, 2003 at 04:23:25PM +0200, Andreas Jaeger wrote:
> Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz> writes:
> 
> >> building with multilibs on x86_64-linux-gnu I get a build failure with
> >> a parallel make (-j2 -l7) on my dual Opteron system:
> >> /usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
> >>  i386:x86-64 output
> >
> > The bug only apperas when -j2 is used, with -j4 it is gone. I expect when more
> > processes are used something gets build soon enough.
> >
> > Following patch caused or exposed it.
> >
> > 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
> >
> >         * configure.in: Set RAW_CXX_FOR_TARGET if unset.
> >         * configure: Regenerated.
> >
> > Josef
> 
> Thanks for tracking this down.  Daniel and Nathanael, do you have any
> ideas on how to fix this?

It must be an exposed rather than created... RAW_CXX_FOR_TARGET used to
be left unset, which would cause build failures in my environment.  I
can't see how this could cause -m32 to disappear, especially not from
CC.

> 
> Cheers,
> Andreas
> 
> >> The problem is that -m32 is not passed to GCC.  If I run a sequential
> >> build, this works for me, just the parallel one fails on this machine
> >> (it works on another where I tested it).
> >> 
> >> Looking at x86_64-suse-linux-gnu/32/config.cache I noticed:
> >> 
> >> ac_cv_prog_CC=${ac_cv_prog_CC='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/
> >>  -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-sus
> >> e-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -isys
> >> tem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include'}
> >> ac_cv_prog_CPP=${ac_cv_prog_CPP='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gc
> >> c/ -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-s
> >> use-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -is
> >> ystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include -E'}
> >> 
> >> So, the -m32 is missing.  But it's there for CXXCPP:
> >> ac_cv_prog_CXXCPP=${ac_cv_prog_CXXCPP='/builds/gcc/misc/gcc/xgcc -shared-libgcc 
> >> -B/builds/gcc/misc/gcc/ -nostdinc++ -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/
> >> libstdc++-v3/src -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/libstdc++-v3/src/.l
> >> ibs -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-
> >> suse-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -i
> >> system /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include  -m32 -E'}
> >
> >
> 
> Andreas
> -- 
>  Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
>   SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz> writes:

>> building with multilibs on x86_64-linux-gnu I get a build failure with
>> a parallel make (-j2 -l7) on my dual Opteron system:
>> /usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
>>  i386:x86-64 output
>
> The bug only apperas when -j2 is used, with -j4 it is gone. I expect when more
> processes are used something gets build soon enough.
>
> Following patch caused or exposed it.
>
> 2003-08-27  Daniel Jacobowitz  <drow@mvista.com>
>
>         * configure.in: Set RAW_CXX_FOR_TARGET if unset.
>         * configure: Regenerated.
>
> Josef

Thanks for tracking this down.  Daniel and Nathanael, do you have any
ideas on how to fix this?

Cheers,
Andreas

>> The problem is that -m32 is not passed to GCC.  If I run a sequential
>> build, this works for me, just the parallel one fails on this machine
>> (it works on another where I tested it).
>> 
>> Looking at x86_64-suse-linux-gnu/32/config.cache I noticed:
>> 
>> ac_cv_prog_CC=${ac_cv_prog_CC='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/
>>  -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-sus
>> e-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -isys
>> tem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include'}
>> ac_cv_prog_CPP=${ac_cv_prog_CPP='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gc
>> c/ -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-s
>> use-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -is
>> ystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include -E'}
>> 
>> So, the -m32 is missing.  But it's there for CXXCPP:
>> ac_cv_prog_CXXCPP=${ac_cv_prog_CXXCPP='/builds/gcc/misc/gcc/xgcc -shared-libgcc 
>> -B/builds/gcc/misc/gcc/ -nostdinc++ -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/
>> libstdc++-v3/src -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/libstdc++-v3/src/.l
>> ibs -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-
>> suse-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -i
>> system /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include  -m32 -E'}
>
>

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: problem with parallel make

[Josef Zlomek]

> building with multilibs on x86_64-linux-gnu I get a build failure with
> a parallel make (-j2 -l7) on my dual Opteron system:
> /usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
>  i386:x86-64 output

The bug only apperas when -j2 is used, with -j4 it is gone. I expect when more
processes are used something gets build soon enough.

Following patch caused or exposed it.

2003-08-27  Daniel Jacobowitz  <drow@mvista.com>

        * configure.in: Set RAW_CXX_FOR_TARGET if unset.
        * configure: Regenerated.

Josef

> The problem is that -m32 is not passed to GCC.  If I run a sequential
> build, this works for me, just the parallel one fails on this machine
> (it works on another where I tested it).
> 
> Looking at x86_64-suse-linux-gnu/32/config.cache I noticed:
> 
> ac_cv_prog_CC=${ac_cv_prog_CC='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/
>  -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-sus
> e-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -isys
> tem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include'}
> ac_cv_prog_CPP=${ac_cv_prog_CPP='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gc
> c/ -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-s
> use-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -is
> ystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include -E'}
> 
> So, the -m32 is missing.  But it's there for CXXCPP:
> ac_cv_prog_CXXCPP=${ac_cv_prog_CXXCPP='/builds/gcc/misc/gcc/xgcc -shared-libgcc 
> -B/builds/gcc/misc/gcc/ -nostdinc++ -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/
> libstdc++-v3/src -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/libstdc++-v3/src/.l
> ibs -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-
> suse-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -i
> system /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include  -m32 -E'}

problem with parallel make

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]


building with multilibs on x86_64-linux-gnu I get a build failure with
a parallel make (-j2 -l7) on my dual Opteron system:
/usr/bin/ld: warning: i386 architecture of input file `.libs/allchblk.o' is incompatible with
 i386:x86-64 output

The problem is that -m32 is not passed to GCC.  If I run a sequential
build, this works for me, just the parallel one fails on this machine
(it works on another where I tested it).

Looking at x86_64-suse-linux-gnu/32/config.cache I noticed:

ac_cv_prog_CC=${ac_cv_prog_CC='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/
 -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-sus
e-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -isys
tem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include'}
ac_cv_prog_CPP=${ac_cv_prog_CPP='/builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gc
c/ -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-s
use-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -is
ystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include -E'}

So, the -m32 is missing.  But it's there for CXXCPP:
ac_cv_prog_CXXCPP=${ac_cv_prog_CXXCPP='/builds/gcc/misc/gcc/xgcc -shared-libgcc 
-B/builds/gcc/misc/gcc/ -nostdinc++ -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/
libstdc++-v3/src -L/builds/gcc/misc/x86_64-suse-linux-gnu/32/libstdc++-v3/src/.l
ibs -B/opt/gcc/3.4-devel/x86_64-suse-linux-gnu/bin/ -B/opt/gcc/3.4-devel/x86_64-
suse-linux-gnu/lib/ -isystem /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/include -i
system /opt/gcc/3.4-devel/x86_64-suse-linux-gnu/sys-include  -m32 -E'}

What's wrong here?  Any ideas how to fix this?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]