ChanServ changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.33.0 | Fund Crystal's development: http://is.gd/X7PRtI | GH: https://github.com/crystal-lang/crystal | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/ | Gitter: https://gitter.im/crystal-lang/crystal
ur5us has joined #crystal-lang
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 260 seconds]
deavmi has quit [Ping timeout: 260 seconds]
ur5us has joined #crystal-lang
deavmi has joined #crystal-lang
<FromGitter> <Blacksmoke16> better way to get the first line of a string? `string.lines.first`, or some regex, or?
<FromGitter> <Blacksmoke16> maybe `string.each_line { |l| return l }` to avoid the array of `.lines`?
<FromGitter> <Blacksmoke16> `.each_line.first` iterator version is prob the winner
ur5us has quit [Ping timeout: 260 seconds]
<FromGitter> <Afront> @Daniel-Worrall welp, so it's not a good idea using Crystal for embedded development?
<FromGitter> <smalls12> I think he might have meant natively, cross compiling is easier
<FromGitter> <smalls12> it looks like the crystal compiler is good enough to get running on embedded
<FromGitter> <smalls12> or rather, get crystal binaries running on embedded
<FromGitter> <smalls12> I'm having difficulty getting the compiler built for ARM from my x86 machine
<FromGitter> <smalls12> he was able to and I am curious how since crystal lacks a bootstrapping method to build
<FromGitter> <smalls12> you need crystal to build crystal
<FromGitter> <smalls12> I only just got cross compiling to work now actually ⏎ I was trying to cross compile the crystal compiler, but just needed libcrystal.a ⏎ and didnt realize libgc.a was a completely separate repo lol
<FromGitter> <smalls12> I wanted to make a webserver on my rpi ⏎ but c++ has too much upfront ⏎ already did it with python somewhere else ⏎ go, despite what people keep saying, I don't find it as easy as crystal [https://gitter.im/crystal-lang/crystal?at=5e8941d09316f34b8d7ef578]
<FromGitter> <Blacksmoke16> whoa, did error messaging get updated for JSON parsing?
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5e8946315b98016d6a1552a4]
<FromGitter> <Blacksmoke16> thats quite helpful :0
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 260 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 256 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 265 seconds]
rohitpaulk has joined #crystal-lang
_ht has joined #crystal-lang
HumanGeek has joined #crystal-lang
Human_G33k has quit [Ping timeout: 250 seconds]
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 260 seconds]
<FromGitter> <deiv> Hi, about the bootstrap script for building the compiler, is there anyway to reduce the rounds ? or using the first round (from ruby) to build an actual version?
<FromGitter> <deiv> Im working on packaging crystal inside debian, by the way
<FromGitter> <deiv> Another question is, I see in the omnibus package the crsytal source installed in /usr/share (i remenber), they are needed for compiling or runtime in any way
<FromGitter> <deiv> Thanks
<FromGitter> <stronny> given that Crystal releases often, what's the plan? unstable + backports?
<oprypin> i hope people won't actually use debian's stale packages 😬
<FromGitter> <grkek> `sudo apt-get install crystal`
<FromGitter> <Blacksmoke16> Or use snap, also allows installing nighlies
<FromGitter> <deiv> @stronny normal releases, if needed backports, but first need to look if its posible to boostrap it without much hustle
<FromGitter> <deiv> @oprypin thats low blow lol
<oprypin> deiv, which rounds are you talking about? you just download an official crystal binary and then build your own crystal using that. basically 1 round
<oprypin> arch linux at first was doing that https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/crystal - see source_x86_64
<FromGitter> <grkek> Can't wait for the moment of me typing `crystal -v` and it printing out Crystal 1.0.0
<oprypin> later they declared that arch linux's crystal package needs to be installed in order to compiler arch linux's crystal package https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/crystal
<FromGitter> <deiv> @oprypin to build it without it
<oprypin> woops bad link. > arch linux at first was doing that https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/crystal&id=62b264a9db6eff92595126b56a2f54a030a268ae - see source_x86_64
<oprypin> deiv, which bootstrap script are you talking about, anyway?
<oprypin> oh https://github.com/crystal-lang/bootstrap-script/blob/master/bootstrap - wow, it's actually been done, i had no idea
<oprypin> deiv, then to answer your question, no, there is no way to reduce the rounds.
<FromGitter> <deiv> Maybe
<oprypin> you could actually try dropping those individual `stage` from the script but it's not gonna be a big win
<oprypin> even if a few of them are unnecessary
<oprypin> I'm guessing towards the end some of the releases are not necessary and are included just for completeness
<oprypin> oof. on arch linux i'm getting this error consistently now. `.build/all_spec: symbol lookup error: .build/all_spec: undefined symbol: __libc_start_main` for `make clean; make && make spec`
<FromGitter> <smalls12> did the `./build/crystal` target work ?
<FromGitter> <smalls12> I had some issues yesterday
<oprypin> i think it works, it's specific to spec because it's so big
<oprypin> posted on https://github.com/crystal-lang/crystal/issues/7177 which seems to be describing the same issue
<FromGitter> <stronny> @deiv until 1.0 Crystal changes sometimes even breaking API, so maybe you could package each version into its own package? like `crystal-0-33` or something
<FromGitter> <stronny> people are looking for older version quite often and there is an explicit version lock in shards.yml as well
<FromGitter> <Blacksmoke16> what the `crystal: 0.33.0` thing?
<FromGitter> <stronny> yeah
<FromGitter> <Blacksmoke16> that doesnt do anything
sagax has quit [Read error: Connection reset by peer]
<FromGitter> <stronny> it should
<FromGitter> <Blacksmoke16> i agree, but it doesnt atm
<FromGitter> <stronny> still, my point stands
<FromGitter> <Blacksmoke16> is just a way to represent the last known version a shard works with
<FromGitter> <Blacksmoke16> but its not enforced or anything and is up to the owner of the shard to keep up to date
<FromGitter> <stronny> that's unhelpful model being "we only have the most recent supported version available, and if you somehow end up with broken code well good luck"
<FromGitter> <stronny> I agree with breaking changes, at least there should be a way to roll them back if the need arises
<FromGitter> <stronny> by the way I don't understand this universal race to 1.0
<FromGitter> <stronny> what's gonna change? you alread have a stable API: just get the right version, it won't change on you suddenly by itself
<FromGitter> <Blacksmoke16> :shrug:
return0e_ has quit [Ping timeout: 256 seconds]
<FromGitter> <deiv> @stronny it could go without versioning and people install the one who wants
<FromGitter> <deiv> On other way, the source files (*.cr for compiler and std) are needed for compiling runtime?
<FromGitter> <deiv> Compiling or runtime**
MasterdonX has quit [Ping timeout: 256 seconds]
MasterdonX has joined #crystal-lang
return0e has joined #crystal-lang
Subsentient has joined #crystal-lang
<Subsentient> So, how far off is Crystal from Windows support? I love what I'm seeing, but most of the development I do needs to be somewhat portable.
deavmi has quit [Quit: Going into the wilderness...]
deavmi has joined #crystal-lang
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
ht_ has joined #crystal-lang
_ht has quit [Ping timeout: 260 seconds]
ht_ is now known as _ht
<oprypin> Subsentient, biggest gap is networking. other than that, u can mostly use it. compiler itself doesnt run on windows but oh well
sagax has joined #crystal-lang
<FromGitter> <stronny> wsl?
<FromGitter> <naqvis> quick question: what is the right way to pass primitives to FFI expecting input as `void*`? Tried `pointerof` but seems FF is receiving invalid value.
<FromGitter> <asterite> are exceptions already working in Windows?
rohitpaulk has quit [Ping timeout: 265 seconds]
ur5us has joined #crystal-lang
rohitpaulk has joined #crystal-lang
<oprypin> asterite, yes. well actually not sure, stack traces didnt look so good last i checked. @RX14's work, of course
rohitpaulk has quit [Ping timeout: 256 seconds]
<Stephie> exceptions work pretty well
<Stephie> backtraces are different
<Stephie> backtraces require debug info and a library to decode it
<Stephie> remember we literally implement a DWARF parser on linux and macos for this
<Stephie> windows, of course, uses something special and unique
<Stephie> actually i dont think we even have libunwind working
<Stephie> :/
<Stephie> difficult...
<Stephie> oh wow
<Stephie> libunwind doesnt use libunwind at all
<Stephie> amazing
<Stephie> i give up
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
<yxhuvud> How do other languages solve that?
<Stephie> requires research
<FromGitter> <stronny> golang solves that by not having exceptions
<FromGitter> <stronny> does it unwinds panics?
<Stephie> it can
<Stephie> optionally
<Stephie> there's an env var iirc
<Stephie> or maybe thats rust
<raz> hmm. when i have: def foo(klass : Bar.class). can i somehow make it accept also any sub-type of Bar? (e.g. it should accept Batz.class, when Batz is defined as "class Batz < Bar")
<FromGitter> <stronny> yeah, it should
<FromGitter> <stronny> have an example where it doesn't?
<raz> ah gtk that it should. hmm gonna try to create a minimal example then. perhaps my problem stems from something else and i just got lost in the type magic
<FromGitter> <perfecto25> hello everyone, quick question, how do i pretty print a JSON object?
<FromGitter> <perfecto25> i have a function that returns a JSON, 1 liner, wanted to pretty print it out
<FromGitter> <stronny> ```class A; end ⏎ class A1 < A; end ⏎ def foo(k : A.class); p k end ⏎ foo A ⏎ foo A1``` ⏎ ⏎ that works as expected [https://gitter.im/crystal-lang/crystal?at=5e8a405138198d56a1823bc2]
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
<raz> ahhh... probably something to do with me trying to do it _inside_ Foo
* raz scratches head
<FromGitter> <stronny> why do you need `as`?
<raz> just a test out of despair ;)
<raz> it doesn't work when i leave it out either
<raz> oh!
<FromGitter> <stronny> what does `Bar.class` mean as argument?
<raz> exactly
* raz facepalms
<raz> sorry for the noise, i think without the extraneous .class it should work ;)
* raz tries it
<FromGitter> <stronny> that's not noise, that's a valid question
<FromGitter> <stronny> don't beat yourself over it, happens to the best of us
<FromGitter> <stronny> @perfecto25 ``` ⏎ require "json" ⏎ ⏎ ppj = JSON.build(" ") do |jb| ⏎ [1,2,3].to_json(jb) ... [https://gitter.im/crystal-lang/crystal?at=5e8a41f01aaf8e4b8e625a23]
<FromGitter> <stronny> unfortunately seems you can only customize the indent
<FromGitter> <Blacksmoke16> you can also just do `obj.to_pretty_json`
<FromGitter> <stronny> would be great to document that!
<FromGitter> <Blacksmoke16> it is, https://crystal-lang.org/api/master/Object.html#to_json-instance-method is below the normal `.to_json` methods on `Object`
<FromGitter> <stronny> yeah, what I meant is mention it in JSON description
<FromGitter> <stronny> alternatively you may output the raw json and pipe it through `jq`
<FromGitter> <stronny> it's even may give you some colours
<FromGitter> <Blacksmoke16> https://github.com/Blacksmoke16/oq :0
_ht has quit [Remote host closed the connection]
<FromGitter> <perfecto25> thank you!
<Stephie> i've just come up with the most universe brain way of getting OptionParser to handle subcommands seamlessly
<Stephie> this is the magnum opus of command parsing
<FromGitter> <stronny> interesting you should say that, I'm also doing a magnum opus of command parsing, but sidestepping optionparser
<FromGitter> <stronny> basically I'm trying to build an adapter from an array of strings to a method signature
<Stephie> yeah thats too complex
<FromGitter> <stronny> but the most convenient to use
<Stephie> idk, OptionParser isnt so bad
<FromGitter> <stronny> if foces you to write code twice, maybe thrice
<Stephie> how so?
<FromGitter> <stronny> first the code itself, then the wrappers, then the usage
<FromGitter> <stronny> in non-trivial cases I mean
<Stephie> well thats why i'm rewiting it right now...
<Stephie> should be able to handle subcommands with a very simple tweak
<FromGitter> <stronny> as a test I would suggest to try and express all the `git` forest for example
<FromGitter> <stronny> or idk `knife`
<Stephie> whats knife?
<FromGitter> <stronny> `chef`'s admin CLI tool
<Stephie> oh
<FromGitter> <stronny> hell, even crystal itself
<Stephie> yeah
<FromGitter> <stronny> as of now its CLI suuuucks
<Stephie> thats basically my goal
<Stephie> nahh
<Stephie> it's alright
<FromGitter> <stronny> it's working
<FromGitter> <stronny> but it could be way better
<Stephie> well, what would you improve?
<Stephie> without bikeshedding and redesigning all of it
<FromGitter> <stronny> first: built-in help
<FromGitter> <stronny> it's downright inaccurate
<Stephie> where?
<FromGitter> <stronny> here ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5e8a516f9316f34b8d8136a5]
<Stephie> well
<Stephie> thats just a bug
<Stephie> not a problem with optionparser
<FromGitter> <stronny> if you say so
<FromGitter> <stronny> I say optionparser is the reason for this kind of bugs
<Stephie> so everyone writes 3000loc of complicated impenetrable macro magic
<FromGitter> <stronny> also: tab completion
<Stephie> and thats supposed to be better
<Stephie> lol
<FromGitter> <stronny> by your logic the optionparser is also superfluous complexity
<Stephie> i mean i see the point of those frameworks
<Stephie> some of them arent half bad
<Stephie> just, if they use macros, they suck
<FromGitter> <stronny> no other options
<Stephie> nahh
<FromGitter> <stronny> hey, don't let me stop you!
<Stephie> it's not hard to create a very nice DSL without macros, see https://github.com/shinzlet/phreak
<Stephie> ctrl-f macro in that repo
<Stephie> you get nothing
<FromGitter> <stronny> all the method defs are macros
<Stephie> uhh
<Stephie> no?
<FromGitter> <stronny> yes
<Stephie> where??
<FromGitter> <stronny> ask ary
<Stephie> well if thats what you understood from ary then you don't understand what he said
<Stephie> defs are very different to macros and you know it
<FromGitter> <stronny> maybe I didn't
<Stephie> defs are instantiated for every set of argument *types*
<Stephie> macros are instantiated always
<FromGitter> <stronny> why does it matter?
<Stephie> because people overuse macros in persuit of "maximum DSL beauty" and end up with brittle DSLs which shatter when you hold them slightly wrong
<FromGitter> <stronny> ```def foo(*args); end```
<Stephie> or end up not being able to handle unusual usecases
<FromGitter> <stronny> ```def foo(*args); end ⏎ foo 1 ⏎ foo 1, 2 ⏎ foo 1, 2, 3``` ⏎ ⏎ makes 3 foos, right? [https://gitter.im/crystal-lang/crystal?at=5e8a538e5b98016d6a179b3c]
<Stephie> this method takes a bunch of flags and conditionally defines a bunch of optionparser flags based on them
<Stephie> this isnt possible in many DSLs
<Stephie> because then that create_compiler needs to be a macro
<Stephie> and define them at compile time
<Stephie> and now you have {{}} everywhere
<Stephie> and your eyes hurt
<Stephie> macros are a port of last call
<Stephie> they're a last resort
<Stephie> and the ruby-loving core crystal community refuses to take this to heart
<FromGitter> <stronny> no, I feel you
<FromGitter> <stronny> just sometimes you only has this last resort
<Stephie> well, I think that phreak proves that this last resort is unneccesary for option parsing
<FromGitter> <stronny> well it's neccesery for my take on it
<Stephie> well i'm calling your take unneccesary
<Stephie> :P
<FromGitter> <stronny> okay, you are free to not use it! =)
<Stephie> i won't :)
<FromGitter> <stronny> that implies that I'm gonna be able to finish it of course lol
<Stephie> same
<Stephie> thanks adhd
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 250 seconds]
<Stephie> http://owo.sh/3nbhPy9.txt :))))))))
<Stephie> spec passes
<Stephie> diff of 3 loc
<Stephie> okay, after i rewrote the entire optionparser
<Stephie> oprypin, how do you mean?
<oprypin> Stephie, well if one wants Process support on Windows, they could choose either of those two as the starting point, and your seems more idiomatic
<Stephie> it's been so long
<oprypin> yes
<Stephie> i remember looking at both and going like
<Stephie> "well they're not so far off the difference is mostly style"
<Stephie> damn the windows process file is like twice the size on the new PR
<Stephie> oprypin, if you have the will to bring that commit up to date, please,,
<Stephie> it's better than that PR, but
<Stephie> i just dont have the energy to care any more
<oprypin> welp, yes, that's the current plan
<Stephie> thanks
<Stephie> it's really appreciated
<Stephie> yay, more people to add to the "burnt out over adding windows support" pile of bodies
<oprypin> it's cursed :3
<Stephie> definitely :3
<Stephie> at least i trust you to have a sense of style
<oprypin> aw, thanks.
<Stephie> ...did macos CI fail in your PR because circleci tried to run it in the context of your fork oprypin??
<Stephie> thats so broken
<FromGitter> <deiv> @RX14 stupid question hehe should the bootstrap-script works without touching anything ?
<oprypin> Stephie, yea i think so
<Stephie> lol
<Stephie> @deiv which bootstrap script? For windows?
<Stephie> ohhh
<Stephie> that one
<FromGitter> <deiv> yep
<FromGitter> <deiv> xD
<Stephie> i mean it has to download stuff
<Stephie> what do you mean by "touching anything"?
<Stephie> it's certified working on my machine a year ago
<FromGitter> <deiv> without change any line of code ... mostly from bash
<Stephie> which means... approximately nothing
<Stephie> @deiv try it...
<Stephie> it *should* be fairly robust
<FromGitter> <deiv> im having linking problems
<Stephie> okay
<Stephie> that sounds, about right
<Stephie> can you show me?
<FromGitter> <deiv> lots ot them xD
<FromGitter> <deiv> for example /usr/bin/ld: /home/deiv/dev-dinamic/debian/pkgs/crystal/bootstrap-script/buildroot/llvm33/lib/libLLVMSupport.a(Errno.o): en la función `llvm::sys::StrErrorabi:cxx11 (int)': ⏎ Errno.cpp:(.text+0x6b): referencia a `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' sin definir
<FromGitter> <deiv> in round 3
<Stephie> oh god
<Stephie> if llvm33 doesnt build thats pretty cursed
<FromGitter> <deiv> if I add "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr"
<FromGitter> <deiv> to it
<FromGitter> <deiv> I get some ld problems asking for lpthread
<Stephie> could you send me a pastebin/gist/whatever of the build log?
<FromGitter> <deiv> @RX14 ^^^^^
<FromGitter> <deiv> by the way - the url for openssl dont works ;-wget -O "$downloads"/openssl-1.0.2q.tar.gz https://www.openssl.org/source/openssl-1.0.2q.tar.gz ⏎ +wget -O "$downloads"/openssl-1.0.2q.tar.gz https://ftp.openssl.org/source/old/1.0.2/openssl-1.0.2q.tar.gz
<FromGitter> <smalls12> probably cuz it reached eol
<Stephie> everything rots, nothing is free from decay and death
<FromGitter> <deiv> :D
<Stephie> anyway, im glad you found a good workaround for some of those linking errors
<Stephie> i'd rather that, you know, LLVM actually worked out of the box
<Stephie> without being cursed
<FromGitter> <smalls12> llvm-3.3, could you use a newer version ? ⏎ ( just observing in the background here ;p )
<FromGitter> <kingsleyh> Evening
<Stephie> @smalls12 nope, that crystal version supports only that old LLVM version
<Stephie> LLVM versions have breaking changes
<Stephie> so it's difficult to upgrade
<Stephie> using something with a sane toolchain like arch linux might still build
<FromGitter> <deiv> @RX14 so... this thing will never be updated, I guess ...
<Stephie> I could try it again
<FromGitter> <smalls12> would it be better in the long run to make it work with newer llvm ? what kind of estimate would you think it would take ?
<FromGitter> <deiv> Im looging for a way to build crystal without crystal ... but the build depends are very outdated for what I need it
<Stephie> what's the usecase?
<Stephie> fun?
<oprypin> smalls12, would it be better in the long run to port every past version of Crystal every time a new version of LLVM comes out? no, probably not
<FromGitter> <deiv> @RX14 packaging into debian without uploading a previous binary build of crystal
<Stephie> you're part of debian packaging team?
<FromGitter> <smalls12> I understand, but its several major revisions behind, not worth it everytime I agree
<FromGitter> <deiv> @RX14 what team ? Im on my own, atm ...
<Stephie> oh
<Stephie> so this isn't an effort to get it into debian as an official package?
<FromGitter> <deiv> yes yes, official would be :)
<Stephie> ah
<FromGitter> <deiv> and the other user case is to use the bootstrapped binaries rather than the prebuilt ones (if I built crystal from source uploading previously a binary package)
<FromGitter> <deiv> so, getting a bootstrap script with using only actual libraries (llvm8, ruby2-x, etc) is something "imposible" ? I guess ...
<Stephie> yes
<Stephie> it's impossible
<Stephie> the only other avenue for a clean bootstrap is to write another crystal compiler
<Stephie> or interpreter
<Stephie> it wouldn't be *terrible*, just pretty hard
<Stephie> okay
<Stephie> it'd be terrible
<Stephie> and pretty hard
<FromGitter> <deiv> lol
<FromGitter> <deiv> and getting the current one working ? :)
<FromGitter> <deiv> that way could build a crystal compiler without use a precompiled one
<Stephie> well
<Stephie> i'll see if it works on arch linux
<FromGitter> <deiv> thanks !
<Stephie> if it does, then i can solidly blame debian's build environment
<FromGitter> <deiv> ok :)
<FromGitter> <deiv> hehe
<Stephie> well
<Stephie> or maybe my non-portable script
<Stephie> if you can figure out what's the root cause of the link errors i can know who to blame :P
<FromGitter> <deiv> If I add "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr" I get: /usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error al añadir símbolos: DSO faltante desde línea de orden
<Stephie> what's that in english >_<
<FromGitter> <deiv> in round3
<Stephie> wait
<FromGitter> <smalls12> would there ever be a need to update that compiler? ⏎ or in its current state, should be more than sufficient for the some time to come
<FromGitter> <deiv> maybe it needs -lpthread.
<FromGitter> <deiv> ?
<Stephie> is this with *debian's* llvm-3.3??
<FromGitter> <deiv> not
<Stephie> yeah it probably does need -lpthread
<FromGitter> <deiv> the downloaded onw
<FromGitter> <deiv> one
<Stephie> are you sure there's no /usr/lib<whatever debian shit uses>/libLLVM-3.3.{so,a}??
<FromGitter> <deiv> no, I have llvm{8,9}
<Stephie> huh
<Stephie> interesting
<Stephie> i wouldnt have expected it to work
<Stephie> since the script simply tells the compiler where llvm-config is
<Stephie> from the built LLVM
<Stephie> so -lLLVM-3.3 should find nothing...
<Stephie> oh damn
<Stephie> LLVM with autotools build
<Stephie> this is ancient
<FromGitter> <deiv> ldd stages/2-crystal ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5e8a67c85d148a0460e891f6]
<Stephie> well that looks like the correct llvm-3.3.so
<Stephie> and that binary works?
<FromGitter> <deiv> it building stages/3-crystal
<FromGitter> <deiv> I guess, yes
<Stephie> really weird
<Stephie> wait
<Stephie> i forgot entirely how i did this script
<FromGitter> <deiv> maybe libpthread needs to be explcitily in cc commandline ?
<FromGitter> <deiv> "llvm-config --libs --ldflags" gives: -lz -lpthread -ldl -lm
<Stephie> that's...
<Stephie> @deiv what about buildroot/bin/llvm-config --libs --ldflags?
<FromGitter> <deiv> -L/home/deiv/dev-dinamic/debian/pkgs/crystal/bootstrap-script/buildroot/llvm33/lib -lz -lpthread -ldl -lm ⏎ -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMIRReader -lLLVMAsmParser -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInstrumentation -lLLVMArchive
<FromGitter> ... -lLLVMBitReader -lLLVMInterpreter -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMBitWriter -lLLVMMCJIT -lLLVMJIT -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport
<Stephie> well
<Stephie> that makes sense
<Stephie> i wonder why i did that on stage2
<Stephie> and why stage2 works
<Stephie> and why the heck stage3 *doesn't*
<FromGitter> <deiv> maybe stage2 compiler needs something ?
<Stephie> nah
<Stephie> this is linking stuff
<Stephie> if stage2 was broken it would run
<FromGitter> <deiv> stage3 without "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr" can't find nothing I guess
<Stephie> this is somewhat disturbing
<FromGitter> <deiv> remember the gist :D
<Stephie> yeah
<Stephie> well
<Stephie> i'll figure out wtf i was thinking 2 years ago tomorrow :)
<Stephie> I'll probably boot a debian container and try it
<Stephie> is this debian stable or debian unstable @deiv ?
<FromGitter> <deiv> dont blame much then
<FromGitter> <deiv> testing/unstable/experimental
<Stephie> oke
<Stephie> i'll try it in a sid container tomorrow i guess
<FromGitter> <deiv> testing having pirority (so i thiun testing woud be the guess)
<FromGitter> <deiv> I will ask you again tomorrow I guess :D
<FromGitter> <smalls12> out of curiosity, what are you doing with buildroot ?
<FromGitter> <smalls12> are you trying to cross compile crystal ?
<Stephie> this isnt actually buildroot
<Stephie> this is a folder called buildroot
<Stephie> which i use as a prefix for building stuff in
<FromGitter> <smalls12> ah ok
<FromGitter> <deiv> @smalls12 blame @RX14 for her dirs-shit ;)
<Stephie> completely unrelated to the buildroot project which i was probably unaware of at the time
<Stephie> hah
<Stephie> yeah please do :P
<FromGitter> <smalls12> : )
darkstardev13 has quit [Read error: Connection reset by peer]
darkstardev13 has joined #crystal-lang
<Stephie> @deiv well i'm up to crystal stage 17 so it seems to only appear on debian
<Stephie> i'll work out why tomorrow
<FromGitter> <deiv> @RX14 thanks (the only thing that comes to mind is that here we have multiarch "/usr/lib/x86_64-linux-gnu/" <- all arch specific libs go there)
<Stephie> llvm-config from LLVM 3.3 sucks
<Stephie> it just always prints the static library names
<Stephie> i dont want this, print the .so name please
<Stephie> i dunno why static linking isnt working either way but
<Stephie> probably because it's trying to use the system LLVM*.a libs, actually
<Stephie> cause they have preference over the -L/whatever that llvm-config adds
<Stephie> hmm
<Stephie> anyway, it's 1am
<FromGitter> <deiv> easy, 2am here ! xD