thr3ads.net - llvm dev - [LLVMdev] Build(s) broken? [Aug 2009]

If this information is useful, please help other people find it:
Share via:

Paul Melis

2009-Aug-31 13:48 UTC

[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)

Paul Melis wrote:> Jim Grosbach wrote:
>>
>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>
>>> Hello,
>>>
>>> Bill Wendling wrote:
>>>> Before we had buildbots, a random patch would break the system.
It
>>>> would sometimes take a whole day to determine which patch broke
it.
>>> I see the buildbots are currently showing no problem on 32-bit
linux
>>> but
>>> I get the following build error with TOT (out-of-source autoconf
>>> build):
>>>
>>> [...]
>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>> make[1]: Entering directory
`/home/melis/c/llvm-svn-release/runtime'
>>> make[2]: Entering directory
>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
>>> Release build (bytecode)
>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>> BasicBlockTracing.ll:1:2:
>>> error: expected top-level entity
>>>    .file    "BasicBlockTracing.c"
>>>    ^
>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
>>> signature
>>> make[2]: ***
>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>> BasicBlockTracing.bc]
>>> Error 1
>>> make[2]: Leaving directory
>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>> make[1]: *** [libprofile/.makeall] Error 2
>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime'
>>> make: *** [all] Error 1
>>>
>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.
>>>
>>>
>>> Also, llvm-gcc also doesn't build for me. Here the error is
related to
>>> exception handling:
>>>
>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
>>> libdecnumber'
>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall
-Wwrite-strings
>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I. -I.
>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>> -I../../llvm-gcc-svn/gcc/../include
>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>> gtype-desc.c -o gtype-desc.o
>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared
here (not
>>> in a
>>> function)
>>> make[3]: *** [gtype-desc.o] Error 1
>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>> make[2]: *** [all-stage1-gcc] Error 2
>>> make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
>>> make[1]: *** [stage1-bubble] Error 2
>>> make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
>>> make: *** [all] Error 2
>>>
>>> Is there something suddenly wrong with my system (which hasn't
changed
>>> in any way)? I used to be able to build LLVM(GCC) without problems
a
>>> few
>>> weeks ago...
>>>
>>
>> SJLJ exception handling is only implemented on ARM Darwin. It looks
>> like your target is pulling in bits of that?
>
> Well, I don't know what changed to make this suddenly happen. FYI, here
is
> the configure line I have been using for quite some time:
>
> ../llvm-gcc-svn/configure \
>     --prefix=/home/melis/llvm \
>     --program-prefix=llvm- \
>     --with-llvm=/home/melis/c/llvm-svn \
>     --enable-languages=c,c++ \
>     --target=i686-pc-linux-gnu \
>     --with-tune=generic \
>     --with-arch=pentium4
It seems my installed version of llvm-gcc had lost its ability to generate
LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
case). That caused LLVM itself not to build, as the stuff in runtime/
picked up the flaky llvm-gcc.

Cleaning out my LLVM install and completely rebuilding from scratch fixed
the LLVM build. However, llvm-gcc still has the SJLJ error.

Paul

Jim Grosbach

2009-Aug-31 16:14 UTC

head link

[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)

On Aug 31, 2009, at 6:48 AM, Paul Melis wrote:
> Paul Melis wrote:
>> Jim Grosbach wrote:
>>>
>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>>
>>>> Hello,
>>>>
>>>> Bill Wendling wrote:
>>>>> Before we had buildbots, a random patch would break the
system. It
>>>>> would sometimes take a whole day to determine which patch
broke
>>>>> it.
>>>> I see the buildbots are currently showing no problem on 32-bit
>>>> linux
>>>> but
>>>> I get the following build error with TOT (out-of-source
autoconf
>>>> build):
>>>>
>>>> [...]
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>>> make[1]: Entering directory `/home/melis/c/llvm-svn-release/ 
>>>> runtime'
>>>> make[2]: Entering directory
>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc
for
>>>> Release build (bytecode)
>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>> BasicBlockTracing.ll:1:2:
>>>> error: expected top-level entity
>>>>   .file    "BasicBlockTracing.c"
>>>>   ^
>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
>>>> signature
>>>> make[2]: ***
>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>> BasicBlockTracing.bc]
>>>> Error 1
>>>> make[2]: Leaving directory
>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>> make[1]: *** [libprofile/.makeall] Error 2
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime'
>>>> make: *** [all] Error 1
>>>>
>>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM
IR.
>>>>
>>>>
>>>> Also, llvm-gcc also doesn't build for me. Here the error is
>>>> related to
>>>> exception handling:
>>>>
>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
>>>> libdecnumber'
>>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall -Wwrite- 
>>>> strings
>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
>>>> -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
>>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I.
-I.
>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>>> -I../../llvm-gcc-svn/gcc/../include
>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>>> gtype-desc.c -o gtype-desc.o
>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node'
undeclared here (not
>>>> in a
>>>> function)
>>>> make[3]: *** [gtype-desc.o] Error 1
>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>> make[2]: *** [all-stage1-gcc] Error 2
>>>> make[2]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>> make[1]: *** [stage1-bubble] Error 2
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>> make: *** [all] Error 2
>>>>
>>>> Is there something suddenly wrong with my system (which
hasn't
>>>> changed
>>>> in any way)? I used to be able to build LLVM(GCC) without  
>>>> problems a
>>>> few
>>>> weeks ago...
>>>>
>>>
>>> SJLJ exception handling is only implemented on ARM Darwin. It looks
>>> like your target is pulling in bits of that?
>>
>> Well, I don't know what changed to make this suddenly happen. FYI,
>> here is
>> the configure line I have been using for quite some time:
>>
>> ../llvm-gcc-svn/configure \
>>    --prefix=/home/melis/llvm \
>>    --program-prefix=llvm- \
>>    --with-llvm=/home/melis/c/llvm-svn \
>>    --enable-languages=c,c++ \
>>    --target=i686-pc-linux-gnu \
>>    --with-tune=generic \
>>    --with-arch=pentium4
>
> It seems my installed version of llvm-gcc had lost its ability to  
> generate
> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in  
> that
> case). That caused LLVM itself not to build, as the stuff in runtime/
> picked up the flaky llvm-gcc.
>
> Cleaning out my LLVM install and completely rebuilding from scratch  
> fixed
> the LLVM build. However, llvm-gcc still has the SJLJ error.
Please try pulling in the changes from r80588. I suspect that'll take  
care of your issue. Unfortunately, I can't reproduce the failure here  
to verify directly.

-Jim

Török Edwin

2009-Aug-31 17:32 UTC

head link

[LLVMdev] Build(s) broken?

On 2009-08-31 19:14, Jim Grosbach wrote:>
> On Aug 31, 2009, at 6:48 AM, Paul Melis wrote:
>
>> Paul Melis wrote:
>>> Jim Grosbach wrote:
>>>>
>>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Bill Wendling wrote:
>>>>>> Before we had buildbots, a random patch would break the
system. It
>>>>>> would sometimes take a whole day to determine which
patch broke it.
>>>>> I see the buildbots are currently showing no problem on
32-bit linux
>>>>> but
>>>>> I get the following build error with TOT (out-of-source
autoconf
>>>>> build):
>>>>>
>>>>> [...]
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>>>> make[1]: Entering directory
`/home/melis/c/llvm-svn-release/runtime'
>>>>> make[2]: Entering directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> llvm[2]: Compiling BasicBlockTracing.ll to
BasicBlockTracing.bc for
>>>>> Release build (bytecode)
>>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.ll:1:2:
>>>>> error: expected top-level entity
>>>>>   .file    "BasicBlockTracing.c"
>>>>>   ^
>>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid
bitcode
>>>>> signature
>>>>> make[2]: ***
>>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.bc]
>>>>> Error 1
>>>>> make[2]: Leaving directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> make[1]: *** [libprofile/.makeall] Error 2
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime'
>>>>> make: *** [all] Error 1
>>>>>
>>>>> It seems BasicBlockTracing.ll contains assembly instead of
LLVM IR.
>>>>>
>>>>>
>>>>> Also, llvm-gcc also doesn't build for me. Here the
error is
>>>>> related to
>>>>> exception handling:
>>>>>
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/
>>>>> libdecnumber'
>>>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall
-Wwrite-strings
>>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
>>>>> -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
>>>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H
-I. -I.
>>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>>>> -I../../llvm-gcc-svn/gcc/../include
>>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>>>> gtype-desc.c -o gtype-desc.o
>>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node'
undeclared here (not
>>>>> in a
>>>>> function)
>>>>> make[3]: *** [gtype-desc.o] Error 1
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> make[2]: *** [all-stage1-gcc] Error 2
>>>>> make[2]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make[1]: *** [stage1-bubble] Error 2
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Is there something suddenly wrong with my system (which
hasn't
>>>>> changed
>>>>> in any way)? I used to be able to build LLVM(GCC) without
problems a
>>>>> few
>>>>> weeks ago...
>>>>>
>>>>
>>>> SJLJ exception handling is only implemented on ARM Darwin. It
looks
>>>> like your target is pulling in bits of that?
>>>
>>> Well, I don't know what changed to make this suddenly happen.
FYI,
>>> here is
>>> the configure line I have been using for quite some time:
>>>
>>> ../llvm-gcc-svn/configure \
>>>    --prefix=/home/melis/llvm \
>>>    --program-prefix=llvm- \
>>>    --with-llvm=/home/melis/c/llvm-svn \
>>>    --enable-languages=c,c++ \
>>>    --target=i686-pc-linux-gnu \
>>>    --with-tune=generic \
>>>    --with-arch=pentium4
>>
>> It seems my installed version of llvm-gcc had lost its ability to
>> generate
>> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
>> case). That caused LLVM itself not to build, as the stuff in runtime/
>> picked up the flaky llvm-gcc.
>>
>> Cleaning out my LLVM install and completely rebuilding from scratch
>> fixed
>> the LLVM build. However, llvm-gcc still has the SJLJ error.
>
> Please try pulling in the changes from r80588. I suspect that'll take
> care of your issue. Unfortunately, I can't reproduce the failure here
> to verify directly.
It fixes it for me: with that patch I can bootstrap llvm2.6 now.
I think it should be pulled into the 2.6 branch.

Best regards,
--Edwin

Paul Melis

2009-Aug-31 18:33 UTC

head link

[LLVMdev] Build(s) broken?

Jim Grosbach wrote:>
> On Aug 31, 2009, at 6:48 AM, Paul Melis wrote:
>
>> Paul Melis wrote:
>>> Jim Grosbach wrote:
>>>>
>>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Bill Wendling wrote:
>>>>>> Before we had buildbots, a random patch would break the
system. It
>>>>>> would sometimes take a whole day to determine which
patch broke it.
>>>>> I see the buildbots are currently showing no problem on
32-bit linux
>>>>> but
>>>>> I get the following build error with TOT (out-of-source
autoconf
>>>>> build):
>>>>>
>>>>> [...]
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>>>> make[1]: Entering directory
`/home/melis/c/llvm-svn-release/runtime'
>>>>> make[2]: Entering directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> llvm[2]: Compiling BasicBlockTracing.ll to
BasicBlockTracing.bc for
>>>>> Release build (bytecode)
>>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.ll:1:2:
>>>>> error: expected top-level entity
>>>>>   .file    "BasicBlockTracing.c"
>>>>>   ^
>>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid
bitcode
>>>>> signature
>>>>> make[2]: ***
>>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.bc]
>>>>> Error 1
>>>>> make[2]: Leaving directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> make[1]: *** [libprofile/.makeall] Error 2
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime'
>>>>> make: *** [all] Error 1
>>>>>
>>>>> It seems BasicBlockTracing.ll contains assembly instead of
LLVM IR.
>>>>>
>>>>>
>>>>> Also, llvm-gcc also doesn't build for me. Here the
error is
>>>>> related to
>>>>> exception handling:
>>>>>
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/
>>>>> libdecnumber'
>>>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall
-Wwrite-strings
>>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
>>>>> -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
>>>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H
-I. -I.
>>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>>>> -I../../llvm-gcc-svn/gcc/../include
>>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>>>> gtype-desc.c -o gtype-desc.o
>>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node'
undeclared here (not
>>>>> in a
>>>>> function)
>>>>> make[3]: *** [gtype-desc.o] Error 1
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> make[2]: *** [all-stage1-gcc] Error 2
>>>>> make[2]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make[1]: *** [stage1-bubble] Error 2
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Is there something suddenly wrong with my system (which
hasn't
>>>>> changed
>>>>> in any way)? I used to be able to build LLVM(GCC) without
problems a
>>>>> few
>>>>> weeks ago...
>>>>>
>>>>
>>>> SJLJ exception handling is only implemented on ARM Darwin. It
looks
>>>> like your target is pulling in bits of that?
>>>
>>> Well, I don't know what changed to make this suddenly happen.
FYI,
>>> here is
>>> the configure line I have been using for quite some time:
>>>
>>> ../llvm-gcc-svn/configure \
>>>    --prefix=/home/melis/llvm \
>>>    --program-prefix=llvm- \
>>>    --with-llvm=/home/melis/c/llvm-svn \
>>>    --enable-languages=c,c++ \
>>>    --target=i686-pc-linux-gnu \
>>>    --with-tune=generic \
>>>    --with-arch=pentium4
>>
>> It seems my installed version of llvm-gcc had lost its ability to
>> generate
>> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
>> case). That caused LLVM itself not to build, as the stuff in runtime/
>> picked up the flaky llvm-gcc.
>>
>> Cleaning out my LLVM install and completely rebuilding from scratch
>> fixed
>> the LLVM build. However, llvm-gcc still has the SJLJ error.
>
> Please try pulling in the changes from r80588. I suspect that'll take
> care of your issue. Unfortunately, I can't reproduce the failure here
> to verify directly.Well, that seems to have fixed it with TOT, thanks!

