Potential breakage in llvm-gcc's ./configure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential breakage in llvm-gcc's ./configure

Joachim Durchholz
(Apologies if this appears twice, it seems to not have made it into the list. I added an update for SVN trunk.)

Just a quick heads-up for 2.2 and SVN trunk:

./configure in the llvm package will work on my amd64 machine
with this command line:

./configure --prefix=$HOME --enable-optimized \
--build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2

Note that the CC and CXX flags are set on the command line, not as
environment variables - trying to submit them via the environment got me
all kinds of breakage.

Also not that this needs to set just --build, not --host (which defaults
to the setting of --build) nor --target (which defaults to whatever
value --host ends up as).


Now the ./configure in llvm-gcc4.2 will choke badly on such a command line.

First, it misinterprets the CC= and CXX= strings as target architecture
names, and continues to complain that it cannot configure for multiple
architectures at once.

Second, it does not default --host or --target to --build.

Third, even with --target and --host explicitly set to
i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The
failing command is

/home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/
-B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/
-isystem /home/jo/i686-pc-linux-gnu/include
-isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I. -I.
-I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/.
-I/home/jo/llvm-gcc-src/gcc/../include
-I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer
-c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O
-o crtbeginT.o

(slightly edited to leave out multiple blanks and line continuation
backslashes).

The error messages are just what I had seen earlier:

/tmp/ccVjR8Qt.s: Assembler messages:
/tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push'
/tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call'
/tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push'
/tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call'


It seems that the ./configure for llvm-gcc is doing some, er, seriously
nonstandard things with autoconf...


This is close to a showstopper for integrating an llvm-gcc bootstrap
into the nightly tester. The llvm-gcc ./configure needs to be called
very differently from the llvm ./configure, and keeping two sets of
options is Not Worth The Trouble, at least IMHO.


Regards,
Jo

P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage
to bootstrap it or run the nightly tester :-D

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Daniel Berlin
>
>  ./configure in the llvm package will work on my amd64 machine
>  with this command line:
>
>  ./configure --prefix=$HOME --enable-optimized \
>  --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2
>
>  Note that the CC and CXX flags are set on the command line, not as
>  environment variables - trying to submit them via the environment got me
>  all kinds of breakage.

Err, you should set them as env vars.
Really.

>
>  Also not that this needs to set just --build, not --host (which defaults
>  to the setting of --build) nor --target (which defaults to whatever
>  value --host ends up as).
>
>
>  Now the ./configure in llvm-gcc4.2 will choke badly on such a command line.
>
>  First, it misinterprets the CC= and CXX= strings as target architecture
>  names, and continues to complain that it cannot configure for multiple
>  architectures at once.
Which is why you should be setting them as env vars :)

>
>  Second, it does not default --host or --target to --build.

This is normal.
Crappy, but normal.

>
>  Third, even with --target and --host explicitly set to
>  i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The
>  failing command is
>
>  /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/
>  -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/
>  -isystem /home/jo/i686-pc-linux-gnu/include
>  -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall
>  -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
>  -Wold-style-definition -isystem ./include -I. -I.
>  -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/.
>  -I/home/jo/llvm-gcc-src/gcc/../include
>  -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0
>  -finhibit-size-directive -fno-inline-functions -fno-exceptions
>  -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer
>  -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O
>  -o crtbeginT.o
>
>  (slightly edited to leave out multiple blanks and line continuation
>  backslashes).
>
>  The error messages are just what I had seen earlier:
>
>  /tmp/ccVjR8Qt.s: Assembler messages:
>  /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push'
>  /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call'
>  /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push'
>  /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call'
>

This is interesting, and I wonder if it appears in gcc itself. If so,
it is a bug.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Joachim Durchholz

Am Montag, den 24.03.2008, 11:37 -0400 schrieb Daniel Berlin:

> >
> >  ./configure in the llvm package will work on my amd64 machine
> >  with this command line:
> >
> >  ./configure --prefix=$HOME --enable-optimized \
> >  --build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2
> >
> >  Note that the CC and CXX flags are set on the command line, not as
> >  environment variables - trying to submit them via the environment got me
> >  all kinds of breakage.
>
> Err, you should set them as env vars.
> Really.

Hm. For some reason, ld kept searching the wrong (64-bit) library paths
when trying to link the 32-bit results.

I just retried and now everything is fine. Mystifying.
Ah well. Probably my first experiments had some stry env var set that
shouldn't have been, derailing the build machinery.

> >  Also not that this needs to set just --build, not --host (which defaults
> >  to the setting of --build) nor --target (which defaults to whatever
> >  value --host ends up as).
> >
> >
> >  Now the ./configure in llvm-gcc4.2 will choke badly on such a command line.
> >
> >  First, it misinterprets the CC= and CXX= strings as target architecture
> >  names, and continues to complain that it cannot configure for multiple
> >  architectures at once.
> Which is why you should be setting them as env vars :)
>
> >
> >  Second, it does not default --host or --target to --build.
>
> This is normal.
> Crappy, but normal.

According to the autoconf docs, this should be everything but normal!
In fact it works for llvm. It's just llvm-gcc that fails to do that
right. (Checked with the config.logs of both runs.)

My best guess is that something is wrong in the .ac file for llvm-gcc,
and the llvm .ac file got it right.

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Joachim Durchholz
In reply to this post by Daniel Berlin
Am Montag, den 24.03.2008, 11:37 -0400 schrieb Daniel Berlin:

> >
> >  Third, even with --target and --host explicitly set to
> >  i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The
> >  failing command is
> >
> >  /home/jo/llvm-gcc-wrk/gcc/xgcc -B/home/jo/llvm-gcc-wrk/gcc/
> >  -B/home/jo/i686-pc-linux-gnu/bin/ -B/home/jo/i686-pc-linux-gnu/lib/
> >  -isystem /home/jo/i686-pc-linux-gnu/include
> >  -isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall
> >  -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> >  -Wold-style-definition -isystem ./include -I. -I.
> >  -I/home/jo/llvm-gcc-src/gcc -I/home/jo/llvm-gcc-src/gcc/.
> >  -I/home/jo/llvm-gcc-src/gcc/../include
> >  -I/home/jo/llvm-gcc-src/gcc/../libcpp/include -g0
> >  -finhibit-size-directive -fno-inline-functions -fno-exceptions
> >  -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer
> >  -c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O
> >  -o crtbeginT.o
> >
> >  (slightly edited to leave out multiple blanks and line continuation
> >  backslashes).
> >
> >  The error messages are just what I had seen earlier:
> >
> >  /tmp/ccVjR8Qt.s: Assembler messages:
> >  /tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push'
> >  /tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call'
> >  /tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push'
> >  /tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call'
> >
>
> This is interesting, and I wonder if it appears in gcc itself. If so,
> it is a bug.

The problem persists even when submitting gcc-4.2 and g++-4.2 via
environment variables per your suggestion.
(The failing xgcc command has slightly different options, and the
reported line numbers differ slightly, but that's all.)

I don't know how to check whether it appears in gcc itself. I don't have
an xgcc command installed other than via llvm.

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Tanya Lattner-2
In reply to this post by Joachim Durchholz

> This is close to a showstopper for integrating an llvm-gcc bootstrap
> into the nightly tester. The llvm-gcc ./configure needs to be called
> very differently from the llvm ./configure, and keeping two sets of
> options is Not Worth The Trouble, at least IMHO.

So you didn't like the suggestion of having the configure for llvm-gcc set
via an environment variable? That avoids having to deal with this directly
in the script. Or am I missing something?

-Tanya


>
>
> Regards,
> Jo
>
> P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage
> to bootstrap it or run the nightly tester :-D
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Joachim Durchholz

Am Montag, den 24.03.2008, 12:06 -0700 schrieb Tanya M. Lattner:
> > This is close to a showstopper for integrating an llvm-gcc bootstrap
> > into the nightly tester. The llvm-gcc ./configure needs to be called
> > very differently from the llvm ./configure, and keeping two sets of
> > options is Not Worth The Trouble, at least IMHO.
>
> So you didn't like the suggestion of having the configure for llvm-gcc set
> via an environment variable? That avoids having to deal with this directly
> in the script. Or am I missing something?

No, that was written under the assumption that passing in CC and CXX via
env variables wouldn't work. Things work now, so that assumption is
obviously wrong.

I still don't like environment variables. They tend to remain in effect
long after I forgot that I set them, creating all sorts of hassle. In
fact I suspect I already fell prey to this, getting llvm to compile and
check one day and nearly despairing when trying to reproduce that
success on the next day.
But, well, you use what you need to use to get the job done, so
there :-)

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Anton Korobeynikov
In reply to this post by Daniel Berlin
Hello, Joachim

