llvm dev - Mar 2008 - [LLVMdev] Just got bitten by accidentally using the wrong gcc

>> I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the
>> (broken-for-LLVM) gcc-4.1 as a compiler.
>> The error message that I got was this:
>>  make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore'
>>  make[1]: *** No rule to make target
>>    `/home/jo/llvm-wrk/Release/bin/tblgen', needed by
>>    `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. 
Stop.
>>  make[1]: Leaving directory `/home/jo/llvm-wrk/lib/VMCore'
>>  make: *** [install] Error 1
>>
>> It took me a while to figure out what went wrong.
>>
>> I guess I'm not the only one to stumble upon this problem.
>>
>> Would it be a good idea to make ./configure check whether there's
an
>> incompatible tool configured, and carp if it finds one?
>
> Probably be a good idea. It's reasonably easy to check major/minor
> versions.
Its not just a matter of checking major/minor versions. It also depends on 
the target and in some cases the OS.
http://llvm.org/docs/GettingStarted.html#brokengcc

So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 
(32-bit) has issues. Is it easy to check these kinds of things? Do we even 
want to?

I guess it could be done for things like 4.1.1 or a couple of others on 
the list.

-Tanya

Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M.
Lattner:
> Its not just a matter of checking major/minor versions. It also depends on 
> the target and in some cases the OS.
> http://llvm.org/docs/GettingStarted.html#brokengcc
> 
> So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 
> (32-bit) has issues. Is it easy to check these kinds of things?
uname identifies arch.

/etc/lsb-release identifies Linux distribution; I'm not sure how to
identify Apple and Cygwin.

$prog --version gives a version string for all $progs that follow GNU
conventions (most do).
> Do we even want to?
Dunno, that's why I'm asking.

The one thing that counts for doing it is that ./configure is exactly
for dealing with all those little annoyances that different OSes, tool
versions etc. bring.

The thing that counts against them is that keeping the list of
broken-for-llvm tool versions is a neverending task - but then that's
normal for what ./configure does, so does this really count?
> I guess it could be done for things like 4.1.1 or a couple of others on 
> the list.
For those cases where the script cannot fully determine the conditions,
it might be helpful to emit just a warning. Describe what the issue is,
how any problems would manifest, and let the user go ahead in such a
case.

Just my 2c.

Regards,
Jo

Joachim Durchholz wrote:
> Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner:
>   
>> Its not just a matter of checking major/minor versions. It also depends
on
>> the target and in some cases the OS.
>> http://llvm.org/docs/GettingStarted.html#brokengcc
>>
>> So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 
>> (32-bit) has issues. Is it easy to check these kinds of things?
>>     
>
> uname identifies arch.
>
> /etc/lsb-release identifies Linux distribution; I'm not sure how to
> identify Apple and Cygwin.
>
>   
uname on Apple (at least in a Terminal) returns 'Darwin'.

dom

> I guess it could be done for things like 4.1.1 or a couple of others on 
> the list.
This gcc version always worked fine for me on ubuntu linux (though it
might have been 4.1.2, I don't recall).

Ciao,

Duncan.

Am Freitag, den 21.03.2008, 09:16 +0100 schrieb Duncan
Sands:
> > There's a list at
http://llvm.org/docs/GettingStarted.html#brokengcc so
> > there is a reasonable basis.
> > The list isn't comprehensive, of course, and will likely grow in
the
> > future. OTOH extending it as new problems come up should be easy to
do.
> 
> that list is not very reliable.  For example it says that gcc-4.1 is
> problematic, but I never had any problems with it on ubuntu linux.  So
> it's probably best to warn if a dubious tool is seen, rather than
erroring
> out.
I have to report that the Ubuntu gcc-4.1 will fail. 'make' would run
without giving more than a few warnings, but 'make install' will
complain that it doesn't know how to build one of the intermediate
targets and error out (some VMCore/tablegen file IIRC, I don't have the
log anymore).

Of course, such a list cannot ever be reliable, so giving a warning is
probably the best strategy anyway.
Is there a real difference between an error and a warning
in ./configure, anyway?

Regards,
Jo