Paul

Paul Melis

2009-Aug-31 20:43 UTC

head link

[LLVMdev] Build(s) broken?

Paul Melis wrote:> Paul Melis wrote:
>   
>> Jim Grosbach wrote:
>>     
>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>>
>>>       
>>>> Hello,
>>>>
>>>> Bill Wendling wrote:
>>>>         
>>>>> Before we had buildbots, a random patch would break the
system. It
>>>>> would sometimes take a whole day to determine which patch
broke it.
>>>>>           
>>>> I see the buildbots are currently showing no problem on 32-bit
linux
>>>> but
>>>> I get the following build error with TOT (out-of-source
autoconf
>>>> build):
>>>>
>>>> [...]
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>>> make[1]: Entering directory
`/home/melis/c/llvm-svn-release/runtime'
>>>> make[2]: Entering directory
>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>> llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc
for
>>>> Release build (bytecode)
>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>> BasicBlockTracing.ll:1:2:
>>>> error: expected top-level entity
>>>>    .file    "BasicBlockTracing.c"
>>>>    ^
>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
>>>> signature
>>>> make[2]: ***
>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>> BasicBlockTracing.bc]
>>>> Error 1
>>>> make[2]: Leaving directory
>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>> make[1]: *** [libprofile/.makeall] Error 2
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime'
>>>> make: *** [all] Error 1
>>>>
>>>> It seems BasicBlockTracing.ll contains assembly instead of LLVM
IR.
>>>>
>>>>
>>>> Also, llvm-gcc also doesn't build for me. Here the error is
related to
>>>> exception handling:
>>>>
>>>> make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
>>>> libdecnumber'
>>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall
-Wwrite-strings
>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
>>>> -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
>>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I.
-I.
>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>>> -I../../llvm-gcc-svn/gcc/../include
>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>>> gtype-desc.c -o gtype-desc.o
>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node'
undeclared here (not
>>>> in a
>>>> function)
>>>> make[3]: *** [gtype-desc.o] Error 1
>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>> make[2]: *** [all-stage1-gcc] Error 2
>>>> make[2]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>> make[1]: *** [stage1-bubble] Error 2
>>>> make[1]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>> make: *** [all] Error 2
>>>>
>>>> Is there something suddenly wrong with my system (which
hasn't changed
>>>> in any way)? I used to be able to build LLVM(GCC) without
problems a
>>>> few
>>>> weeks ago...
>>>>
>>>>         
>>> SJLJ exception handling is only implemented on ARM Darwin. It looks
>>> like your target is pulling in bits of that?
>>>       
>> Well, I don't know what changed to make this suddenly happen. FYI,
here is
>> the configure line I have been using for quite some time:
>>
>> ../llvm-gcc-svn/configure \
>>     --prefix=/home/melis/llvm \
>>     --program-prefix=llvm- \
>>     --with-llvm=/home/melis/c/llvm-svn \
>>     --enable-languages=c,c++ \
>>     --target=i686-pc-linux-gnu \
>>     --with-tune=generic \
>>     --with-arch=pentium4
>>     
>
> It seems my installed version of llvm-gcc had lost its ability to generate
> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
> case). That caused LLVM itself not to build, as the stuff in runtime/
> picked up the flaky llvm-gcc.
>   After rebuilding LLVM and llvm-gcc a couple of times now (after rm -rf
*-ing the build directories and reconfiguring) I keep having the problem
that -S -emit-llvm does not produce LLVM IR, e.g.

22:11|melis at juggle2:~> llvm-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../llvm-gcc-svn/configure --prefix=/home/melis/llvm
--program-prefix=llvm- --with-llvm=/home/melis/llvm
--enable-languages=c,c++ --target=i686-pc-linux-gnu --with-tune=generic
--with-arch=pentium4 : (reconfigured) ../llvm-gcc-svn/configure
--prefix=/home/melis/llvm --program-prefix=llvm-
--with-llvm=/home/melis/llvm --enable-languages=c,c++
--target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5649)
22:11|melis at juggle2:~> cat doh.c
#include <stdio.h>
int main()
{
    printf("Doh!\n");
}
22:11|melis at juggle2:~> llvm-gcc -S -emit-llvm doh.c
22:11|melis at juggle2:~> ls -l doh.*
-rw-r--r-- 1 melis melis  56 Aug 31 22:10 doh.c
-rw-r--r-- 1 melis melis 310 Aug 31 22:11 doh.s
22:11|melis at juggle2:~> cat doh.s
    .file    "doh.c"
    .section    .rodata
.LC0:
    .string    "Doh!"
    .text
.globl main
    .type    main, @function
main:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $24, %esp
    movl    $.LC0, (%esp)
    call    puts
    leave
    ret
    .size    main, .-main
    .ident    "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649)"
    .section    .note.GNU-stack,"", at progbits

I figured perhaps the --with-llvm value I used was wrong (should it be
llvm build-dir or final installation dir?), but after trying different
values it still makes no difference. What would cause llvm-gcc to loose
the capability of writing out LLVM IR?

Thanks,
Paul

Jim Grosbach

2009-Aug-31 20:47 UTC

head link

[LLVMdev] Build(s) broken?

On Aug 31, 2009, at 1:43 PM, Paul Melis wrote:
> Paul Melis wrote:
>> Paul Melis wrote:
>>
>>> Jim Grosbach wrote:
>>>
>>>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> Bill Wendling wrote:
>>>>>
>>>>>> Before we had buildbots, a random patch would break the
system.
>>>>>> It
>>>>>> would sometimes take a whole day to determine which
patch broke
>>>>>> it.
>>>>>>
>>>>> I see the buildbots are currently showing no problem on
32-bit
>>>>> linux
>>>>> but
>>>>> I get the following build error with TOT (out-of-source
autoconf
>>>>> build):
>>>>>
>>>>> [...]
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-svn-release/tools'
>>>>> make[1]: Entering directory
`/home/melis/c/llvm-svn-release/
>>>>> runtime'
>>>>> make[2]: Entering directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> llvm[2]: Compiling BasicBlockTracing.ll to
BasicBlockTracing.bc
>>>>> for
>>>>> Release build (bytecode)
>>>>> /home/melis/c/llvm-svn-release/Release/bin/llvm-as:
>>>>> /home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.ll:1:2:
>>>>> error: expected top-level entity
>>>>>   .file    "BasicBlockTracing.c"
>>>>>   ^
>>>>> /home/melis/c/llvm-svn-release/Release/bin/opt: Invalid
bitcode
>>>>> signature
>>>>> make[2]: ***
>>>>> [/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
>>>>> BasicBlockTracing.bc]
>>>>> Error 1
>>>>> make[2]: Leaving directory
>>>>> `/home/melis/c/llvm-svn-release/runtime/libprofile'
>>>>> make[1]: *** [libprofile/.makeall] Error 2
>>>>> make[1]: Leaving directory `/home/melis/c/llvm-svn-release/
>>>>> runtime'
>>>>> make: *** [all] Error 1
>>>>>
>>>>> It seems BasicBlockTracing.ll contains assembly instead of
LLVM
>>>>> IR.
>>>>>
>>>>>
>>>>> Also, llvm-gcc also doesn't build for me. Here the
error is
>>>>> related to
>>>>> exception handling:
>>>>>
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/
>>>>> libdecnumber'
>>>>> make[3]: Entering directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> /home/melis/local/bin/gcc -c   -g -DIN_GCC   -W -Wall
-Wwrite-
>>>>> strings
>>>>> -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long
>>>>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style- 
>>>>> definition
>>>>> -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H
-I. -I.
>>>>> -I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
>>>>> -I../../llvm-gcc-svn/gcc/../include
>>>>> -I../../llvm-gcc-svn/gcc/../libcpp/include
>>>>> -I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
>>>>> gtype-desc.c -o gtype-desc.o
>>>>> gtype-desc.c:5862: error: 'sjlj_fc_type_node'
undeclared here (not
>>>>> in a
>>>>> function)
>>>>> make[3]: *** [gtype-desc.o] Error 1
>>>>> make[3]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build/gcc'
>>>>> make[2]: *** [all-stage1-gcc] Error 2
>>>>> make[2]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make[1]: *** [stage1-bubble] Error 2
>>>>> make[1]: Leaving directory
`/home/melis/c/llvm-gcc-svn-build'
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Is there something suddenly wrong with my system (which
hasn't
>>>>> changed
>>>>> in any way)? I used to be able to build LLVM(GCC) without  
>>>>> problems a
>>>>> few
>>>>> weeks ago...
>>>>>
>>>>>
>>>> SJLJ exception handling is only implemented on ARM Darwin. It
looks
>>>> like your target is pulling in bits of that?
>>>>
>>> Well, I don't know what changed to make this suddenly happen.
FYI,
>>> here is
>>> the configure line I have been using for quite some time:
>>>
>>> ../llvm-gcc-svn/configure \
>>>    --prefix=/home/melis/llvm \
>>>    --program-prefix=llvm- \
>>>    --with-llvm=/home/melis/c/llvm-svn \
>>>    --enable-languages=c,c++ \
>>>    --target=i686-pc-linux-gnu \
>>>    --with-tune=generic \
>>>    --with-arch=pentium4
>>>
>>
>> It seems my installed version of llvm-gcc had lost its ability to  
>> generate
>> LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in  
>> that
>> case). That caused LLVM itself not to build, as the stuff in runtime/
>> picked up the flaky llvm-gcc.
>>
> After rebuilding LLVM and llvm-gcc a couple of times now (after rm -rf
> *-ing the build directories and reconfiguring) I keep having the  
> problem
> that -S -emit-llvm does not produce LLVM IR, e.g.
>
> 22:11|melis at juggle2:~> llvm-gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ../llvm-gcc-svn/configure --prefix=/home/melis/llvm
> --program-prefix=llvm- --with-llvm=/home/melis/llvm
> --enable-languages=c,c++ --target=i686-pc-linux-gnu --with- 
> tune=generic
> --with-arch=pentium4 : (reconfigured) ../llvm-gcc-svn/configure
> --prefix=/home/melis/llvm --program-prefix=llvm-
> --with-llvm=/home/melis/llvm --enable-languages=c,c++
> --target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5649)
> 22:11|melis at juggle2:~> cat doh.c
> #include <stdio.h>
> int main()
> {
>    printf("Doh!\n");
> }
> 22:11|melis at juggle2:~> llvm-gcc -S -emit-llvm doh.c
> 22:11|melis at juggle2:~> ls -l doh.*
> -rw-r--r-- 1 melis melis  56 Aug 31 22:10 doh.c
> -rw-r--r-- 1 melis melis 310 Aug 31 22:11 doh.s
> 22:11|melis at juggle2:~> cat doh.s
>    .file    "doh.c"
>    .section    .rodata
> .LC0:
>    .string    "Doh!"
>    .text
> .globl main
>    .type    main, @function
> main:
>    pushl    %ebp
>    movl    %esp, %ebp
>    subl    $24, %esp
>    movl    $.LC0, (%esp)
>    call    puts
>    leave
>    ret
>    .size    main, .-main
>    .ident    "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649)"
>    .section    .note.GNU-stack,"", at progbits
>
> I figured perhaps the --with-llvm value I used was wrong (should it be
> llvm build-dir or final installation dir?), but after trying different
> values it still makes no difference. What would cause llvm-gcc to  
> loose
> the capability of writing out LLVM IR?
>
Does --enable-llvm=<path> instead of --with-llvm=<path> yield the
same
results?


-Jim

Anton Korobeynikov

2009-Aug-31 20:58 UTC

head link

[LLVMdev] Build(s) broken?

Hello, Paul
> >> ../llvm-gcc-svn/configure \
> >>     --prefix=/home/melis/llvm \
> >>     --program-prefix=llvm- \
> >>     --with-llvm=/home/melis/c/llvm-svn \You need to use --enable-llvm, not --with-llvm
> gcc version 4.2.1 (Based on Apple Inc. build 5649)As you can see - this is not llvm-enabled gcc

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Duncan Sands

2009-Aug-31 21:05 UTC

head link

[LLVMdev] Build(s) broken?

Hi Paul,
> I figured perhaps the --with-llvm value I used was wrong (should it be
> llvm build-dir or final installation dir?), but after trying different
> values it still makes no difference. What would cause llvm-gcc to loose
> the capability of writing out LLVM IR?

maybe you built an llvm-gcc with LLVM disabled (in which case you get
an ordinary Apple GCC, or at least you're supposed to)?  Did you specify
--enable-llvm when configuring GCC?

Ciao,

Duncan.

Reasonably Related Threads

Search for more reasonably related threads

llvm dev - Aug 2009 - [LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)

[LLVMdev] Build(s) broken? (was: Re: Buildbots: Apology and Explanation)

[LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken?

[LLVMdev] Build(s) broken?

Reasonably Related Threads