build troubles on OS X (?)

[GoogleCodeExporter]

Trying to build current default branch (@a218191d46) on OS X 10.6, as described 
at http://code.google.com/p/tart/wiki/BuildingTart

By the way, since an hg clone of the tart repo ends up with a 'trunk' directory 
(remnants of svn?) at the top level, the build instructions above are not quite 
correct, since they refer to the top level 'tart' as the one that contains all 
the source files instead of 'trunk'.  Specifically, the last line in the cmake 
invocation should be ../trunk instead of ../tart.

I have llvm 2.8 installed via homebrew (http://mxcl.github.com/homebrew) in 
/usr/local/Cellar/llvm/2.8.  I haven't built anything else with this llvm 
installation, so something could possibly be screwy there as well.

cmake config output, followed by compilation output:

Lap:build liam$ cmake -D CMAKE_BUILD_TYPE=Debug \
>    -D LLVM_INCLUDE_DIR=/usr/local/Cellar/llvm/2.8/include \
>    -D LLVM_LIBRARY_DIR=/usr/local/Cellar/llvm/2.8/lib \
>    -D LLVM_BINARY_DIR=/usr/local/Cellar/llvm/2.8/bin \
>    ../trunk
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE 
-- Looking for assert.h
-- Looking for assert.h - found
-- Looking for stdio.h
-- Looking for stdio.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Looking for stdlib.h
-- Looking for stdlib.h - found
-- Looking for string.h
-- Looking for string.h - found
-- Looking for stdbool.h
-- Looking for stdbool.h - found
-- Looking for stdarg.h
-- Looking for stdarg.h - found
-- Looking for malloc.h
-- Looking for malloc.h - not found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for errno.h
-- Looking for errno.h - found
-- Looking for execinfo.h
-- Looking for execinfo.h - found
-- Looking for sys/time.h
-- Looking for sys/time.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for sys/resource.h
-- Looking for sys/resource.h - found
-- Looking for libkern/OSAtomic.h
-- Looking for libkern/OSAtomic.h - found
-- Looking for C++ include new
-- Looking for C++ include new - found
-- Looking for C++ include ctime
-- Looking for C++ include ctime - found
-- Looking for C++ include cxxabi.h
-- Looking for C++ include cxxabi.h - found
-- Looking for C++ include dlfcn.h
-- Looking for C++ include dlfcn.h - found
-- Looking for C++ include unwind.h
-- Looking for C++ include unwind.h - found
-- Looking for C++ include libunwind.h
-- Looking for C++ include libunwind.h - found
-- Looking for backtrace
-- Looking for backtrace - found
-- Looking for dladdr
-- Looking for dladdr - found
-- Looking for posix_memalign
-- Looking for posix_memalign - found
-- Looking for valloc
-- Looking for valloc - found
-- Looking for _aligned_malloc
-- Looking for _aligned_malloc - not found
-- Found Perl: /usr/bin/perl 
-- Found LLVM: /usr/local/Cellar/llvm/2.8/include 
-- Performing Test HAVE_GCC_ATOMICS
-- Performing Test HAVE_GCC_ATOMICS - Success
-- Performing Test HAVE_GCC_THREAD_LOCAL
-- Performing Test HAVE_GCC_THREAD_LOCAL - Failed
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of long long
-- Check size of long long - done
-- Check size of void*
-- Check size of void* - done
-- The ASM-ATT compiler identification is unknown
-- Found assembler: /usr/bin/as
-- Loaded CMakeASM-ATTInformation - ASM-ATT support is still experimental, 
please report issues
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/liam/Documents/mtcode/tart/build
Lap:build liam$ make
Scanning dependencies of target compiler
[  0%] Building CXX object 
compiler/CMakeFiles/compiler.dir/lib/AST/ASTDecl.cpp.o
In file included from 
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp:7:
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:318: error: ‘assertionFailed’ has not been declared
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: expected primary-expression before ‘const’
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: expected primary-expression before ‘const’
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: expected primary-expression before ‘unsigned’
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: expected primary-expression before ‘const’
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: there are no arguments to ‘assertionFailed’ that depend on a 
template parameter, so a declaration of ‘assertionFailed’ must be available
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: (if you use ‘-fpermissive’, G++ will accept your code, but 
allowing the use of an undeclared name is deprecated)
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:323: error: variable or field ‘LLVM_ATTRIBUTE_NORETURN’ declared void
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:335: error: ‘__fail’ has not been declared
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:335: error: ‘void tart::Diagnostics::LLVM_ATTRIBUTE_NORETURN(int (*)(const 
char*, const char*, unsigned int))’ cannot be overloaded
/Users/liam/Documents/mtcode/tart/trunk/compiler/include/tart/Common/Diagnostics
.h:318: error: with ‘void tart::Diagnostics::LLVM_ATTRIBUTE_NORETURN(int 
(*)(const char*, const char*, unsigned int))’
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp: In member 
function ‘virtual void tart::ASTDecl::format(tart::FormatStream&) const’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp:19: error: 
‘class tart::Diagnostics’ has no member named ‘__fail’
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp: In member 
function ‘virtual void tart::ASTTypeDecl::format(tart::FormatStream&) 
const’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp:62: error: 
‘class tart::Diagnostics’ has no member named ‘__fail’
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp: In member 
function ‘virtual void tart::ASTVarDecl::format(tart::FormatStream&) const’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp:91: error: 
‘class tart::Diagnostics’ has no member named ‘__fail’
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp: In member 
function ‘virtual void tart::ASTFunctionDecl::format(tart::FormatStream&) 
const’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/AST/ASTDecl.cpp:163: 
error: ‘class tart::Diagnostics’ has no member named ‘__fail’
make[2]: *** [compiler/CMakeFiles/compiler.dir/lib/AST/ASTDecl.cpp.o] Error 1
make[1]: *** [compiler/CMakeFiles/compiler.dir/all] Error 2
make: *** [all] Error 2

Original issue reported on code.google.com by lst...@gmail.com on 23 Feb 2011 at 9:58

[GoogleCodeExporter]

Tart currently doesn't build against LLVM 2.8 - right now it's building against 
the head revision. For example, the DIBuilder class isn't present in 2.8.

That being said, it would not surprise me if there were additional problems 
building on OS X, as it has been several months since I have attempted a build 
on that platform.

Original comment by viri...@gmail.com on 23 Feb 2011 at 10:15

[GoogleCodeExporter]

So it would seem - LLVM_ATTRIBUTE_NORETURN doesn't show up anywhere in my LLVM 
includes.  I'll try to get set up with llvm head and see how it goes.  Might be 
nice to update the build page in the meantime, I suppose.

What's your normal build platform?

Original comment by lst...@gmail.com on 23 Feb 2011 at 10:19

[GoogleCodeExporter]

Looks like there have been quite a few renames in DIBuilder - patch attached 
for their uses in CodeGenDebug.cpp

Now seeing some undefined symbols errors when "Linking CXX shared library 
libgc"...

Original comment by lst...@gmail.com on 23 Feb 2011 at 11:25

Attachments:

• codegenrenames.diff

[GoogleCodeExporter]

Ah, thank you very much! I was wondering if they were going to make that 
change...I'll apply this when I get home.

My normal build platform is Ubuntu, but I have an OS X machine as well.

Original comment by viri...@gmail.com on 23 Feb 2011 at 11:30

• Changed state: Accepted
• Added labels: Component-Compiler, OpSys-All, Priority-Medium, Type-Patch

[GoogleCodeExporter]

Turns out my env was still a little screwy, with some paths pointing to my 
previous llvm 2.8 install - as such, here's another patch that supersedes the 
previous one, and includes a few more trivial changes.  Mostly changing include 
paths from "System" to "Support".

Second question - I'm seeing messages like 

cc1plus: warnings being treated as errors
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Common/Compiler.cpp: In 
member function ‘void tart::Compiler::processInputFile(const std::string&)’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Common/Compiler.cpp:38: 
warning: ‘getSuffix’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:292)
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Common/Compiler.cpp:66: 
warning: ‘exists’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:383)

There don't seem to be any drop-in replacements for this one.  As far as I can 
tell, the recommended API is to use the Twine class to represent the filepath, 
and use the routines in PathV2.h to query/manipulate it.  What are your 
thoughts about updating to that API?

Original comment by lst...@gmail.com on 24 Feb 2011 at 12:38

Attachments:

• more_renames.diff

[GoogleCodeExporter]

The current LLVM tip no longer has a "System" directory, and I made those 
adjustments quite a while back - there should no longer be any Tart files that 
refer to "llvm/System" as far as I know.

Original comment by viri...@gmail.com on 24 Feb 2011 at 2:30

[GoogleCodeExporter]

Hm - see the first couple entries in the latest diff for where the compiler 
found them in the latest tart source.  Also just found another: 
tart/trunk/compiler/lib/Common/PackageMgr.cpp:13:30: error: llvm/System/Path.h: 
No such file or directory

I ported (but did not test yet) the file handling in Common/Compiler.cpp in 
order to continue building, and am now seeing the following deprecation 
warnings, related to the same sys::Path() deprecations.  Since warnings are 
configured to be treated as errors (which is good), it would be nice to figure 
out what the plan is for those.

cc1plus: warnings being treated as errors
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp: In 
member function ‘void tart::CodeGenerator::genDICompileUnit()’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp:97: 
warning: ‘getLast’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:269)
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp:98: 
warning: ‘getDirname’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:283)
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp: In 
member function ‘llvm::DIFile tart::CodeGenerator::genDIFile(const 
tart::SourceRegion*)’:
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp:119: 
warning: ‘getLast’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:269)
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenDebug.cpp:120: 
warning: ‘getDirname’ is deprecated (declared at 
/Users/liam/Documents/mtcode/llvm-install/include/llvm/Support/PathV1.h:283)

Original comment by lst...@gmail.com on 24 Feb 2011 at 2:56

[GoogleCodeExporter]

BTW - here's my (not final/tested) hack at porting the path handling logic.  
Not totally sure if this is the right approach - the llvm path/string handling 
support seems pretty convoluted, unless I'm missing something...

Original comment by lst...@gmail.com on 24 Feb 2011 at 3:07

Attachments:

• path_handling.diff

[GoogleCodeExporter]

Sounds like I must have old headers too. Time for a cleaning!

Original comment by viri...@gmail.com on 24 Feb 2011 at 3:08

[GoogleCodeExporter]

It'll be a few days before I can apply the patches, I'm in the middle of a 
large change at the moment.

Original comment by viri...@gmail.com on 24 Feb 2011 at 9:15

[GoogleCodeExporter]

OK, standing by

Original comment by lst...@gmail.com on 24 Feb 2011 at 3:13

[GoogleCodeExporter]

OK I've been working on getting things to compile on OS X, and I have run into 
a number of problems along the way:

1) It appears that "can_read" is defined in llvm/Support/FileSystem.h, but not 
actually implemented.

2) The shared libraries won't build because of undefined symbols, mostly ones 
in the LLVM libs. On Linux, this works fine because the shared libraries expect 
those symbols to be provided by the host application when the lib is loaded, 
but apparently on Darwin we need some additional magic to make this work, and I 
don't know what that is.

(In older versions of Tart, I statically linked the LLVM libs into the shared 
library, but this caused problems - for example, the command-line library would 
complain about options being registered multiple times, since the same static 
constructors were included in both the library and the host app.)

In any case, I don't want to check in the code until at least item (1) is 
addressed, since it would break my ability to work on Tart on other platforms.

Original comment by viri...@gmail.com on 27 Feb 2011 at 3:07

[GoogleCodeExporter]

Hm - 1) is a bummer.  If that gets resolved, I'd be happy to dig into the issue 
of the shared libraries not building.

Original comment by lst...@gmail.com on 27 Feb 2011 at 6:12

[GoogleCodeExporter]

Just to confirm - since can_read() looks like it's going to be removed from 
llvm altogether, are you in a position to commit your recent work (or will be 
sometime soon), such that OS X may still need some tweaks but other platforms 
are OK?

Original comment by lst...@gmail.com on 3 Mar 2011 at 10:53

[GoogleCodeExporter]

Yeah, I'll try to get to it tonight.

Original comment by viri...@gmail.com on 4 Mar 2011 at 11:54

[GoogleCodeExporter]

OK changes have been committed.

Original comment by viri...@gmail.com on 5 Mar 2011 at 1:41

[GoogleCodeExporter]

I found and fixed a few more build problems, but the shared library build 
problems have not been fixed.

Original comment by viri...@gmail.com on 6 Mar 2011 at 11:37

[GoogleCodeExporter]

Cool - some of the link failures look like a result of not specifying in the 
cmake files which llvm libs to link against (they were commented out?).  
Uncommenting those allows several link steps to succeed, but I saw a couple 
more simple llvm API change-related problems.  Attached is a patch with the 
mods that allow me to get quite a bit further in the build.

However, I'm seeing some segfaults in tartc as the build progresses, as shown 
below:

[ 30%] Generating dependencies for libstd.bc
[ 30%] Built target testrunner
[ 55%] Built target libstd
[ 55%] [ 55%] Compiling Tart source file tart/testing/Asserts.tart
Compiling Tart source file tart/opts/NameConflictError.tart
[ 55%] Compiling Tart source file tart/opts/OptionBase.tart
[ 55%] Compiling Tart source file tart/testing/Test.tart
Stack dump:
0.  Program arguments: ../../tools/tartc/tartc -g -debug-errors -sourcepath 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart 
[ 55%] Linking libtesting.bc
[ 55%] Generating dependencies for libtesting.bc
[ 55%] Built target libtesting
[ 55%] Compiling Tart source file tart/gc1/GC1.tart
/bin/sh: line 1: 70294 Segmentation fault      ../../tools/tartc/tartc -g 
-debug-errors -sourcepath /Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart
make[2]: *** [lib/opts/tart/opts/OptionBase.bc] Error 139
make[1]: *** [lib/opts/CMakeFiles/libopts.dir/all] Error 2

Original comment by lst...@gmail.com on 7 Mar 2011 at 2:37

Attachments:

• sharedlibs.diff

[GoogleCodeExporter]

So the reason those were commented out is that if I put them back in, they get 
statically linked into the .so instead of being dynamically linked. That's a 
problem because then you get two copies of the object files, one in the .so and 
one in the main program. This causes llc and opt to get unhappy - for example, 
LLVM's command-line library complains about program options being registered 
twice. That happens because you have two copies of each option, each having 
it's own static constructor that tries to register it.

What needs to happen is that the .so looks for undefined symbols in the main 
program. Unfortunately, I don't know how to tell cmake to build the .so that 
way.

Original comment by viri...@gmail.com on 7 Mar 2011 at 2:49

[GoogleCodeExporter]

Ah, ok.  I'll poke around and see what I can find.

Original comment by lst...@gmail.com on 7 Mar 2011 at 5:25

[GoogleCodeExporter]

I've just checked in a few more OS X build fixes:

-- CMakeLists.txt for gendeps had not been updated.
-- Some 32-bit pointer issues (My iMac is pre-snow-leopard.)

Original comment by viri...@gmail.com on 9 Mar 2011 at 2:28

[GoogleCodeExporter]

Hm - with the latest changes, I zapped my 'build' dir in order to re-run the 
cmake generator from scratch, and it can no longer find llvm-config.  Still 
looking into why.

Original comment by lst...@gmail.com on 9 Mar 2011 at 7:56

[GoogleCodeExporter]

Try defining LLVM_CONFIG on the cmake command line.

Original comment by viri...@gmail.com on 9 Mar 2011 at 8:02

[GoogleCodeExporter]

Indeed - that helps.

Definitely struggling with my cmake noob-ness here, but now some of the LLVM 
library definitions turn up empty.  When I edit the cmake files to include the 
llvm libs that libgc needs to link against, at least temporarily to allow it to 
build, things like ${LLVM_SUPPORT} are empty, whereas they previously pointed 
to the LLVMSupport lib.

My cmake invocation, which allows the static compiler lib to build, looks like:

 cmake -D CMAKE_BUILD_TYPE=Debug -D LLVM_CONFIG=$HOME/Documents/mtcode/llvm-install/bin/llvm-config ../trunk

Original comment by lst...@gmail.com on 9 Mar 2011 at 4:51

[GoogleCodeExporter]

Ah, I can see why that would be confusing. I changed the way that the 
FindLLVM.cmake module works, there is no longer definitions for individual 
libraries such as ${LLVM_SUPPORT}. Instead, each target now calls llvm-config 
to get the set of libraries needed to build that target. Look at the 
execute_process command in the cmake file for tartc or tartln in the tools 
directory.

Original comment by viri...@gmail.com on 9 Mar 2011 at 7:02

[GoogleCodeExporter]

OK, applying that same pattern to the libgc target I'm able to continue the 
build again, but I'm getting to a point where tartc crashes with a segfault.  I 
couldn't easily figure out how to pass any helpful flags to tartc as it was 
being invoked from within cmake, so I generated an xcode project via cmake and 
tried to run it within the debugger there.  I still couldn't figure out how to 
dump the stack from within the debugger (!) so I just grabbed a screen cap for 
now, attached.

Note the 'function_' member is listed as NULL in the variable view as it's 
being called in the source view. 

This comes at the following point in my build:

[snip]

