Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2014-02-21

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:35 spito left #divine
00:58 xstill joined #divine
01:02 xstill joined #divine
05:28 mornfall joined #divine
08:21 neie joined #divine
08:22 neie xstill: i finally got it to work, i think you were right, it was a version issue; btw is it possible to use llvm 3.4/clang 3.4 with divine? and is it possible to speed up the divine compile --llvm part? it takes really long
08:25 xstill neie: good to hear it works. If you are using development version of divine than llvm 3.4 should be supported (please report any deviation if there is such, it is not much tested)
08:26 xstill as for compile you can first precompile libraries with divine compile --llvm --libraries-only [ -j N ]  (the -j parameter work just like in make) and then compile model with divine compile --llvm --precompiled=.
08:26 neie xstill: there is this thing in CMakeLists.txt which stopped me from compiling using 3.3.1 (would stop 3.4 also i guess) ./CMakeLists.txt: if ( NOT ( ${LLVM_STRING_VERSION} VERSION_EQUAL "3.1" OR ${LLVM_STRING_VERSION} VERSION_EQUAL "3.2" OR ${LLVM_STRING_VERSION} VERSION_EQUAL "3.3" ) )./CMakeLists.txt: disabling( "LLVM" "" "Found version ${LLVM_STRING_VERSION} but 3.1, 3.2 or 3.3 is required." )
08:28 xstill hm, it is an error if cmake stops 3.3.1 (despite it is not officil version maybe)
08:28 xstill current develomplemt version should support 3.4, I'll check
08:31 xstill neie: the version marked as mainline in http://divine.fi.muni.cz/status.html supports llvm+clang 3.4
08:45 neie i had divine-3.0.92 that's why, which row do i need for that on ubuntu 13.10 32bits?
08:52 xstill seems like we don't have build for 13.10. I am not sure if 13.4 version can work
08:53 xstill where did you get 3.0.92
08:53 xstill ?
08:53 xstill (which version)
09:08 neie xstill: from this page: https://divine.fi.muni.cz/download.html
09:08 neie Latest development version: divine-3.0.92.tar.gz (3.1 beta 1)
09:08 neie i compiled it
09:09 xstill in that case you might just download tarball from status page and compale it in the same way
09:10 xstill neie: http://divine.fi.muni.cz/hydra/build/4785815/download/1/divine-3.0.92+pre4690.tar.gz
09:10 xstill that should be the latest
09:12 neie right ok
09:12 neie xstill: this tar.gz you gave me looks like it supports 3.4, but may have issues like: http://i.imgur.com/16ocXcy.png
09:13 xstill hm, seems that 3.4 support is not fully done
09:14 xstill what is the path given by llvm-config --ldflags on ubuntu please?
09:14 xstill or --libdir
09:17 neie xstill: -L/usr/local/lib  -lz -lpthread -ldl -lm, but this might be because i also compiled llvm from scratch and i'm not using a package; i'm not sure
09:18 xstill neie: you might want to configure with -DCMD_LLVMGOLD=/usr/local/lib/LLVMgold.so (please check the file exists)
09:19 xstill I should fix searching for LLVMgold in CMake
09:19 neie xstill: i removed all the LLVM stuff, i recompiled LLVMgold.so myself and it's on my ~/src directory; do you want me to install llvm-3.4 to see where it would create the LLVMgold.so?
09:21 xstill neie: you don't need to, just point -DCMD_LLVMGOLD and -DLLVM_CONFIG_EXECUTABLE to right path
09:21 neie when compiling divine? yes right, i usually configured using ccmake _build
09:22 xstill yes
10:23 neie if i have a trivial program with just assert(0) or assert(1), why do i get the same output for divine verify -p assert trivial.bc? (property doesn't hold)
10:24 neie nvm it works
10:30 mornfall to mi asi spadlo do spamu
10:30 mornfall jdu se kouknout
10:30 mornfall klíče asi myslí v reportu
10:32 mornfall jasně že to spadlo do spamu
10:32 mornfall aha on asi myslí prostě stavy, ve smyslu DESS
10:35 xstill hm, to dává smysl
10:35 xstill odepíšeš mu, nebo mám já?
10:37 xstill mornfall: můžeš udělat branch 3.1 buidy v hydře?
10:48 spito joined #divine
10:52 neie does divine assume that a malloc always succeed?
10:52 neie if not, how can i add this assumption?
10:53 mornfall it doesn't
10:53 mornfall you can call __divine_malloc instead, that's guaranteed to succeed
10:55 neie mornfall: ok thanks, are there other changes like that that i should be aware of before giving my programs to divine? (free, etc.)
11:01 xstill neie: nothing I know of, C library should be pretty complete (malloc is there too, just it simulates failure).
11:01 xstill also most of (non IO) C++ should work
11:42 neie is there a simplified form for the trace output? the -d option has too much details and is a bit hard to read
11:43 mornfall unfortunately no, and it's a struggle -- it's too detailed and not detailed enough at the same time
11:44 mornfall we will eventually need an interactive trace viewer
11:44 neie would be nice :)
11:48 neie mornfall: this is bit hardcore http://i.imgur.com/FKCL70U.png is there something which explains this syntax? @(p | c) represents a pointer (pointing at address p) and c is content of address p? what does it mean when p = 21:0 for instance?
11:49 mornfall neie: yes
11:49 mornfall neie: I don't think we have documentation for the trace format though... it's a little ad-hoc
11:49 mornfall neie: 21:0 means this is heap object 21 and the offset is 0
11:50 neie one "heap object" is 4 bytes?
11:50 mornfall heap object is any size, each allocation results in a separate heap object
11:52 mornfall ? are uninitialized values
11:52 neie cool ok thanks
11:53 mornfall neie: also, beware that the default property is "deadlock" which is most likely not what you want :-)
11:54 neie mornfall: i use divine verify -p assert program.bc to check for assertion failures is that correct?
11:54 mornfall yeah, that's correct
11:55 neie also, when a thread has #1, #2, ... does this mean that #i+1 was called from #i?
11:55 mornfall yes, it's a callstack
11:58 neie mornfall: (hopefully) last question, does divine draw help to visualize the trace? i've tried to save the output of divine verify --report -p assert, and then execute divine draw --trace=trace.txt -p assert program.bc but i get a seg fault
12:00 mornfall --trace takes the numbers directly, actually
12:00 neie oh --trace should be the list of numbers of CE-init and not a text file sorry
12:00 mornfall the fact it segv's is a bug though :-)
12:00 mornfall it just interprets it as numbers no matter what, I guess
12:01 mornfall but draw is only useful if you want to see what's going on around the trace, I guess
12:01 mornfall it's also not very useful with LLVM at the moment, because of the huge state descriptors
12:02 mornfall neie: for assertion failures, you may want to just look at the error state itself, and work out what went wrong from backtraces, like you would in a traditional debugger
12:02 mornfall neie: then trace back through the trace only if it's not clear how the program got into the final state
12:03 neie backtraces? you mean i go up?
12:03 mornfall backtrace = call stack
12:03 mornfall i.e. just look at what functions are active in which threads, and which lines of code
12:06 mornfall neie: basically, with -d, just look at the stuff after '===== The goal =====' and only look at the rest to get clues about how the program got to that point
12:13 neie mornfall: i see it makes sense
12:14 neie i tried looking at the end, and this is what i get: http://pastie.org/8755262 however the only assert in my code is line 108 and no thread is at this line, could it be that it failed at some other assert inside the C librairies?
12:14 mornfall neie: oh, right, because it didn't fail a literal assertion
12:15 mornfall it found a memory leak
12:15 mornfall there's a number of things treated as assertions right now
12:16 neie how does it define a memory leak? didn't see that in the manual, and can we disable that? (sorry it wasn't the last question :))
12:17 mornfall neie: hmm, right now the only way to disable that is comment out divine/llvm/machine.cpp:232 which should read             problem( Problem::MemoryLeak, p );
12:17 mornfall neie: memory leak happens when you lose the last reference to a heap-allocated object
12:18 neie mornfall: ok i see, could i for instance add a custom label in my program which is reachable only if an assertion fails, and check for reachability for this label (there this would remove all other default assertion checks right?)
12:18 mornfall but it's pretty hard to figure out from the traces ... the heap object identifiers aren't persistent
12:20 xstill mornfall: maybe we should split memory leaks to different property that assert
12:20 mornfall neie: not at the moment -- you could abuse deadlock detection for that though
12:20 neie hm right
12:20 neie i guess i prefer the machine.cpp hack
12:21 neie so i just comment out 232? are there other properties that i should remove?
12:21 mornfall neie: (the way it'd work with deadlocks is make the program while(1); at every exit but the bad one)
12:21 neie yes makes sense
12:21 mornfall neie: don't know, leaks are the most problematic I think
12:21 mornfall neie: everything else that we flag is more-or-less fatal for the program
12:22 mornfall neie: the other thing you may want to disable is jumps conditional on uninitialised values
12:22 mornfall neie: that'd be execution.h 657-659
12:23 neie thanks
12:23 neie btw i had a compilation problem, g++ gets stuck at [ 74%] Building CXX object divine/CMakeFiles/libdivine.dir/llvm/constants.cpp.o with cc1plus running at 50 or 100%, so i had to switch to clang for the compilation
12:23 mornfall although it's not nearly as much trouble as memory leaks, and the program flaws it reveals are probably more serious
12:24 mornfall neie: what version of g++, and how long did you try to wait?
12:24 mornfall I think it only takes 5 or so minutes nowadays...
12:24 neie i tried to wait one hour: g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
12:24 neie with clang it was just a few minutes
12:24 mornfall hrm
12:24 mornfall what version of divine do you have?
12:25 neie Latest development version: divine-3.0.92.tar.gz (3.1 beta 1) from https://divine.fi.muni.cz/download.html
12:26 mornfall neie: OK, the gcc fix didn't make it into beta
12:26 mornfall I should make another beta, we have a few fixes since the last one
12:27 neie ok ty
12:30 xstill mornfall: do 3.1 branche je pořeba integrovat ještě nějaké patche z mainline
12:30 mornfall xstill: neboj
12:31 xstill plus jsem ti poslal nějaké patche dneska
12:32 xstill (tím že jsem vyhodil druhej test z atomic.cpp se stavovej prostor zmenšil 10x, což je docela hodně, ale za to můžou ty vlákna co tam zůstávaj)
12:40 neie now that i've disabled memory leak checking, it's taking too long to finding the real assertion failure; can we bound the number of context switches to help it find the bug?
12:55 neie looks like it failed after running out of memory :(  terminate called after throwing an instance of 'std::bad_alloc'what(): std::bad_allocAborted (core dumped)
13:09 xstill neie: there is currently no way of bounding context-switches, however you can use --compression=tree switch to turn on lossless compression which is quite efficient for LLVM
13:24 mornfall spito: hele, co ten failující concurrentset test? :P
13:24 neie same error after 13m: searching...  terminate called after throwing an instance of 'std::bad_alloc'
13:26 mornfall neie: well, I guess your program is pretty big (in number of threads) -- also, how much memory do you have?
13:29 neie mornfall: 2GB, it's a little bit big but not too much (about 100 lines and ~5 threads i guess), i was able to pass this example with another tool, but it was a little bit of cheating because it used context-bounding :)
13:38 mornfall neie: number of lines doesn't matter much, it's the number of threads that is the limiting factor
13:39 neie sure yes
13:40 mornfall and well, context bounding also saves exponential amount of work, so with context-bounding you could probably verify very large programs
13:40 mornfall "verify"
13:41 mornfall I guess we could try throwing a hundred or two G of memory on the program if you are willing to share (at least) the bitcode
13:47 neie actually i was just looking for a tool which would find bugs (rather than prove correctness) in a pretty quick way; i don't mind giving you the example, it's not even really mine: http://pastie.org/8755546 http://pastie.org/8755547 (only one of these should fail)
13:47 neie this is one of the small program we have, and unfortunately we weren't yet able to find tools which find bugs quicky in these (except for this context bounding tool)
13:52 neie CBMC also fails: Solving with MiniSAT 2.2.0 with simplifier 3330891 variables, 14748675 clauses terminate called after throwing an instance of 'Minisat::OutOfMemoryException'
14:16 mornfall neie: well, divine might be able to do a directed and/or bounded search in the future, but it can't right now -- it's mostly for verification, bug-hunting is sort of a bonus :-)
14:19 xsabo4 joined #divine
14:40 spito joined #divine
14:41 xstill dneska je tu provoz
14:42 mornfall xsabo4: no nazdar
14:42 spito mornfall: on ti failuje i bittuple test :P
14:42 mornfall spito: to vim, ale ten failuje aspoň deterministicky
14:42 xstill spito: dík za články, koukám že je tam pěknej bordel
14:42 spito jo, to je
14:42 mornfall xsabo4: seminář v pondělí prý není, takže nebudu nejspíš ani já
14:43 spito mornfall: deterministicky? jako že jenom při nějaké konfiguraci?
14:43 neie yes i see
14:43 mornfall neie: maybe I could suggest that you get an account on divine.fi.muni.cz/trac and create tickets for things that would make it more useful for you :-)
14:48 xstill xsabo4: takto
14:51 neie ok thanks
14:52 xsabo4 xstill: takto?
14:52 xstill jo
14:52 xsabo4 ok thx
14:54 xsabo4 mornfall: uz som sa konecne trochu zorientoval
14:58 xsabo4 mornfall: takze ani v labe nebudes?
15:00 xstill mornfall: btw, nevíš jestli se dá nějak integrovat irssi s xmobarem?
15:18 xsabo4 joined #divine
15:31 xsabo4_ joined #divine
15:51 spito mornfall: ohledně toho testu - nevím, jak k tomu vůbec může dojít
15:51 spito když to nechám prověřit divinem, tak to je v přádku
15:55 xsabo4_ nazdar, pri makeovani divinu mi make skoncil s errorom kvoli llvm, vypisalo mi asi milion riadkov typu /usr/bin/ld: cannot find -lLLVMCore (-lLLVMSupport,atd), neviete nahodou co s tym?
16:00 mornfall xstill: určitě dá :-) ale nemam nic hotovýho
16:00 mornfall xsabo4_: radšej tu
16:01 mornfall xsabo4_: akú máš verziu llvm?
16:02 xsabo4_ mornfall: som tu spravne? :D mam verziu Package llvm-3.3-4.fc20.x86_64 already installed and latest version
16:08 xstill xsabo4_: co říká llvm-config --libdir? a llvm-config --ldflags?
16:09 xsabo4_ xstill: libdir /usr/lib64/llvm a ldflags hovori -L/usr/lib64/llvm  -lz -lpthread -lffi -ldl -lm
16:11 xsabo4_ xstill: mrzi ma ze vas tym otrvujem, ale neviem to vygooglit :(
16:16 xsabo4_ xstill: takze to mam presunut tie veci do /usr/bin/ld?
17:28 mornfall xstill: fakt chceme -pedantic? :P
17:29 xstill tak, bylo ty to hezčí. Ale to je na tobě. Momentálně to dává dost warningů v bitstreamu.
17:30 xstill ten warning hardening patch je na ostatních snad nezávislej
17:30 mornfall je, zatím jsem ho nepushnul
17:31 mornfall uvidíme co na nás vybleje hydra když se zapnou warningy v debug-u
17:38 xstill mimochodem, s tím dobíháním threadů asi nejde moc jednoduše udělat, co?
17:49 xsabo4 joined #divine
17:54 mornfall xstill: je to docela problém no :)
17:54 xstill xsabo4: zkontroluj si, že máš v /usr/lib64/llvm soubroy LLVMCore.so a tak podobně
17:54 mornfall libLLVMcore.so
17:54 xstill mornfall: no to teda, potřebovali bysme ten thread atomicky ukončit jakmile pthread_join zasignalizuje že to jde
17:55 xstill hm, free vytvoří stav?
17:56 xstill (ach já blbec mám == místo != a trvalo mi dva dny na to přijít)
17:57 mornfall free asi stav nevytvoří
17:58 xsabo4 xstill: diky, nie je to tam - mam tam iba BugpointPasses.so  libLTO.so    LLVMgold.so libLLVM-3.3.so  a   libprofile_rt.so ... a ako ziskam ten so file?
17:59 mornfall xsabo4: llvm-devel alebo taký nejaký balík
17:59 mornfall hmm
17:59 xstill xsabo4: hm, to je divný, co ti řekne llvm-config --libs? (monfrall má dobrý point)
17:59 mornfall to asi nepomůže
17:59 xstill ale je divný že tam je LLVMgold
18:00 mornfall a libLLVM-3.3.so? wtf is that :-)
18:00 xsabo4 Package llvm-devel-3.3-4.fc20.x86_64 already installed and latest version :/
18:00 xstill hm, to maj ti blbci ve fedoře všechno v jednom .so?!
18:01 xsabo4 llvm-config --libs mi asi vypise vsetky prepinace pri ktorych mi hodilo chybu, proste dlhy zoznam prepinacov (ktorych nazvy som uz videl)
18:01 xstill je tam něco kromě -l option?
18:03 xsabo4 ako to zistim? manual?
18:03 xstill v tom llvm-config --libs jsem myslel
18:04 xsabo4 jaj...vsetko zacina na l
18:04 xstill super
18:06 xstill xsabo4: zkus jestli existuje balík llvm-static a nainstaluj ho případně
18:07 mornfall tak, mam tady netinst fedory 20
18:07 xsabo4 xstill: instalujem
18:07 mornfall zítra vám řeknu jak to je s tím llvm tam :P
18:08 xstill btw. podle release.nix bych řekl, že ani v té fedoře 18 kterou tam máme nemáme llvm
18:08 xsabo4 inak co mate za distro? naschval som si daval fedoru kvoli tomu ze ju ma uz vlado, ale ak by ste prisli s niecim lepsim tak to kludne preinstalujem ;)
18:09 xstill (a jelikož je rok stará a EOL tak nevím jestli ten buidl má smysl)
18:09 xstill xsabo4: já mám nixos a mornfall taky, ale to asi není čím bys chtěl začít
18:10 xstill a všechny počítače v labu mají nixos
18:10 mornfall kto je vlado? :-)
18:12 mornfall naše fc18 buildy llvm nemaj
18:12 xsabo4 xstill :D
18:12 xstill ale já jsem nikdy neřekl, že mám fedoru
18:12 xstill měl jsem fedoru naposledy někdy před 4 lety, možná víc
18:13 xstill tyhle distribuce (fedora/ubuntu a spol) mi jdou na nervy
18:14 mornfall já počítám že za pár hodin budu nějakou fedoru mít
18:14 mornfall i když teda už jsem to zkoušel asi 3x a zatím to vždycky nějak zdechlo
18:15 mornfall dokonce 64b
18:16 xstill mornfall: co víš o RHEL 7, teď čtu že má mít kernel 3.10 dokonce. Dočkáme se RHELu s rozumně novým kompilátorem?
18:16 mornfall no, rhel7 je plusminus fedora 20, pokud jde o verze sw
18:17 mornfall ale bude mít stejnej překladač až do EOLu, což je tak 10 let :-)
18:17 xstill no jasný, ale pokud by začal s gcc 4.8 mohlo by to alespoň k něcěmu být (teď)
18:18 xstill rhel kterej umí kompilovat c++11
18:19 xstill a to že tam ten kompilátor skejsne celou dobu je mi jasný, je to rhel
18:19 xsabo4 inak dnes som skusal ten nixos, prislo mi to celkom v pohode...inak vytvoril som novy _build a teraz robim make
18:20 xstill jak jsi ho zkoušel? jako na labovém pc?
18:21 xsabo4 hej
18:21 xsabo4 akurat ma nechcelo prihlasit, musel som ist na iny pocitac (a tam ma prihlasilo uplne v pohode)
18:21 xstill nixos je ze začátku dost vtipnej když se ho člověk pokusí nainstalovat na svůj počítač. Ale zase od doby kdy jsem to dělal poprvé tu jsou (skoro) 2 release
18:21 xstill tak na běžnou práci moc nepoznáš, že je to jiný
18:22 xstill pozitivum je že můžeš instalovat i bez root práv
18:22 xstill což se v labu hodí
18:22 xstill hm, rhel 5 a 6 maj prej 13 let podpory
18:23 xstill (5ka s náma bude do roku 2020!)
18:50 xstill mornfall: /home/xstill/DiVinE/mainline/divine/llvm/execution.h: 851: assertion `not imlemented' failed;
18:50 xstill je to llvm.trap v místě kde chybí return ve funkci
18:51 xstill mohli bysme trap reportovat
19:23 xsabo4 btw diky, uz mi to ide, som vam vdacny ;)
19:24 xsabo4 mornfall: ako teda v ten pondelok? lebo rad by som sa stretol ak teda budes v Brne
19:25 mornfall xsabo4: utorok by bol možno lepší
19:26 mornfall xstill: hmm, to je další variace na téma unreachable?
19:26 xstill je to intrinsic, mělo by to vygenrovat TRAP interrupt nebo co
19:27 xstill http://llvm.org/docs/LangRef.html#llvm-trap-intrinsic
19:28 xsabo4 mornfall: ok, ako len povies, hlavne aby sme sa stretli, lebo ja vobec neviem co a ako...okrem toho ak by si mi poradil nieco co si este pozriet...divine skusam, tu HACKER cast na divine.fi. som si prebehol, darcs mam nainstalovane...akurat neviem co to qt - mam qt (creator) neviem ci to zahrnuje aj qt, vlastne stale uplne nechapem co to uplne je
19:30 xsabo4 skusal som vyskusat divine v praxi ale zial nepodarilo sa mi to nemate na toto nejaku medicinu? ;) divine compile --llvm main.c  + clang -c -D__divine__ -emit-llvm -nobuiltininc -nostdinc -Xclang -nostdsysteminc -nostdinc++ -g  -D_PDCLIB_BUILD -I.. -I. functions/ctype//isascii.c -o functions/ctype//isascii.c.bc sh: clang: command not found Error running an external command. Exiting after receiving fatal error.
19:31 mornfall clang: command not found
19:31 mornfall to je pomerne jasná chyba nie? :)
19:31 xsabo4 sry uz som daky unaveny
19:31 xsabo4 btw co to vlastne je?
19:32 mornfall čo je čo? :)
19:33 mornfall http://lmgtfy.com/?q=clang :-P
19:34 xsabo4 no pravda :D mal by som si dat zakaz pytania sa po dlhom dni
19:35 xstill mornfall: :-D tu stránku neznám
19:39 xstill ale zato jsem snad vyřešil ty thready
19:40 mornfall v usr-pthread?
19:41 xstill jo
19:45 mornfall nerozbil se žádnej wait?
19:48 xstill jako mělo by to být v pořádku, ale budu chtít aby ses na to pořádně podíval, než to pushneš
19:49 xstill změna je v tom, že paměť uvolňuje join
19:53 mornfall ukaž patch :) podívám se
19:53 xstill hm, mám tam leak
19:53 mornfall jediný co musíš ošetřit je když se detach zavolá hned
19:53 mornfall (nebo se rovnou vytvoří detached vlákno)
19:54 xstill jo no to dělám
19:56 mornfall a já mam fc20 s xfce
19:56 mornfall ve VMku
19:57 xstill (otázka je co je horší :-P)
20:29 xsabo4 servus, dostavam ld.gold error :( znamena to ze mam zmenit nejaku cestu?
21:14 spito mornfall: zamýšlel ses nad tou chybou v concurrent setu?
21:14 mornfall spito: ani ne, spoléhám na tebe? :-)
21:14 spito já na to totiž tak průběžně koukám, ale nechápu, jakou posloupností příkazů se do toho stavu dojde
21:14 spito stala se ještě někdy nedávno ta chyba znova?
21:16 spito hmm, stala...
21:16 mornfall naposled tu http://divine.fi.muni.cz/hydra/build/4774221/log/raw
21:17 mornfall včera
21:18 spito a našel bych někde coredump?
21:18 mornfall spíš je otázka jestli to umírá aj s FastAtomicCell někdy
21:18 mornfall nebo jen AtomicCell
21:18 mornfall třeba je blbě AtomicCell :-)
21:20 spito a ten coredump?
21:21 mornfall těžko
21:21 mornfall asi jedině postavit si to na pheme v release mode a pustit to v cyklu než to zdechne
21:22 xsabo4 joined #divine
21:23 mornfall xsabo4: a ld.gold máš?
21:23 xsabo4 jj, v/usr/bin
21:23 mornfall a co to je za error?
21:24 xsabo4 ld.gold: error: _divine-compile.WLpnCk/main.bc: not an object or archive
21:24 xsabo4 ld.gold: error: divine: no archive symbol table (run ranlib)
21:24 xsabo4 ld.gold: error: cxx: no archive symbol table (run ranlib)
21:24 xsabo4 atd..
21:25 xsabo4 mornfall: hned pridem
21:25 mornfall xsabo4: LLVMgold.so
21:25 spito mornfall: a to na pheme bych mohl udělat jak?
21:25 spito :)
21:27 mornfall spito: jak jako jak?
21:27 mornfall ssh pheme10?
21:27 mornfall třeba?
21:32 spito čím to překládáme?
21:32 spito v hydře?
21:33 spito vidím, gcc
21:37 xsabo4 mornfall: LLVMgold.so nemam - takze nainstalovat?
21:39 mornfall sehnat a nainstalovat, да
21:58 xsabo4 mornfall: tak nakoniec som zistil ze to mam nainstalovane
21:59 xsabo4 akurat na to nefunguje whereis
22:01 xstill xsabo4: pokud jsi dneska od 18:30 nedělal darcs pull tak to zkus a pak překonfiguruj celé (nejlépe smazat build a překonfigurovat) při troše štěstí by se ti měl LLVMgold.so už najít; Alternativně nastav CMD_LLVMGOLD v CMake na správnou cestu
22:04 xstill (dneska končím)
22:05 xsabo4 xstill: ok skusim, a ako sa to nastavuje?
22:05 xsabo4 xstill: si tu este?
22:06 xstill xsabo4: pokud máš build přes configure tak z divine adresáře cmake _build -DCMD_LLVMGOLD=...
22:06 xsabo4 thx..dobru :) diky za pomoc

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary