version of llvm should not be hardcoded

[joshgoebel]

• The "from sources" directions mention brew install --with-llvm which
  installs llvm as llvm, not with a version suffix
• So lets try all the options until we find a working llvm

[refi64]

Aren't there major API changes between LLVM versions?

[joshgoebel]

The docs all mention 3.5.1, and it seems to work for me. If 3.6 is required then the docs need to be updated to say so and it probably should not fail with an obscure error if it's obvious 3.6 is not even installed.

[waterlink]

Look at the Travis script. If you want to compile compiler, you would need
patched llvm version.
On Apr 27, 2015 4:22 AM, "Josh Goebel" notifications@github.com wrote:

The docs all mention 3.5.1, and it seems to work for me. If 3.6 is
required then the docs need to be updated to say so and it probably should
not fail with an obscure error if it's obvious 3.6 is not even installed.

—
Reply to this email directly or view it on GitHub
#582 (comment).

[joshgoebel]

It compiles (and compiles itself) just fine with 3.5.1 it seems.

[joshgoebel]

You're basically saying these directions are entirely wrong: http://crystal-lang.org/docs/installation/from_source_repository.html

Yes?

[waterlink]

I don't know for sure. But if you look to contributing.md guide, it says,
that you need to look into travis.yml. And travis.yml downloads patched
llvm. @asterite said that there was some bug, that is fixed in this patched
version. But it is probably only if you would like to work on compiler
itself. If you need just standard library from master branch, then that
should still work.

Best Regards,
Alexey Fedorov,
Sr Ruby Developer, Clojure Developer, Rust Developer,
+49 15757 486 476

2015-04-27 15:04 GMT+02:00 Josh Goebel notifications@github.com:

You're basically saying these directions are entirely wrong:
http://crystal-lang.org/docs/installation/from_source_repository.html

Yes?

—
Reply to this email directly or view it on GitHub
#582 (comment).

[joshgoebel]

I'll ping @asterite. Sounds like perhaps this should not change but that the docs need to be updated a bit. @asterite Can you confirm llvm36 is no good? The Makefile tries to use it from homebrew if it's installed.

[will]

For me, even with the patched LLVM, I get a segfault on the size_of specs. Using llvm36, everything is fine.

crystal ➤ bin/crystal build spec/compiler/codegen/sizeof_spec.cr                                                                                                                                                                                        git:master*
zsh: correct 'build' to '.build' [nyae]? n
Using compiled compiler at .build/crystal
crystal ➤ ./sizeof_spec                                                                                                                                                                                                                                 git:master*
.....[1]    55639 segmentation fault  ./sizeof_spec
crystal ➤ lldb sizeof_spec                                                                                                                                                                                                                              git:master*
(lldb) target create "sizeof_spec"
Current executable set to 'sizeof_spec' (x86_64).
(lldb) r
Process 55662 launched: '/Users/will/code/crystal/sizeof_spec' (x86_64)
Process 55662 stopped
* thread #1: tid = 0x32f95e, 0x00007fff8e5bca81 libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff8e5bca81 libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565
libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565:
-> 0x7fff8e5bca81:  movq   (%rax), %rdx
   0x7fff8e5bca84:  movq   %rdx, 0x8(%rcx)
   0x7fff8e5bca88:  jmp    0x7fff8e5bcab5            ; libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 617
   0x7fff8e5bca8a:  movq   (%rax), %rdx
(lldb) bt
* thread #1: tid = 0x32f95e, 0x00007fff8e5bca81 libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff8e5bca81 libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565
    frame #1: 0x00007fff8e5ba33b libunwind.dylib`libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncoding(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&) + 41
    frame #2: 0x00007fff8e5ba2e1 libunwind.dylib`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() + 113
    frame #3: 0x0000000100006e63 sizeof_spec`*caller:Array(String) + 115
    frame #4: 0x00000001006ff32e sizeof_spec`*Exception@Exception#initialize<Errno, String>:Array(String) + 46
    frame #5: 0x00000001006ff2f0 sizeof_spec`*Errno#initialize<Errno, String>:Array(String) + 128
    frame #6: 0x00000001006ff249 sizeof_spec`*Errno::new<String>:Errno + 105
    frame #7: 0x00000001009278b7 sizeof_spec`*IO::select<(Nil | {FileDescriptorIO}), (Nil | {FileDescriptorIO}), Nil, Nil>:Array(IO)? + 4919
    frame #8: 0x000000010092651b sizeof_spec`*IO::select<(Nil | {FileDescriptorIO}), (Nil | {FileDescriptorIO}), Nil>:Array(IO) + 59
    frame #9: 0x00000001009264d9 sizeof_spec`*IO::select<(Nil | {FileDescriptorIO}), (Nil | {FileDescriptorIO})>:Array(IO) + 57
    frame #10: 0x00000001009246a8 sizeof_spec`*Process::run:input:output<String, String, Bool>:Process::Status + 2008
    frame #11: 0x0000000100008817 sizeof_spec`*`<String>:String + 39
    frame #12: 0x000000010030a06d sizeof_spec`*Crystal::Program#flags<Crystal::Program>:Set(String) + 77
    frame #13: 0x000000010030a37e sizeof_spec`*Crystal::Program#has_flag?<Crystal::Program, String>:Bool + 14
    frame #14: 0x000000010034d750 sizeof_spec`*Crystal::Program#load_libs<Crystal::Program>:Array(Crystal::LinkAttribute) + 32
    frame #15: 0x000000010034d583 sizeof_spec`*Crystal::Program#run<Crystal::Program, String, Nil>:LLVM::GenericValue + 115
    frame #16: 0x0000000100009e40 sizeof_spec`*run<String, Nil>:(Crystal::SpecRunOutput | LLVM::GenericValue) + 688
    frame #17: 0x0000000100009b73 sizeof_spec`*run<String>:(Crystal::SpecRunOutput | LLVM::GenericValue) + 19
    frame #18: 0x000000010000482f sizeof_spec`__crystal_main + 13359
    frame #19: 0x000000010000993a sizeof_spec`main + 90
    frame #20: 0x00007fff8672d5fd libdyld.dylib`start + 1
    frame #21: 0x00007fff8672d5fd libdyld.dylib`start + 1
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y

[joshgoebel]

For me, even with the patched LLVM, I get a segfault on the size_of specs. Using llvm36, everything is fine.

For me all specs pass (master @ c816cfa) with LLVM 3.5.1 + patch on Mac OS X.

[joshgoebel]

#624 might also be relevant here.

[asterite]

We finally decided that to compile the (compiled) compiler you need to have LLVM in your path, and all the required libraries.