[ 23%] Compiling Tart source file tart/reflect/PrimitiveType.tart
[ 23%] Compiling Tart source file tart/reflect/Property.tart
[ 23%] Compiling Tart source file tart/reflect/PropertyList.tart
[ 23%] Compiling Tart source file tart/reflect/Proxy.tart
[ 23%] Compiling Tart source file tart/reflect/Reflect.tart
[ 23%] Compiling Tart source file tart/reflect/StreamDecoder.tart
[ 23%] Compiling Tart source file tart/reflect/Type.tart
[ 23%] Compiling Tart source file tart/reflect/TypeList.tart
[ 23%] Compiling Tart source file tart/text/encodings/Codec.tart
[ 23%] Compiling Tart source file tart/text/encodings/Codecs.tart
[ 23%] Compiling Tart source file tart/text/encodings/InvalidCharacterError.tart
[ 23%] Compiling Tart source file tart/text/encodings/MalformedInputError.tart
[ 23%] Compiling Tart source file tart/text/encodings/UTF8.tart
[ 23%] Linking libstd.bc
[ 23%] Generating dependencies for libstd.bc
[ 48%] Built target libstd
Scanning dependencies of target libtesting
[ 48%] Compiling Tart source file tart/testing/Asserts.tart
[ 48%] Compiling Tart source file tart/testing/Test.tart
[ 48%] Linking libtesting.bc
[ 48%] Generating dependencies for libtesting.bc
[ 48%] Built target libtesting
Scanning dependencies of target runtime
[ 48%] Building C object runtime/CMakeFiles/runtime.dir/lib/CoreMemory.c.o
[ 48%] Building C object runtime/CMakeFiles/runtime.dir/lib/Debug.c.o
[ 48%] Building C object runtime/CMakeFiles/runtime.dir/lib/Startup.c.o
[ 48%] Building C object runtime/CMakeFiles/runtime.dir/lib/StdFileStream.c.o
[ 50%] Building C object runtime/CMakeFiles/runtime.dir/lib/StringUtils.c.o
[ 50%] Building C object 
runtime/CMakeFiles/runtime.dir/lib/tart_eh_personality.c.o
[ 50%] Building CXX object runtime/CMakeFiles/runtime.dir/lib/gc_common.cpp.o
Linking CXX static library libruntime.a
[ 50%] Built target runtime
Scanning dependencies of target libopts
[ 50%] Compiling Tart source file tart/opts/NameConflictError.tart
[ 50%] Compiling Tart source file tart/opts/OptionBase.tart
Stack dump:
0.  Program arguments: ../../tools/tartc/tartc -g -debug-errors -sourcepath 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart 
/bin/sh: line 1: 54862 Segmentation fault      ../../tools/tartc/tartc -g 
-debug-errors -sourcepath /Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart
make[2]: *** [lib/opts/tart/opts/OptionBase.bc] Error 139
make[1]: *** [lib/opts/CMakeFiles/libopts.dir/all] Error 2

Original comment by lst...@gmail.com on 10 Mar 2011 at 8:01

Attachments:

• Screenshot.png

[GoogleCodeExporter]

OK I ran into that same problem and fixed it here, I just haven't pushed the 
changes yet. The crash happens when it tries to evaluate a global initializer 
expression that's outside of a function body. Just put an if (function_) block 
around it and it should be OK.

In terms of debugging, here's what I usually do: From the shell, do "make 
VERBOSE=1" which causes cmake to print out the command lines with all the 
arguments. Then I cd to the correct directory, copy the command from cmake's 
output, and do "gdb --args " and then paste.

Original comment by viri...@gmail.com on 10 Mar 2011 at 8:14

[GoogleCodeExporter]

OK, progress...and on to the next failure :)

The test/unit/unittest target runs successfully, and now I'm seeing some 
compile errors in the following tart source:

Compiling Tart source file tartx/lexgenTest/shared//ScannerBaseTest.tart
[ 54%] cd /Users/liam/Documents/mtcode/tart/build/tools/lexgen && 
../tartc/tartc -g -debug-errors -sourcepath 
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/testing -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src 
tartx/lexgenTest/shared//ScannerBaseTest.tart
Compiling Tart source file tart/opts/OptionBase.tart
cd /Users/liam/Documents/mtcode/tart/build/lib/opts && ../../tools/tartc/tartc 
-g -debug-errors -sourcepath /Users/liam/Documents/mtcode/tart/trunk/lib/opts 
-i /Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgen/shared/Sca
nnerBase.tart:36: error: Expected semicolon, not If
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:10: error: Undefined type 'ScannerBase'
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:15: error: read huh?
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:39: error: Undefined member 'tokenText'
info: Scoped searched:
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:39: info:   TestScanner
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:49: error: Undefined member 'take'
info: Scoped searched:
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:49: info:   TestScanner
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:71: error: Undefined member 'take'
info: Scoped searched:
/Users/liam/Documents/mtcode/tart/trunk/tools/lexgen/src/tartx/lexgenTest/shared
//ScannerBaseTest.tart:71: info:   TestScanner
make[2]: *** [tools/lexgen/tartx/lexgenTest/shared/ScannerBaseTest.bc] Error 1
make[1]: *** [tools/lexgen/CMakeFiles/lexgenTest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/usr/local/Cellar/cmake/2.8.3/bin/cmake -E cmake_progress_report 
/Users/liam/Documents/mtcode/tart/build/CMakeFiles 
[ 54%] Compiling Tart source file tart/opts/StringOption.tart
cd /Users/liam/Documents/mtcode/tart/build/lib/opts && ../../tools/tartc/tartc 
-g -debug-errors -sourcepath /Users/liam/Documents/mtcode/tart/trunk/lib/opts 
-i /Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/StringOption.tart
/Users/liam/Documents/mtcode/tart/trunk/compiler/lib/Gen/CodeGenCall.cpp:313: 
Assertion failed (gcAllocContext_ != NULL)
   tart::CodeGenerator::genNew(tart::NewExpr const*) + 355
   tart::CodeGenerator::genExpr(tart::Expr const*) + 1582
   tart::CodeGenerator::genArgExpr(tart::Expr const*, bool) + 1257
   tart::CodeGenerator::genCall(tart::FnCallExpr const*) + 547
   tart::CodeGenerator::genExpr(tart::Expr const*) + 1520
   tart::CodeGenerator::genGlobalVar(tart::VariableDefn const*) + 1460
   tart::CodeGenerator::genVarValue(tart::VariableDefn const*) + 139
   tart::CodeGenerator::genXDef(tart::Defn*) + 258
   tart::CodeGenerator::generate() + 608
   tart::Compiler::processInputFile(llvm::StringRef) + 2718
   main + 449
   start + 52
Stack dump:
0.  Program arguments: ../../tools/tartc/tartc -g -debug-errors -sourcepath 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart 
/bin/sh: line 1: 76035 Illegal instruction     ../../tools/tartc/tartc -g 
-debug-errors -sourcepath /Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/std -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts -i 
/Users/liam/Documents/mtcode/tart/trunk/lib/opts tart/opts/OptionBase.tart
make[2]: *** [lib/opts/tart/opts/OptionBase.bc] Error 132
make[1]: *** [lib/opts/CMakeFiles/libopts.dir/all] Error 2

Original comment by lst...@gmail.com on 10 Mar 2011 at 4:29

[GoogleCodeExporter]

OK that's another change I haven't checked in yet. I removed lexgen from the 
list of targets that are built, since it's an experimental project that's 
barely started.

Try doing a "make check".

Original comment by viri...@gmail.com on 10 Mar 2011 at 5:09

[GoogleCodeExporter]

Ah, make check finally gets me to the point where I see the multiple 
definitions of opts from the command line that you had previously mentioned.  
Will see what I can find.

Original comment by lst...@gmail.com on 10 Mar 2011 at 6:19

[GoogleCodeExporter]

OK, some progress, although not fully resolved just yet.  This linking issue 
appears to be a known constraint in LLVM in particular, and they have some 
tools to help.  At <llvmroot>/cmake/moculdes/AddLLVM.cmake in the LLVM source 
tree, macro(add_llvm_loadable_module name) exists, which appears to contain the 
linker options required on both OS X and Linux to create a library that 
appeases opt & llc.  

Note that LLVM_ON_UNIX must be defined in order for add_llvm_loadable_module() 
to work properly - in LLVM, this gets done in llvm-config.h, and I've just hard 
coded it manually for now.  Not sure ultimately what the best way to handle 
that will be.

So I've copied those cmake modules over to the tart source tree, and made some 
local mods to the CMakeLists file in tart/trunk/linker that look a bit like:

include(AddLLVM)

... rest of file ...

execute_process(
  COMMAND ${LLVM_CONFIG} --libs all
  OUTPUT_VARIABLE LLVM_ALL_LIBS
  OUTPUT_STRIP_TRAILING_WHITESPACE
)

add_llvm_loadable_module(gc SHARED ${GC_SOURCES} ${GC_HEADERS})
set_target_properties(gc PROPERTIES LINK_FLAGS "${LD_FLAGS} ${LLVM_LD_FLAGS}")
target_link_libraries(gc ${LLVM_ALL_LIBS})

This builds successfully, but appears to name the resulting library gc.dylib 
instead of libgc.dylib - opt appears to expect the latter, so it's currently 
failing to find it.  Still looking into this last part, but I'm hopeful that 
this is the appropriate solution to this issue.

Original comment by lst...@gmail.com on 13 Mar 2011 at 1:08

[GoogleCodeExporter]

OK, success!  I modified tart/trunk/test/stdlib/CMakeLists to look for gc.dylib 
and reflector.dylib, without the lib prefix, and removed the 
set_target_properties() and target_link_libraries() in the snippet above, since 
they were overwriting the values set internally by add_llvm_loadable_module() 
for those properties.  It looks like the lib prefix is specifically removed 
within add_llvm_loadable_module() - perhaps they don't want it named normally 
since a loadable module shouldn't be treated like a normal shared lib?

I'm now able to run make check almost to completion - several of the tart tests 
run (ArrayTest, ArithmeticOperatorTest.run, a few others), but I'm seeing a 
failure in one of them:

Scanning dependencies of target ArrayListTest.run
[Running] ArrayListTest.testConstruct
[Running] ArrayListTest.testImplicitType
[Running] ArrayListTest.testOutOfRange
Unsupported exception encoding type 155
/bin/sh: line 1: 37983 Abort trap              ./ArrayListTest
make[3]: *** [test/stdlib/CMakeFiles/ArrayListTest.run] Error 134
make[2]: *** [test/stdlib/CMakeFiles/ArrayListTest.run.dir/all] Error 2

Original comment by lst...@gmail.com on 13 Mar 2011 at 1:34

[GoogleCodeExporter]

So where's my patch? :)

I've spent the day deep in the arcane details of Unicode character tables...

Original comment by viri...@gmail.com on 13 Mar 2011 at 3:09

[GoogleCodeExporter]

So pushy!  I guess you've probably earned the right with that unicode work...

Patch attached. Things that may not be ready to be committed as is:
- hard coding the LLVM_ON_UNIX define
- the amount of cmake module material copied over from the llvm tree...can 
probably trim just what we need out of it, but have not gone through there just 
yet

Please also note there are a couple more compile errors fixed in this patch - 
include paths pointing to System instead of Support within llvm, etc

Original comment by lst...@gmail.com on 13 Mar 2011 at 3:27

Attachments:

• loadable_modules.diff

[GoogleCodeExporter]

Improved patch attached:
- don't hard code the platform detection for building loadable modules
- only minimum amount of cmake infrastructure pulled over form LLVM source tree

Original comment by lst...@gmail.com on 14 Mar 2011 at 5:41

Attachments:

• loadable_modules_v2.diff

[GoogleCodeExporter]

Cool, thanks. I worked on it a bit today.

Original comment by viri...@gmail.com on 14 Mar 2011 at 6:11

[GoogleCodeExporter]

OK well, I made some changes, and things are building, but all of the unit 
tests are crashing. This is on OS X Leopard (I don't have Snow Leopard) so it's 
possible that it's a 32-bit vs 64-bit issues - I've had some troubles with that 
in the past.

It turns out that I only needed to take a few lines from your cmake script to 
get the plugins to build:

if (APPLE)
  # Darwin-specific linker flags for loadable modules.
  set_target_properties(gc PROPERTIES LINK_FLAGS "-Wl,-flat_namespace -Wl,-undefined -Wl,suppress")
  set_target_properties(reflector PROPERTIES LINK_FLAGS "-Wl,-flat_namespace -Wl,-undefined -Wl,suppress")
endif()

At least it *seems* like everything is building, although I may be missing 
something.

So anyway, I'm still trying to track down why the unit tests are crashing. 
Unfortunately, it looks like DWARF debugging is broken - *again* - and so I 
spent some time trying to figure out why, with no luck.

Original comment by viri...@gmail.com on 14 Mar 2011 at 10:19

[GoogleCodeExporter]

Does the output from the unit tests look different than the failure I pasted 
above, ie, with the "Unsupported exception encoding type 155" errors?  I'm on 
Snow Leopard, and those are the only ones I see, but quite a few tests seem to 
be affected by it.

I guess the only other part of the cmake logic around loadable modules that 
might be worth retaining is printing an error and bailing for platforms on 
which they're not supported, namely non-cygwin Windows.

Original comment by lst...@gmail.com on 15 Mar 2011 at 12:45

[GoogleCodeExporter]

Actually, that "unsupported exception encoding type" is not a hard problem to 
fix, now that I think about it. That message comes from tart_eh_personality.c, 
which contains the exception personality function for Tart exceptions. 
Basically, I was too lazy to support all of the various compression types for 
DWARF exception tables, so I only coded the ones I actually needed. We'll just 
need to add a few more.

Original comment by viri...@gmail.com on 15 Mar 2011 at 1:08

[GoogleCodeExporter]

Cool. If it's easy enough to describe the issue a bit, I'd be happy to dig into 
it - not a great of idea just where to jump in at the moment, but seems like it 
could be a good small chunk to learn from.  Presumably the encodings in 
question correspond to an emission somewhere...?

Original comment by lst...@gmail.com on 16 Mar 2011 at 4:56

[GoogleCodeExporter]

You are a brave soul, my friend. The arcane world of DWARF exception tables is 
not for the faint of heart.

However, here's a starting point:

http://src.gnu-darwin.org/src/contrib/gcc/unwind-pe.h.html

That's a fragment of code from the GNU libc that decodes the exception tables. 
If you compare that with tart_eh_personalty.c, you'll see that there are a few 
more encoding types defined in that file. What needs to happen is that we have 
to fill in the blanks in the functions "readEncodedValue" and 
"encodedValueSize".

The DWARF standards docs are here: http://www.dwarfstd.org/Download.php. Don't 
look at the 1.0 standard, it's obsolete. I usually use the 3.0 or 4.0 doc.

There is of course the docs referred to on the llvm.org site:

http://llvm.org/docs/ExceptionHandling.html
http://www.codesourcery.com/public/cxx-abi/abi-eh.html

There is also this document which (I think) is the key to understanding all of 
this, or at least it was for me:

http://www.codesourcery.com/public/cxx-abi/exceptions.pdf

So all this stuff is emitted by the LLVM code generator, in response to my 
frontend calling the various LLVM exception intrinsics.

The first step will be to determine what the encoding value is that's failing, 
and then see what that translates to in DWARF terms. Then see how libc handles 
that encoding type.

In the mean time, I'm working on updating the docs...

Original comment by viri...@gmail.com on 16 Mar 2011 at 5:28

[GoogleCodeExporter]

Well, with all that info it's easy to cheat a bit and resolve just the errors 
I'm currently seeing, without fully understanding the entire context - that 
does indeed seem like a ton of info to sift through.  Patch is attached that 
addresses the exception handling errors I was seeing.

But I'm still seeing an abort() in ArrayListTest that does not appear to be 
coming from tart_eh_personalty.c.  to be continued...

Original comment by lst...@gmail.com on 16 Mar 2011 at 6:51

[GoogleCodeExporter]

Woops - patch attached here.

Original comment by lst...@gmail.com on 16 Mar 2011 at 6:52

Attachments:

• eh.diff

[GoogleCodeExporter]

May not be able to get around it so easily for the next abort - I'm seeing the 
following error, but still looking:

Starting program: 
/Users/liam/Documents/mtcode/tart/build/test/stdlib/ArrayListTest 
Reading symbols for shared libraries ++. done
[Running] ArrayListTest.testConstruct
[Running] ArrayListTest.testImplicitType
[Running] ArrayListTest.testOutOfRange

Program received signal SIGABRT, Aborted.
0x00007fff82022616 in __kill ()
(gdb) bt full
#0  0x00007fff82022616 in __kill ()
No symbol table info available.
#1  0x00007fff820c2cca in abort ()
No symbol table info available.
#2  0x00007fff82039391 in unwind_phase2 ()
No symbol table info available.
#3  0x00007fff82042c6b in _Unwind_Resume ()
No symbol table info available.
Dwarf Error: Cannot find DIE at 0xe5 referenced from DIE at 0x1a6 [in module 
/Users/liam/Documents/mtcode/tart/build/test/stdlib/ArrayListTest]

Original comment by lst...@gmail.com on 16 Mar 2011 at 3:38

[GoogleCodeExporter]

Patch applied, thanks.

I see that I'm getting unit test crashes on OS X now (not as a result of your 
patch), which means that something broke within the last couple of days. 
Unfortunately with debugging info being broken as well, it's kind of hard to 
track down. It's also possible that something is broken in LLVM, as there are 
known problems with emitting DWARF.

Original comment by viri...@gmail.com on 16 Mar 2011 at 5:54

[GoogleCodeExporter]

A couple of other questions that might be relevant:

Are all the unit tests failing, or just a few? (You can run single tests via 
"make <testname>.run", and you can get a list of all make targets with "make 
help".)

_Unwind_Resume() is only called if an exception is being resumed - this happens 
when there is no catch block to catch the exception, but there is a "finally" 
block that needs to execute before the exception can propagate upwards. The 
weird part is that I don't think there's any code written yet that uses 
"finally" block except for ExceptionTest. So I can't think of any reason why 
_Unwind_Resume() would be called.

One thing you might try is to liberally sprinkle calls to Debug.writeLn() in 
the offending test.

Original comment by viri...@gmail.com on 17 Mar 2011 at 6:17

[GoogleCodeExporter]

There are several passing tests: ArithmeticOperatorTest, AtomicTest, ArrayTest, 
BitTricksTest, CharacterTest at the very least.  ArrayListTest is the first 
that fails.  I'll poke around in ArrayListTest a bit more via Debug.writeLn() 
to see if anything looks suspicious.

Original comment by lst...@gmail.com on 17 Mar 2011 at 3:08

[GoogleCodeExporter]

Actually, a quick inspection makes it look like exception handling is at fault. 
 I think (not totally sure yet) that any test with a try/catch aborts, at the 
moment.

Original comment by lst...@gmail.com on 17 Mar 2011 at 3:17

[GoogleCodeExporter]

One thing to investigate is alignment and padding issues with the exception 
structure. The class Throwable has within it a declaration of the exception 
structure needed by libunwind. That same structure is declared within 
tart_eh_personality.c. Both the C version and the Tart version have to match.

Original comment by viri...@gmail.com on 17 Mar 2011 at 4:26

[GoogleCodeExporter]

I haven't figured out how best to determine the size of the Tart 
representation, but the C representation - sizeof(struct TartThrowable) - is 24 
bytes, though I see some offsets of 26 being returned from findCallSite() and 
friends which seems a bit suspicious.

Any tips on how I can verify the size of the tart representation of a Throwable 
object?

Original comment by lst...@gmail.com on 18 Mar 2011 at 7:10