<CeBot>
asterite: collect2: error: ld returned 1 exit status
<asterite>
I guess there's no llvm in the playpen :)
<asterite>
It crashes if you don't do LLVM.init_x86, but it works if you run that
<asterite>
The big problem with this project is that chances of doing blame and finding my name are very high :(
<jhass>
I tried binding LLVMGetTargetFromName
<jhass>
and hardcoding "x86" and "x86-64" respectively
<jhass>
which works
<jhass>
but I don't think adding a param for that would be good/needed
<jhass>
the triple should already identify it I think
<jhass>
that stuff still confuses me somewhat tbh
<jhass>
that init thing threw /usr/lib/crystal/io.cr:242: undefined method 'inspect' for Void btw
<jhass>
finding the useful line to return in crystals error output is hard :P
<asterite>
Mmm... I think Void has no methods, it doesn't even inherit Object, I think
<asterite>
But maybe we should make all types inherit Object... the same goes with a C struct, you can't to_s or inspect it, but it should be possible
<asterite>
The only hard thing would be to do a to_s for a C union... for that we might just say "C union" and that' it, I guess
<asterite>
For the LLVM issue, I think getting the target from the triple should work
<jhass>
yeah, except now I'm getting linker errors
<asterite>
Is it against LLVM 3.5?
<jhass>
3.5.1, yep
<jhass>
ah, cleanup helped
<asterite>
The problem now is that I do: puts LLVM::Target.from_triple "x86_64-apple-darwin14.0.0"; puts LLVM::Target.from_triple "x86_64-unknown-linux-gnu"
<asterite>
and it says "x86-64 - 64-bit X86: EM64T and AMD64" the two times
<asterite>
Mmm... I should try with 32
<asterite>
What's the target triple for a 32 bits linux machine?
<jhass>
i686-pc-linux-gnu
<jhass>
I hope
<jhass>
the -gnu is probably not needed
<asterite>
Good, it worked. I get: x86 - 32-bit X86: Pentium-Pro and above
<asterite>
If you want, I can try to fix this issue by creating an LLVM target using the triple that you pass when you cross compile
<jhass>
yeah, that's what I'm trying locally too atm
<jhass>
asterite: works like a charm <3. Now I can work on adding 32bit versions to the crystal AUR packages so I can built a 32bit chroot for playpen on my VM so I can move the bot there
<asterite>
jhass; awesom!
<asterite>
with an e
<jhass>
did I mention I like indirection? :D
<jhass>
the bot puts your code into a template ;)
<asterite>
And I guess we'll start distributing 32 bits binaries in the releases (maybe not in the next one)
<jhass>
yeah, I'll just upload a 32bit binary somewhere for the time being
<asterite>
I didn't know about String#rjust and ljust... yes, they seem fun (and easy) to implement
<asterite>
>> Time.now
<CeBot>
asterite: 2015-01-25 19:53:25
<asterite>
>> {{ `ls`.join(" ") }}
<CeBot>
asterite: Error in line 3: expanding macro
<asterite>
>> {{ `ls`.split('\n').join(" ") }}
<CeBot>
asterite: ""
<asterite>
>> {{ `pwd`.stringify }}
<CeBot>
asterite: "/home/crystal\n"
CeBot has quit [Quit: Crystal]
CeBot has joined #crystal-lang
<jhass>
>> {{ `ls`.join(" ") }}
<CeBot>
jhass: in line 3: undefined macro method StringLiteral#join'
<jhass>
:)
<asterite>
Cool! :)
<asterite>
I got a crystal 32 bits on a trusty32 VM
<jhass>
yay
<jhass>
so the hmac error is still there of course
<asterite>
I guess, I didn't try it. I get a segfault at this: puts({1 => 2} == {1 => 2})
<asterite>
It's a pretty small program, but it still has Hash, so it could be smaller
<jhass>
spec/compiler/codegen/alias_spec.cr fails
<asterite>
I tried cross-compiling that program to 32 bits and it works
<jhass>
fails = segfaults
<asterite>
but that program, compiled with the 32 bits compiler, fails
<jhass>
yeah, that's what I'm experiencing too
<jhass>
which is why I guess that the target triple is not correctly autodetermined or something like that
<asterite>
I'm sure it's just one or two tiny things we have to change/fix, but they'll be hard to find
<jhass>
how do we actually generate the target triple when there's none given?
<jhass>
same question for cpu
<asterite>
It's LLVM::default_target_triple
<asterite>
it's a method from LLVM
<jhass>
ah
<asterite>
I think it returns the same as `llvm-config --host-targets`
<jhass>
yeah, if it wasn't that it would've been my suggestions
<jhass>
I asked because while building the sandbox I noticed a call to uname -m -s
<asterite>
Ugh, it gives me "i386-pc-linux-gnu"
<jhass>
mmh
<asterite>
while `llvm-config --host-target` gives me "i686-pc-linux-gnu"
<asterite>
Is there a difference?
<jhass>
yes and no
<jhass>
both should yield x86 as cpu
<jhass>
same for i486, i586,
<asterite>
`uname -m -s` is invoked to get the flags that you use in ifdef, so I don't think that's the problem
<jhass>
but I guess the instruction set is slightly different
<asterite>
I'll try to cross-compile against i386
<asterite>
It still segfaults
<jhass>
so what about the cpu/mcpu thingy, where does that come from if not passed?
<asterite>
I see we pass "" to it, and I guess LLVM tries to figure it out
<asterite>
but I tried also specifying it with the --cpu option and it fails too, so maybe that's not it
<asterite>
Hash#== fails, so I'm trying to write a Hash2 class and reduce it to find the problem
zamith has quit [Quit: Be back later ...]
zamith has joined #crystal-lang
<asterite>
jhass: Well, I found something. Now more specs pass, but some still fail, so I have to continue investigating... I guess it'll take me a lot of time, but eventually we'll make it :)
<jhass>
cool
<jhass>
not to sidetrack but
<jhass>
>> def foo &block : String ->; end
<CeBot>
jhass: Failed to run your code, sorry!
<jhass>
eh
<jhass>
Syntax error in eval:3: \e[1munexpected token: &\e[0m\n
<jhass>
asterite: I got a list failing spec files (hmac, segfaults, one failure in complex) prior your last commit now, should I post it?
<asterite>
Should, it can help
<asterite>
I'll also post short snippets that fail
<asterite>
I think there might be an issue with libunwind bindings or llvm exception-related issues (landing pad, etc.)... so I'll have to check with @waj to continue