Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling:> Sorry to step into this in the middle of a thread, but what exactly is > LLVM's autoconf doing that "autoconf shouldn't do if properly set up"?1) Variables like CC, CXX, CFLAGS don't work properly when submitted via the command line. The handling seems to be inconsistent, i.e. it seems that parts of the toolchain receive these flags, others don't. This is just a cosmetic problem, of course. 2) The setting of --build should be the default for --host, and the value of --host should be the default for --target. The build machinery seems to take the defaults for --host and --target from elsewhere, specifying just --build or --host will cause amd64 assembly to be fed to an assembler running in i686 mode. 3) On a 64-bit Ubuntu, setting --build/host/target=i686-pc-linux-gnu will work when compiling with gcc, but llvm-gcc will try to feed 64-bit machine code to the assembler in this situation. At least that's what happens when bootstrapping. 4) I also dimly recall having seen llvm-gcc use 64-bit library paths for linking the 32-bit binaries (with ensuing hilarity, of course). I had postponed further investigation with this issue until after I'd get the assembly stage working - this approach had worked well with gcc, too. I'm under the impression that problems 1-3 are caused by autoconf as used in LLVM. I don't know about problem 4; it might be because Ubuntu's handling of library paths is inherently broken, or it might be a consequence of problem 3. If autoconf in LLVM can be cleaned up, I'd be really like to do it. Having expertise in that area might just be what's been missing, so if you're willing to give a helping hand to an autoconf newbie, this might finally work out.> I have some experience with autoconf. I don't know if I've ever seen > one "properly set up" before. :-)I can understand that, it's a beast and few if any people ever set it up for cross compilation anyway. I assume that a cross compilation capable tool like LLVM needs a particularly careful setup in autoconf to avoid breakage like the above. Regards, Jo
On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz <jo at durchholz.org> wrote:> > Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling: >> Sorry to step into this in the middle of a thread, but what exactly is >> LLVM's autoconf doing that "autoconf shouldn't do if properly set up"? > > 1) Variables like CC, CXX, CFLAGS don't work properly when submitted via > the command line. The handling seems to be inconsistent, i.e. it seems > that parts of the toolchain receive these flags, others don't. > This is just a cosmetic problem, of course.Is this specifying CC, CXX, and CFLAGS during the "configure" process or during the "make" process? The Makefiles seem to be using them in a fairly consistent manner, as far as I can see. Which parts of the toolchain don't get the flags? Also, are we talking LLVM or LLVM-GCC?> 2) The setting of --build should be the default for --host, and the > value of --host should be the default for --target. The build machinery > seems to take the defaults for --host and --target from elsewhere, > specifying just --build or --host will cause amd64 assembly to be fed to > an assembler running in i686 mode.I don't have much of an explanation for this. I would suggest specifying all three (build/host/target) parameters if you're running into this problem. It might help in the short term while we figure out the issue.> 3) On a 64-bit Ubuntu, setting --build/host/target=i686-pc-linux-gnu > will work when compiling with gcc, but llvm-gcc will try to feed 64-bit > machine code to the assembler in this situation. At least that's what > happens when bootstrapping.(We derive our configure script for llvm-gcc from gcc's configure script, so there shouldn't be any drastic changes.) If you're cross-compiling, I don't think you can do a bootstrap. If you're compiling natively, you don't need to specify the build/host/target flags. Try disabling bootstrapping to see if this helps your problem.> 4) I also dimly recall having seen llvm-gcc use 64-bit library paths for > linking the 32-bit binaries (with ensuing hilarity, of course). I had > postponed further investigation with this issue until after I'd get the > assembly stage working - this approach had worked well with gcc, too. > > I'm under the impression that problems 1-3 are caused by autoconf as > used in LLVM. > I don't know about problem 4; it might be because Ubuntu's handling of > library paths is inherently broken, or it might be a consequence of > problem 3. > > If autoconf in LLVM can be cleaned up, I'd be really like to do it. > Having expertise in that area might just be what's been missing, so if > you're willing to give a helping hand to an autoconf newbie, this might > finally work out. >I suggest looking at the autoconf/configure.ac (for LLVM) and configure.in & gcc/configure.ac (for LLVM-GCC) scripts. You can find documentation here: http://www.gnu.org/software/autoconf/manual/autoconf.html The documentation will help you understand what the different macros in the .ac/.in files are up to and how they work. I'll try to help as much as I can, but I warn that I'm not an expert on GCC's configure scripts (they do a lot of...interesting things there).>> I have some experience with autoconf. I don't know if I've ever seen >> one "properly set up" before. :-) > > I can understand that, it's a beast and few if any people ever set it up > for cross compilation anyway. > I assume that a cross compilation capable tool like LLVM needs a > particularly careful setup in autoconf to avoid breakage like the above. >-bw
Bill Wendling wrote:> On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz <jo at durchholz.org> wrote: > >> Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling: >> >>> Sorry to step into this in the middle of a thread, but what exactly is >>> LLVM's autoconf doing that "autoconf shouldn't do if properly set up"? >>> >> 1) Variables like CC, CXX, CFLAGS don't work properly when submitted via >> the command line. The handling seems to be inconsistent, i.e. it seems >> that parts of the toolchain receive these flags, others don't. >> This is just a cosmetic problem, of course. >> > > Is this specifying CC, CXX, and CFLAGS during the "configure" process > or during the "make" process? The Makefiles seem to be using them in a > fairly consistent manner, as far as I can see. Which parts of the > toolchain don't get the flags? Also, are we talking LLVM or LLVM-GCC? > >As an example: When running make from my own project that uses llvm (and the llvm makefiles), I am unable to add extra include paths to the build. It seems that they get into the makefiles ok, but not through to the compiler itself.
Am Dienstag, den 13.05.2008, 11:50 -0700 schrieb Bill Wendling:> On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz <jo at durchholz.org> wrote: > > > > Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling: > >> Sorry to step into this in the middle of a thread, but what exactly is > >> LLVM's autoconf doing that "autoconf shouldn't do if properly set up"? > > > > 1) Variables like CC, CXX, CFLAGS don't work properly when submitted via > > the command line. The handling seems to be inconsistent, i.e. it seems > > that parts of the toolchain receive these flags, others don't. > > This is just a cosmetic problem, of course. > > Is this specifying CC, CXX, and CFLAGS during the "configure" process > or during the "make" process?That was during configure.> Which parts of the > toolchain don't get the flags? Also, are we talking LLVM or LLVM-GCC?Both. I seem to recall that LLVM and LLVM-GCC were failing in slightly different ways, but I'll have to verify this more precisely. Would --debug=j be a good way to log all commands as they are executed? Somehow I overlooked that option and didn't use it during my earlier tests, which made diagnosing this kind of problem somewhat difficult.> > 2) The setting of --build should be the default for --host, and the > > value of --host should be the default for --target. The build machinery > > seems to take the defaults for --host and --target from elsewhere, > > specifying just --build or --host will cause amd64 assembly to be fed to > > an assembler running in i686 mode. > > I don't have much of an explanation for this. I would suggest > specifying all three (build/host/target) parameters if you're running > into this problem. It might help in the short term while we figure out > the issue.I've been doing that all the time, and it got LLVM unwedged. It wasn't enough to get LLVM-GCC to compile though.> > 3) On a 64-bit Ubuntu, setting --build/host/target=i686-pc-linux-gnu > > will work when compiling with gcc, but llvm-gcc will try to feed 64-bit > > machine code to the assembler in this situation. At least that's what > > happens when bootstrapping. > > (We derive our configure script for llvm-gcc from gcc's configure > script, so there shouldn't be any drastic changes.) If you're > cross-compiling, I don't think you can do a bootstrap.Oh. What would be the problems with that> If you're > compiling natively, you don't need to specify the build/host/target > flags. > > Try disabling bootstrapping to see if this helps your problem.I wanted to avoid issues with compiling LLVM for 64 bits. (I'm running a 64-bit Linux here.) There was a warning that you have to disable PIC generation in that situation, and I wasn't sure whether that wouldn't get me into other kinds of trouble.> > If autoconf in LLVM can be cleaned up, I'd be really like to do it. > > Having expertise in that area might just be what's been missing, so if > > you're willing to give a helping hand to an autoconf newbie, this might > > finally work out. > > > I suggest looking at the autoconf/configure.ac (for LLVM) and > configure.in & gcc/configure.ac (for LLVM-GCC) scripts. You can find > documentation here: > > http://www.gnu.org/software/autoconf/manual/autoconf.html > > The documentation will help you understand what the different macros > in the .ac/.in files are up to and how they work. I'll try to help as > much as I can, but I warn that I'm not an expert on GCC's configure > scripts (they do a lot of...interesting things there).:-) Thanks. I hope to find some time for this tomorrow. Regards, Jo