> Hm. For some reason, ld kept searching the wrong (64-bit) library paths
> when trying to link the 32-bit results.
Hrm. This looks like to be old story about 'lib vs lib32 vs lib64'
directories in different distributions. Almost every of them patch gcc
inside their packages to provide valid library paths.

Look for example, here:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01991.html

--
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Joachim Durchholz
Am Montag, den 24.03.2008, 22:34 +0300 schrieb Anton Korobeynikov:
> Hello, Joachim
>
> > Hm. For some reason, ld kept searching the wrong (64-bit) library paths
> > when trying to link the 32-bit results.
> Hrm. This looks like to be old story about 'lib vs lib32 vs lib64'
> directories in different distributions. Almost every of them patch gcc
> inside their packages to provide valid library paths.

Right.

However, I don't think that's the issue here.
After all, it will work when CC and GCC are passed in via environment
variables.

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Potential breakage in llvm-gcc's ./configure

Ralph Corderoy
In reply to this post by Joachim Durchholz

Hi Jo,

> No, that was written under the assumption that passing in CC and CXX
> via env variables wouldn't work. Things work now, so that assumption
> is obviously wrong.
>
> I still don't like environment variables. They tend to remain in
> effect long after I forgot that I set them, creating all sorts of
> hassle. In fact I suspect I already fell prey to this, getting llvm to
> compile and check one day and nearly despairing when trying to
> reproduce that success on the next day.  But, well, you use what you
> need to use to get the job done, so there :-)

Are you aware that

    FOO=bar ./configure

makes the shell set an environment variable just for the running of
./configure, i.e. it isn't an envvar in your shell as

    FOO=bar; export FOO
    ./configure

would do.  But it still an envvar, unlike

    ./configure FOO=bar

It may help.

    $ env | grep FOO
    $ FOO=bar env | grep FOO
    FOO=bar
    $

Cheers,


Ralph.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Environment variables considered evil

Joachim Durchholz
Am Dienstag, den 25.03.2008, 12:08 +0000 schrieb Ralph Corderoy:

> > No, that was written under the assumption that passing in CC and CXX
> > via env variables wouldn't work. Things work now, so that assumption
> > is obviously wrong.
> >
> > I still don't like environment variables. They tend to remain in
> > effect long after I forgot that I set them, creating all sorts of
> > hassle. In fact I suspect I already fell prey to this, getting llvm to
> > compile and check one day and nearly despairing when trying to
> > reproduce that success on the next day.  But, well, you use what you
> > need to use to get the job done, so there :-)
>
> Are you aware that
>
>     FOO=bar ./configure
>
> makes the shell set an environment variable just for the running of
> ./configure,

I am.
I'm not sure that
  FOO=bar BAZ=boo ./configure
will work; at least I got some funny results (though that may have been
due to other reasons).

Well, you live and learn. I have now switched to opening a new shell
window whenever I start an experiment, since gcc won't become
environment-agnostic in my lifetime anyway.
Though that's bad. If some overambitious sysadmin adds a CFLAGS variable
to /etc/profile, people on that machine will get funny results. To make
matters worse, there does not seem to be an exhaustive list of
environment variables to check, at least not for gcc and autoconf
(though there are plenty of non-exhaustive ones). I know I have to check
CC, CXX, CCFLAGS, CPPFLAGS, CXXFLAGS, and LDFLAGS; does an ASFLAGS
exist? A RANLIBFLAGS? ARFLAGS? (This is essentially the same problem as
with global variables: lack of information hiding, making it very
difficult to check all dependencies.)

I'm pretty sure that I'm not the first to observe this kind of
difficulty, and the GNU project probably won't change their conventions
anyway, I'll stop my rant now :-)

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Environment variables considered evil

Mike Stump
On Mar 25, 2008, at 5:47 AM, Joachim Durchholz wrote:
>
> I'm not sure that
>  FOO=bar BAZ=boo ./configure
> will work

It will.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev