< cfields>
yea, forgot my scrollpad doesn't play nice with a default shell config
< Luke-Jr>
is there a way to configure the shell to work nicer? :o
< cfields>
hmm, don't remember what i did to make it play nice
< Luke-Jr>
cfields: back for a bit - anything interesting?
< cfields>
Luke-Jr: no, got distracted by something else. probably won't poke at it any more tonight
< Luke-Jr>
cfields: did you look further into that -static-stdc++ difference?
< Luke-Jr>
or should I check that/
< cfields>
Luke-Jr: yea, linked without that. still crashed
< Luke-Jr>
hmm
< cfields>
oh wait, sec
< cfields>
nm, that fixed :)
< cfields>
i forgot to re-link the test binary
< Luke-Jr>
>_<
< Luke-Jr>
so I guess the solution is something like: 1) use static univalue in Travis/depends/releases (until the entire build uses shared libs); and 2) don't use -static-libstdc++ when building for the system
< jgarzik>
Luke-Jr, ACK 1.0.2 tag
< cfields>
Luke-Jr: all depends are static
< cfields>
it was a bug to have it shared anyway, i just didn't say anything because the crash looked like something worth fixing
< Luke-Jr>
cfields: so that solution sounds good?
< Luke-Jr>
jgarzik: 1.0.2 tag when? ;)
< cfields>
Luke-Jr: i don't see the point of having it in depends, personally
< Luke-Jr>
cfields: 1) easy install for users; 2) needed for Travis/gitian
< cfields>
Luke-Jr: eh? both of those are easier as it is now
< Luke-Jr>
cfields: as it is now is just plain broken
< cfields>
Luke-Jr: to clarify, in-tree seems fine to me
< Luke-Jr>
cfields: to clarify, in-tree is a bug
< cfields>
Luke-Jr: i don't really care strongly, but until distros are shipping it and it's easy to apt-get/emerge/yum, moving it out would be premature
< Luke-Jr>
no, it's just good software development practice
< cfields>
Luke-Jr: good practice is modularizing your code base and creating new upstreams. check. bad practice is making life hard for compilers by making them jump through hoops until those upstreams are rooted.
< Luke-Jr>
1 extra step does not make life hard
< cfields>
Luke-Jr: i can clone a huge number of codebases and ./configure && make. anything more than that and my interest plummets quickly.
< cfields>
i'm sure i'm not alone
< Luke-Jr>
…
< cfields>
anything more being: digging through docs, c/p cmdlines, foreign scripts, etc
< Luke-Jr>
we already require more
< cfields>
?
< Luke-Jr>
apt-get install or equivalent
< Luke-Jr>
which you need to read docs to figure out
< Luke-Jr>
cfields: how do you get the build to use depends/ without changing the prefix btw?
< cfields>
yes, but more likely you'll just ./configure and i'll yell "you need openssl"
< cfields>
Luke-Jr: i think that's the only trick that works.
< droark>
Is there a reason why the OSX deterministic build notes recommend Xcode 6.1.1 and not 6.2 when grabbing the SDK? Looks like 6.2 is the last version to support Mavericks.
< cfields>
should do it, i think
< cfields>
droark: the sdk corresponds to the clang version we use
< Luke-Jr>
cfields: I wonder if it makes sense to add a --with-depends option to set up the paths
< droark>
Okay. Looks like there's a minor revision in there. I thought it wouldn't be a problem but I guess it is, or at least, it's not but 6.1.1 gets everybody on the same page. Correct?
< cfields>
Luke-Jr: i believe that one's always voodoo
< Luke-Jr>
:|
< Luke-Jr>
cfields: `make -C depends HOST=i686-pc-linux-gnu libevent` does not populate depends/i686-pc-linux-gnu/ - any idea why?
< cfields>
Luke-Jr: what's with the libevent target?
< Luke-Jr>
cfields: I only want libevent built/installed
< cfields>
Luke-Jr: heh, depends weren't made to work that way :)
< Luke-Jr>
:/
< Luke-Jr>
trivial to make it work that way?
< cfields>
Luke-Jr: the result is meant to be deterministic, so each package is built in its own staging area, then all packages are installed into the prefix at the end
< cfields>
not really :\
< cfields>
only option would be something like the NO_QT or NO_WALLET options
< cfields>
but i don't like that, it's kinda abusing the system
< Luke-Jr>
ok, so depends basically only makes sense for travis/gitian :/
< cfields>
yes, it was designed to be a means of reproducing release build conditions reliably
< jgarzik>
Luke-Jr, v1.0.2 passed local univalue travis
< Luke-Jr>
thanks
< dcousens>
when does cs_main need to be locked?
< dcousens>
(is there a reference for that?)
< dcousens>
(I have a rough idea)
< dcousens>
also, whats the difference between EXCLUSIVE_LOCKS_REQUIRED and just using AssertLockHeld?
< dcousens>
Luke-Jr: interesting, but how can I review that merge in any reasonable way? How do I know you haven't just injected some malicious code in there?
< dcousens>
I guess I could manually verify it by checking the diffs locally with my own merge?
< Luke-Jr>
or just view the diff on github?
< Luke-Jr>
but yeah, locally checking is the best way