1 2014-11-19 00:00:26 <phantomcircuit> i feel like they weren't always byte swapped
2 2014-11-19 00:00:28 <phantomcircuit> am i crazy
3 2014-11-19 00:00:45 <sipa> it depends on the double sha256 of the phase of the moon
4 2014-11-19 00:00:55 <tdlfbx> I've been using btrfs for years. Pretty happy with it. Haven't lost any data yet.
5 2014-11-19 00:01:29 <phantomcircuit> tdlfbx, do a bunch of snapshots
6 2014-11-19 00:01:31 <phantomcircuit> fill the disk
7 2014-11-19 00:01:34 <phantomcircuit> pull power cord
8 2014-11-19 00:01:37 <phantomcircuit> gl
9 2014-11-19 00:02:31 <tdlfbx> Yep it does poorly with low space. But on the other hand you can mount the snapshots read only and not lose your data.
10 2014-11-19 00:19:20 <blockstreamskept> Blockstream is about to destroy the economics of BTC https://www.reddit.com/r/Bitcoin/comments/2moq3o/theres_been_a_lot_of_talk_lately_of_blockstream/
11 2014-11-19 00:26:17 <firelegend> which file contained the bitcoin address version?
12 2014-11-19 00:30:42 <netg> address versio?
13 2014-11-19 00:31:09 <netg> https://en.bitcoin.it/wiki/List_of_address_prefixes ?
14 2014-11-19 00:31:15 <firelegend> yep in the source code
15 2014-11-19 00:31:26 <netg> cant help rro
16 2014-11-19 00:31:27 <netg> y
17 2014-11-19 00:35:44 <kefkius> firelegend: src/chainparams.cpp
18 2014-11-19 00:38:16 <firelegend> kefkius:thanks
19 2014-11-19 00:42:20 <kefkius> np
20 2014-11-19 00:50:15 <tdlfbx> When multiple branches are present, as shown by getchaintips, how does the network decide on only one of them, and how long does it take?
21 2014-11-19 01:23:14 <cfields> BlueMatt: terminate called after throwing an instance of 'std::bad_alloc'
22 2014-11-19 01:23:19 <cfields> BlueMatt: you saw that, i assume?
23 2014-11-19 02:04:58 <BlueMatt> WTF: g++: internal compiler error: Segmentation fault (program cc1plus)
24 2014-11-19 02:08:10 <BlueMatt> oh, lol, had set low stack size for testing...
25 2014-11-19 02:08:27 <gwillen> hah
26 2014-11-19 02:46:18 <gmaxwell> BlueMatt: I know our testing infrastructure isn't good enough because we've never found any GCC bugs. In the development of libopus I found three.
27 2014-11-19 02:46:58 <gmaxwell> (er, maybe it was just two gcc plus one ICC, whatever. several.)
28 2014-11-19 02:48:14 <copumpkin> how's it fare on clang?
29 2014-11-19 02:49:52 <gmaxwell> copumpkin: used to be much worse... both seem to have improved a lot since john regehr's work with compiling random programs.
30 2014-11-19 02:50:25 <gmaxwell> (I've found a lot of clang bugs, though mostly they were already reported... so I don't really count those)
31 2014-11-19 02:51:08 <gmaxwell> e.g. I just hit one the other day, using __int128 makes clang undefined behavior checker crash.
32 2014-11-19 02:51:38 <copumpkin> fun :)
33 2014-11-19 02:52:24 <Luke-Jr> gmaxwell: do GDB bugs count?
34 2014-11-19 02:52:36 <Luke-Jr> I hit one the other day with BFGMiner..
35 2014-11-19 02:52:54 <Luke-Jr> (actually, I suppose it could have been triggered by a GCC bug producing invalid debug info..)
36 2014-11-19 02:53:04 <gmaxwell> yea, well in general.. you know you're doing something right with testing if you're finding bugs in your toolchain.
37 2014-11-19 02:54:17 <Luke-Jr> or at least doing something not commonly done XD
38 2014-11-19 02:59:19 <cfields> gmaxwell: we just had to crank down travis this week to avoid ICE's...
39 2014-11-19 02:59:27 <cfields> not exactly what you were getting at, but at least we're close :)
40 2014-11-19 03:00:03 <cfields> (i'm 99% sure they're oom-related, so they don't really count at all)
41 2014-11-19 03:35:35 <cfields> sipa: sorry for the noise if you're seeing those
42 2014-11-19 03:35:45 <xuxu> what is the purpose of a paymentrequest object?
43 2014-11-19 03:36:13 <cfields> BlueMatt: see https://github.com/bitcoin/bitcoin/pull/5247 for a method of doing git-only signed acks (the 2nd one)
44 2014-11-19 03:36:59 <cfields> it exploits the fact that github shows cross-repo references
45 2014-11-19 03:38:24 <cfields> could easily be turned into a quick script if you like the approach
46 2014-11-19 04:11:43 <xuxu> what is a vin?
47 2014-11-19 04:13:44 <xuxu> does vout represent an utxo?
48 2014-11-19 04:16:00 <kefkius> vin = input, vout= output
49 2014-11-19 04:16:18 <xuxu> kefkius: what does the v represent?
50 2014-11-19 04:16:34 <kefkius> IDK, satoshi practiced Hungarian notation
51 2014-11-19 04:17:45 <Luke-Jr> xuxu: vector. vin = *vector of* input*s*
52 2014-11-19 04:19:57 <xuxu> thank you Luke-Jr
53 2014-11-19 06:31:49 <BlueMatt> gmaxwell: I know our testing infrasturcture sucks because half of it was written by me :p
54 2014-11-19 06:32:45 <BlueMatt> cfields: can you get it to embed a full signature in the hidden "spoiler" button?
55 2014-11-19 06:33:03 <BlueMatt> cfields: or only first-line of something?
56 2014-11-19 06:33:40 <cfields> BlueMatt: not sure. i have something hacked together here. Don't want to flood real PRs with it. I'll try tomorrow and see what I can get away with
57 2014-11-19 06:34:18 <cfields> BlueMatt: fix your mem issue and I'll ack it :p
58 2014-11-19 06:34:40 <BlueMatt> I mean scripting echo ACK | gpg --sign | scp to server (+comment on github) isnt hard either, but if we can do it with "spoiler" buttons, then I'm happy :)
59 2014-11-19 06:34:43 <BlueMatt> heh, ok
60 2014-11-19 06:48:16 <earlz> So, when using getblock, does that give any indication that a block is orphaned?
61 2014-11-19 06:48:39 <earlz> I don't really have an orphan block hash to test it with heh
62 2014-11-19 07:02:29 <justanotheruser> earlz: I guess you could do getblock and check if its parent is in your chain
63 2014-11-19 07:05:17 <earlz> apparently `confirmations` for an orphan block would be -1
64 2014-11-19 07:05:32 <earlz> although, it'd be nice to know how "confirmed" it is in the orphan chain
65 2014-11-19 07:46:26 <Krellan> sipa: Thanks, I saw your comment, I added a comment to the code explaining it more there
66 2014-11-19 07:46:38 <Krellan> https://github.com/bitcoin/bitcoin/pull/5288
67 2014-11-19 10:42:40 <xperia> Hi all. I am having problems with compiling bitcoin in windows. when i try to configure bitcoin i am getting this error message here
68 2014-11-19 10:42:42 <xperia> checking for boostlib >= 1.20.0... yes
69 2014-11-19 10:42:43 <xperia> checking whether the Boost::System library is available... yes
70 2014-11-19 10:42:45 <xperia> configure: error: Could not find a version of the boost_system library!
71 2014-11-19 10:42:46 <xperia> I have several files inside ../boost_1_55_0/stage/lib/ like libboost_chrono-mgw48-mt-s-1_55.a libboost_filesystem-mgw48-mt-s-1_55.a libboost_program_options-mgw48-mt-s-1_55.a libboost_system-mgw48-mt-s-1_55.a libboost_thread-mgw48-mt-s-1_55.a
72 2014-11-19 10:42:48 <xperia> why does bitcoin configure still say it can not find a boost_system Lib ?
73 2014-11-19 10:43:30 <sipa> you likely need to tell configure where to look for those files, but i have no experience with windows
74 2014-11-19 10:56:09 <xperia> sipa. yeah it looks like there is a problem between installed libs and staged libs in a special dir. hmmmm
75 2014-11-19 13:47:44 <jonasschnelli> ./test_bitcoin: is it possible to only run a single unit test suite?
76 2014-11-19 13:47:55 <wumpus> jonasschnelli: yes
77 2014-11-19 13:50:26 <jonasschnelli> wumpus: how can i do this? ./test_bitcoin --help does not tell me how i can do this... thanks
78 2014-11-19 13:50:57 <wumpus> ok, well I could be mistaken then
79 2014-11-19 13:51:47 <wumpus> best place to look would be the boost unit_test documentatino
80 2014-11-19 13:52:11 <jonasschnelli> yes. let me have a look there.
81 2014-11-19 14:40:19 <jonasschnelli> is there any automated functional GUI testing? i just saw that there is a src/qt/test but looks only after unit tests.
82 2014-11-19 14:40:48 <sipa> not that i know
83 2014-11-19 14:44:00 <wumpus> there are only a few unit tests
84 2014-11-19 14:50:57 <gavinandresen> git HEAD isnât building for me on OSX because Iâm missing a working bignum library. Anybody know what I need to brew install ???
85 2014-11-19 14:52:19 <sipa> gmp
86 2014-11-19 14:53:04 <gavinandresen> sipa: thanks
87 2014-11-19 14:53:39 <sipa> i should try to get rid of that; i don't think the signing code in libsecp256k1 actually still needs gmp
88 2014-11-19 14:57:45 <gavinandresen> sipa: I just pushed a change to doc/build-osx.md mentioning the dependency, if you do get rid of it remove it there, too.
89 2014-11-19 14:58:17 <sipa> gavinandresen: good to know
90 2014-11-19 15:05:38 <wumpus> ok, if we've gained a new dependency we should also update build-unix. but if it's temporary I'll wait with that
91 2014-11-19 15:06:56 <sipa> if we really want to avoid the dependency i guess i can add a --disable-verification to libsecp256k1 that would remove the code that depends on it
92 2014-11-19 15:07:32 <wumpus> nah
93 2014-11-19 15:07:33 <gavinandresen> when we switch to libsec256 weâll gain that dependency anyway, right?
94 2014-11-19 15:08:18 <sipa> for verification, yes - unless someone implements a modular inverse that's competitive with the one in gmp
95 2014-11-19 15:08:33 <wumpus> indeed, thus we should just document the dependency, working around that temporarily is just a waste of work
96 2014-11-19 15:08:37 <sipa> ok
97 2014-11-19 15:10:06 <wumpus> do we have a requirement on gmp version?
98 2014-11-19 15:10:12 <sipa> let's see
99 2014-11-19 15:11:15 <sipa> it needs mpn_tdiv_qr
100 2014-11-19 15:12:48 <sipa> GMP 3.1
101 2014-11-19 15:12:55 <wumpus> ok, thanks
102 2014-11-19 19:32:47 <BlueMatt> cfields: can we get more memory from travis?
103 2014-11-19 19:32:54 <BlueMatt> is that a pay-to-play option?
104 2014-11-19 19:33:33 <cfields> BlueMatt: not that i know of, afaik all builders are the same to reduce complexity
105 2014-11-19 19:33:40 <cfields> is it really an issue?
106 2014-11-19 19:37:36 <BlueMatt> 3g is kinda tight, lemme bang on it locally and see if I can get it low enough
107 2014-11-19 19:49:45 <parazyd> hello. i'm on archlinux, using latest bitcoin-qt. i'm unable to get any incoming connections (port 8333 is open) and i have 8 outgoing connections
108 2014-11-19 19:50:01 <parazyd> could anyone help me find the problem?
109 2014-11-19 19:50:10 <BlueMatt> #bitcoin
110 2014-11-19 20:20:22 <xperia> Hi all. I am having problems with compiling bitcoin in windows. when i try to compile it with make i am getting this error message here
111 2014-11-19 20:20:24 <xperia> allocators.h:13:34: fatal error: boost/thread/mutex.hpp: No such file or directory #include <boost/thread/mutex.hpp>
112 2014-11-19 20:20:25 <xperia> Can somebody tell me how to fix this compile error under windows? the mutex.hpp file exist on my side but it looks like it can not be find by the compile proccess. i tryed to use the config option "--includedir="C:\MinGW\msys\1.0\home\username\boost_1_55_0" but it did not work.
113 2014-11-19 20:21:08 <sipa> cfields: ping ^
114 2014-11-19 20:21:34 <jtimon> sipa and looking at https://github.com/sipa/bitcoin/commits/keynoalloc and I like it as a first step, but key.cpp still depends on allocators and thus boost/thread, no?
115 2014-11-19 20:21:53 <jtimon> s/sipa and/sipa I'm
116 2014-11-19 20:22:20 <cfields> xperia: try: ./configure --with-boost=C:\MinGW\msys\1.0\home\username\boost_1_55_0
117 2014-11-19 20:22:48 <xperia> cfield: okay thanks will try it out
118 2014-11-19 20:22:52 <cfields> jtimon: ah, i'll look at that now too
119 2014-11-19 20:23:05 <cfields> saw it this morning and promptly forgot all about it :\
120 2014-11-19 20:24:00 <sipa> jtimon: yes, but that's not fixable
121 2014-11-19 20:24:08 <sipa> jtimon: well, it is, but must be solved independently
122 2014-11-19 20:24:25 <sipa> for example we could say that secure_allocator is enough for those internal computations
123 2014-11-19 20:24:25 <xperia> cfields: just to recheck. if i am not wrong the config option "--with-boost" take only "yes" or "no" as paramether and not a path.
124 2014-11-19 20:24:50 <jtimon> ok, I see, I think it will help for what I was trying yesterday though
125 2014-11-19 20:25:17 <sipa> of course, we could just say that secure_allocator is enough for everything and drop that mlocking mess :)
126 2014-11-19 20:27:07 <jtimon> cfields yesterday I was trying to turn CKey into an interface that CAllocatedKey (name open to bikeshedding) implements, but then I had to use pointers to CKey since you can't instance abstract classes, so I had to change CKeystore interface...
127 2014-11-19 20:28:17 <jtimon> I will rebase sipa's commit on top of #5251 and try again
128 2014-11-19 20:28:42 <cfields> mm, not what i was expecting to see either
129 2014-11-19 20:28:51 <cfields> seems we all have different ideas here :)
130 2014-11-19 20:28:51 <jtimon> (or the oher way around, I don't know)
131 2014-11-19 20:29:04 <sipa> well i'm not sure what you want to do
132 2014-11-19 20:29:54 <jtimon> yes, I think the concrete implementation of keystore should handle the locks, not CKey, and was wondering if using an interface for key would help
133 2014-11-19 20:30:40 <cfields> jtimon: sounds like we're on the same page there, i was hoping to move the locking out of the CKey level
134 2014-11-19 20:30:57 <jtimon> I'm not sure what cfields wants to do either, but the pointers comment didn't sound very well to me
135 2014-11-19 20:31:21 <jtimon> ok, yes, we agree on that part then
136 2014-11-19 20:31:44 <xperia> cfields: your suggestion does not work. --with-boost takes only a yes or no as parameter and not a path value.
137 2014-11-19 20:32:04 <sipa> cfields: that's what i'm doing :)
138 2014-11-19 20:32:32 <sipa> a use_after_free wrapper would be even easier
139 2014-11-19 20:32:37 <cfields> jtimon: to vastly oversimplify, i was imagining using CKey something like: CKey foo(&myLockedMem)
140 2014-11-19 20:33:44 <cfields> ofc it's not that simple since CKey obviously has to do conversions and make copies
141 2014-11-19 20:33:55 <sipa> not really
142 2014-11-19 20:34:09 <sipa> well, not in the way that libsecp does
143 2014-11-19 20:34:27 <cfields> xperia: it takes a path
144 2014-11-19 20:35:36 <Krellan> sipa: Hi again
145 2014-11-19 20:35:53 <Krellan> Comment added https://github.com/bitcoin/bitcoin/pull/5288
146 2014-11-19 20:36:36 <xperia> cfields: ahh yes you are right hmmm did not see this. will retry
147 2014-11-19 20:40:37 <cfields> sipa: regardless of other goals, that abstraction looks much cleaner anyway
148 2014-11-19 20:45:22 <jtimon> mhmm I don't like the &myLockedMem stuff much, looks like a hack, elthough may be the best first solution to clean up later
149 2014-11-19 20:46:37 <cfields> actually, looking at sipa's work, it seems to be exactly what i had in mind, just in a completely different (smarter ;) form
150 2014-11-19 20:46:56 <cfields> it's now up to the wallet to lock, rather than ckey..
151 2014-11-19 20:47:03 <sipa> right, exactly
152 2014-11-19 20:47:16 <cfields> jtimon: i think you and i might have focused too quickly on the fact that there are still a few necessary internal locks for the intermediary work
153 2014-11-19 20:47:17 <sipa> and the key class can just do key stuff, without worrying about how it is allocated
154 2014-11-19 20:47:23 <jtimon> anyway here's a version of the stuff rebased on top of the current master (had some minor conflicts after removing the #ifdefs for secp256) https://github.com/jtimon/bitcoin/commits/keynoalloc
155 2014-11-19 20:47:49 <sipa> gah, still haven't reviewed the block proposal
156 2014-11-19 20:49:05 <jtimon> certainly this looks like a very good first step. it should be much simpler to completely remove the allocators dependency from key.o now
157 2014-11-19 20:51:40 <jtimon> sorry I made a mistake in the rebase
158 2014-11-19 20:55:49 <sipa> jtimon: rebased it myself
159 2014-11-19 20:56:10 <sipa> didn't realize it was outdated already
160 2014-11-19 20:56:42 <jtimon> oh, well, it should be fixed on my branch as well
161 2014-11-19 20:58:08 <sipa> hmm, the libsecp256k1 unit tests take way longer than the bitcoin ones...
162 2014-11-19 21:13:59 <cfields> sipa: looks like the locking in Sign/SignCompact could be avoided relatively cleanly by passing the nonce in, no? and having the caller retry as necessary
163 2014-11-19 21:14:23 <gmaxwell> sipa: yea, so the most recent tests you added were pretty slow, I was going to suggest going from 2000 iterations per iteration to 1000.
164 2014-11-19 21:14:52 <sipa> cfields: #5227 rewrites that anyway
165 2014-11-19 21:15:02 <gmaxwell> cfields: ugh, nonce handing really should be all inside the signing. (esp due to derandomized dsa implementation)
166 2014-11-19 21:15:56 <sipa> and i'm perfectly fine with just using zero_after_use there, as the lifetime of such data is just microseconds anyway
167 2014-11-19 21:22:37 <cfields> sipa: ok, looks like all that combined pretty much solves my issues, then
168 2014-11-19 22:22:21 <Luke-Jr> sigh
169 2014-11-19 22:22:23 <Luke-Jr> master doesn't compiler
170 2014-11-19 22:22:25 <Luke-Jr> compile*
171 2014-11-19 22:22:40 <Luke-Jr> /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `secp256k1/.libs/libsecp256k1.a(field_5x52_asm.o)' is incompatible with i386 output
172 2014-11-19 22:23:38 <sipa> i386:x86-64 vs i386?
173 2014-11-19 22:26:15 <Luke-Jr> I guess
174 2014-11-19 22:28:02 <sipa> which one should it be?
175 2014-11-19 22:28:20 <Luke-Jr> i386
176 2014-11-19 22:28:23 <Luke-Jr> 32-bit OS
177 2014-11-19 22:28:35 <Luke-Jr> checking host system type⦠x86_64-unknown-linux-gnu
178 2014-11-19 22:28:40 <Luke-Jr> trying to figure out why it's misdetecting
179 2014-11-19 22:46:32 <Luke-Jr> not coming up with anything :/
180 2014-11-19 22:46:36 <Luke-Jr> cfields: maybe you can help?
181 2014-11-19 22:47:35 <cfields> Luke-Jr: does that happen often ?
182 2014-11-19 22:47:40 <Luke-Jr> cfields: 100% now
183 2014-11-19 22:47:47 <cfields> Luke-Jr: i mean with other progs
184 2014-11-19 22:47:51 <Luke-Jr> oh, no
185 2014-11-19 22:47:57 <Luke-Jr> just libsecp256k1 and Bitcoin Core now it seems
186 2014-11-19 22:48:10 <cfields> Luke-Jr: does it happen when you build libsecp by itself?
187 2014-11-19 22:48:13 <Luke-Jr> yes
188 2014-11-19 22:48:25 <cfields> but bitcoin was ok before today?
189 2014-11-19 22:48:34 <sipa> bitcoin is still ok for him
190 2014-11-19 22:48:40 <sipa> just libsecp isn't
191 2014-11-19 22:48:48 <sipa> (so it doesn't link)
192 2014-11-19 22:49:08 <Luke-Jr> cfields: yes
193 2014-11-19 22:49:33 <cfields> sec
194 2014-11-19 22:50:35 <cfields> Luke-Jr: bitcoin detects your proper host? or it detects the wrong one but manages to build anyway?
195 2014-11-19 22:51:14 <Luke-Jr> cfields: the latter it seems
196 2014-11-19 22:51:57 <Luke-Jr> hm, it may be this is just an outstanding autotools bug that only is a problem for assembly
197 2014-11-19 22:52:45 <sipa> ah
198 2014-11-19 22:53:08 <Luke-Jr> know any common autotools sw that has assembly I can look at?
199 2014-11-19 22:53:11 <cfields> Luke-Jr: we check the host to see if it's 64bit, if so, we build the 64bit asm
200 2014-11-19 22:53:27 <Luke-Jr> cfields: yeah, but in this case, it's misdetecting the host
201 2014-11-19 22:53:34 <sipa> cfields: shouldn't it look at the target?
202 2014-11-19 22:53:41 <sipa> or is that implied by host
203 2014-11-19 22:53:59 <cfields> Luke-Jr: understood. I'm trying to understand how we're supposed to know what the real host is
204 2014-11-19 22:54:17 <cfields> sipa: host == target, unless you're building a compiler
205 2014-11-19 22:54:23 <sipa> ok
206 2014-11-19 22:54:49 <instablimp> Dumb question: If I want to try out a pull request that's been submitted to bitcoin core, whats the easiest/best way?
207 2014-11-19 22:55:07 <instablimp> rather than cloning other person's repo
208 2014-11-19 22:55:16 <cfields> Luke-Jr: for the moment, you should be able to configure with: --with-scalar=32bit --with-field=32bit, i should think
209 2014-11-19 22:55:43 <sipa> instablimp: github actually exposes all pull requests as a repository
210 2014-11-19 22:56:09 <sipa> [remote "upstream-pull"] fetch = +refs/pull/*:refs/remotes/upstream-pull/* url = git@github.com:bitcoin/bitcoin.git
211 2014-11-19 22:56:26 <sipa> put that (with proper indenting and newlines) in your .git/config
212 2014-11-19 22:56:33 <cfields> Luke-Jr: can you paste a config.log somewhere? I'm not sure how else we can glean the host arch
213 2014-11-19 22:56:40 <sipa> and then do git fetch upstream-pull
214 2014-11-19 22:56:45 <gwillen> sipa: whoa. TIL.
215 2014-11-19 22:57:01 <sipa> then you can git checkout upstream-pull/$PULLNUMBER/head
216 2014-11-19 22:57:17 <instablimp> sipa: Ok let me try that out thanks
217 2014-11-19 22:57:26 <sipa> there's also upstream-pull/$PULLNUMBER/merge (which exposes a merge with the branch it's intended to be merged with)
218 2014-11-19 22:57:55 <Luke-Jr> cfields: http://codepad.org/zEdh4deP
219 2014-11-19 22:58:04 <lechuga_> lol pierre u need a cool nick :)
220 2014-11-19 22:59:21 <cfields> Luke-Jr: ./configure --host=i686-pc-linux-gnu
221 2014-11-19 22:59:26 <cfields> should work also, i'd think
222 2014-11-19 22:59:35 <cfields> (still looking for proper solution)
223 2014-11-19 22:59:35 <Luke-Jr> cfields: I expect so, but it'd be nice to fix this so it works OOTB
224 2014-11-19 23:01:08 <cfields> Luke-Jr: run "depends/config.guess" please
225 2014-11-19 23:01:11 <cfields> from srcroot
226 2014-11-19 23:01:14 <cfields> it just echoes your host
227 2014-11-19 23:01:31 <Luke-Jr> http://codepad.org/8ZOHjMTR
228 2014-11-19 23:01:35 <Luke-Jr> I added set -x
229 2014-11-19 23:02:22 <Luke-Jr> I don't see code in config.guess to even attempt to make a reasonable guess :/
230 2014-11-19 23:02:59 <cfields> ok, there's the problem. I'm not sure how projects outside of portage are supposed to work...
231 2014-11-19 23:03:51 <Luke-Jr> ?
232 2014-11-19 23:03:57 <cfields> sec
233 2014-11-19 23:14:31 <Luke-Jr> ⦠why is libsecp256k1 disabling pkg-config for mingw? O.o
234 2014-11-19 23:15:06 <cfields> Luke-Jr: you have gnuconfig package installed?
235 2014-11-19 23:15:17 <Luke-Jr> cfields: yes
236 2014-11-19 23:15:30 <Luke-Jr> 20140212
237 2014-11-19 23:16:12 <Luke-Jr> http://git.savannah.gnu.org/cgit/config.git/plain/config.guess seems to be wrong still anyway
238 2014-11-19 23:16:41 <cfields> Luke-Jr: yea, it's updated in the 99999 package
239 2014-11-19 23:16:46 <cfields> not sure why that's not pushed upstream
240 2014-11-19 23:16:53 <Luke-Jr> 99999 package?
241 2014-11-19 23:17:16 <cfields> http://packages.gentoo.org/package/sys-devel/gnuconfig
242 2014-11-19 23:17:43 <cfields> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/gnuconfig/files/99999999/0002-Add-x32-support-to-config.guess.patch?revision=1.1&view=markup
243 2014-11-19 23:17:46 <Luke-Jr> I don't see anything in 99999999 that would fix this
244 2014-11-19 23:17:52 <Luke-Jr> I'm not running x32, just normal 32-bit
245 2014-11-19 23:17:56 <cfields> ...
246 2014-11-19 23:18:23 <cfields> ACTION starts over from scratch
247 2014-11-19 23:18:34 <Luke-Jr> :/ sorry
248 2014-11-19 23:18:38 <cfields> i thought you were still running that crazy x32 setup
249 2014-11-19 23:18:40 <Luke-Jr> should have mentioned that upfront I guess
250 2014-11-19 23:18:51 <Luke-Jr> nah, I only built x32 in a chroot once or twice - it doesn't work enough yet
251 2014-11-19 23:18:57 <Luke-Jr> (ie, I couldn't get KDE to install)
252 2014-11-19 23:18:59 <cfields> obviously :)
253 2014-11-19 23:19:21 <sipa> it clearly escaped the jail!
254 2014-11-19 23:19:48 <lechuga_> on the lam
255 2014-11-19 23:19:51 <cfields> Luke-Jr: well if you decide to run it again, you'll probably want that patch :)
256 2014-11-19 23:21:03 <cfields> so... starting over. first guess would be that your env is poisoned
257 2014-11-19 23:21:46 <gmaxwell> I'd suggest x264 as a package which is fairly portable with a bunch of yasm ... but, alas, IIRC it doesn't use autotools.
258 2014-11-19 23:22:27 <Luke-Jr> cfields: well, config.guess is clearly buggy, so I'm getting close to "give up on it" :/
259 2014-11-19 23:22:29 <gmaxwell> If we're concerned the asm in libsecp256k1 may cause build issues for people other than luke, we could turn it off... it basically doesn't matter, esp for signing.
260 2014-11-19 23:22:32 <Luke-Jr> gmaxwell: yeah, that's what i checked first :P
261 2014-11-19 23:22:52 <gmaxwell> Luke-Jr: look to see what else in gentoo depends on both yasm and autotools?
262 2014-11-19 23:23:02 <cfields> Luke-Jr: i'm trying to decide if it really is buggy...
263 2014-11-19 23:23:11 <Luke-Jr> cfields: it never asks GCC what the arch is..
264 2014-11-19 23:23:13 <cfields> Luke-Jr: are you running a 64bit kernel?
265 2014-11-19 23:23:15 <Luke-Jr> yes
266 2014-11-19 23:23:54 <cfields> Luke-Jr: right, so that's our problem then. your host is 64bit. you just happen to be running a 32bit userspace..
267 2014-11-19 23:24:22 <cfields> libsecp makes the assumption that hostcpu arch= target arch. clearly that falls apart here.
268 2014-11-19 23:24:55 <gmaxwell> oh yea, thats bad.
269 2014-11-19 23:24:56 <cfields> i would imagine that portage passes --host=i686-foo to all autotools packages
270 2014-11-19 23:24:58 <Luke-Jr> it still compiles all the C code for the correct arch ;)
271 2014-11-19 23:25:04 <Luke-Jr> yes
272 2014-11-19 23:25:23 <gmaxwell> hm. cfields: I've built libsecp256k1 by itself many times with -m32 without issue.
273 2014-11-19 23:26:18 <sipa> gmaxwell: me too, though i think i had to specify --with-field=32bit in those cases
274 2014-11-19 23:27:43 <cfields> Luke-Jr: it's actually compiling for the wrong arch, it just doesn't know any better :)
275 2014-11-19 23:28:17 <gmaxwell> sipa: maybe I just always did.
276 2014-11-19 23:28:17 <Luke-Jr> cfields: well, it's wrong about which arch is wrong
277 2014-11-19 23:29:52 <Luke-Jr> gcc -dumpmachine looks handy
278 2014-11-19 23:31:25 <cfields> Luke-Jr: let me think on it some. technically, it's working correctly if it succeeds with --host=i386...
279 2014-11-19 23:31:33 <cfields> because technically, you're cross-compiling
280 2014-11-19 23:31:42 <Luke-Jr> no, I'm not cross-compiling..
281 2014-11-19 23:31:58 <Luke-Jr> there isn't a single x86_64 executable/library on my system
282 2014-11-19 23:32:09 <cfields> on your _x86_64_ system, you mean?
283 2014-11-19 23:32:48 <Luke-Jr> on my Haswell system
284 2014-11-19 23:32:50 <gmaxwell> cfields: everything else in my expirence does the right thing while passing m32 in cflags. I don't have concrete advice here, since I normally use inline asm in my projects and handle it a different way.
285 2014-11-19 23:33:42 <Luke-Jr> aha, that's probably why this problem is rare - inline asm would likely just work
286 2014-11-19 23:34:15 <cfields> gmaxwell: not saying it doesn't need a fix, only that it seems to be working as intended. just need to figure out what intentions to shift :)
287 2014-11-19 23:34:18 <sipa> ./configure CFLAGS="-m32" doesn't work here either
288 2014-11-19 23:34:37 <sipa> configure: Using field implementation: 64bit_asm
289 2014-11-19 23:34:46 <cfields> ./configure --host=i686-pc-linux-gnu
290 2014-11-19 23:34:47 <sipa> strangely enough, it does use the 32-bit scalar code
291 2014-11-19 23:34:56 <gmaxwell> yea, it's easyer to get things right for inline, since you can just control the behavior with ifdefs. Not that using yasm is bad... I'm just commenting that I don't personally have expirence with the build system issues involved with it.
292 2014-11-19 23:35:01 <sipa> so autodetection is working fine for the scalar code...
293 2014-11-19 23:35:31 <gmaxwell> sipa: because it tries to use __int128 presumably and fails to compile.
294 2014-11-19 23:36:06 <Luke-Jr> cfields: if you install i686 Debian on x86_64-capable hardware, you get what I have
295 2014-11-19 23:36:39 <gmaxwell> cfields: fedora i686 also installs an x86_64 kernel when using x86_64 hardware.
296 2014-11-19 23:36:49 <gmaxwell> Makes large memory support MUCH easier and faster.
297 2014-11-19 23:36:50 <sipa> right, and the 64-bit asm field code should work on x86_64, even if your compiles is old and doesn't have __int128
298 2014-11-19 23:37:00 <cfields> Luke-Jr: understood. again, i agree that it needs a fix
299 2014-11-19 23:37:38 <gmaxwell> cfields: ugh, it could test link it.
300 2014-11-19 23:37:48 <sipa> of course, you could try to compile a minimal program with yasm code, and see whether it links
301 2014-11-19 23:37:54 <sipa> gmaxwell beat me
302 2014-11-19 23:39:12 <cfields> yea
303 2014-11-19 23:39:35 <sipa> or we could replace the asm code with inline asm blocks :p
304 2014-11-19 23:39:46 <sipa> ACTION feels the wrath of the original author above him
305 2014-11-19 23:40:10 <cfields> +1 for that :)
306 2014-11-19 23:40:28 <sipa> (he very much dislikes the syntax or something)
307 2014-11-19 23:40:35 <cfields> not because of this, but because that would drop the yasm dep
308 2014-11-19 23:41:01 <sipa> yes, i know
309 2014-11-19 23:41:58 <gmaxwell> yasm is really nice if you use the macros, otherwise inline solves a _lot_ of problems, beyond simplifying the build, using inline asm lets you avoid dealing with the different calling conventions on different platforms. Though, annoyingly, x86_64 can't be done as inline asm in MSVC. (MS decided windows programmers shouldn't be using asm anymore and they don't support inline asm with msvc on x86_64)
310 2014-11-19 23:42:03 <cfields> Luke-Jr: let me poke at it a bit more. there must be something i'm missing. not sure how most other programs would manage to get this right
311 2014-11-19 23:43:04 <sipa> there must be some way of knowing for what architecture you're compiling...?
312 2014-11-19 23:43:42 <cfields> sipa: look at it this way. kernel is 64bit. userspace seems to be 32 (but could be both at once), and gcc builds both
313 2014-11-19 23:43:59 <sipa> well yes
314 2014-11-19 23:44:09 <cfields> so the best guess is whatever gcc cranks out by default, i suppose
315 2014-11-19 23:44:12 <sipa> but if you just invoke gcc, it builds for one specific target
316 2014-11-19 23:44:25 <sipa> can't you like just run gcc in a mode that outputs what platform it's building for?
317 2014-11-19 23:44:37 <cfields> but without actually building something, there's really no obvious answer, just by poking stuff
318 2014-11-19 23:44:43 <sipa> gcc -dumpmachine
319 2014-11-19 23:44:54 <cfields> yea
320 2014-11-19 23:45:45 <cfields> s/actually building something/invoking gcc/
321 2014-11-19 23:46:30 <Luke-Jr> cfields: http://codepad.org/UHTT0giM seems to work
322 2014-11-19 23:47:11 <sipa> clang -dumpmachine also works
323 2014-11-19 23:47:36 <Luke-Jr> is this patch okay to PR?
324 2014-11-19 23:47:37 <gmaxwell> well I suppose you can say that if dumpmachine fails that you don't get the asm. Seems fair enough.
325 2014-11-19 23:47:52 <Luke-Jr> gmaxwell: well, I'm failing over to what we have now (config.guess) in that patch
326 2014-11-19 23:49:46 <cfields> Luke-Jr: that patch seems to break all cross logic
327 2014-11-19 23:50:07 <sipa> ACTION zZzZ
328 2014-11-19 23:50:08 <Luke-Jr> cfields: ah, crap
329 2014-11-19 23:50:35 <cfields> Luke-Jr: the whole point of all the host stuff is to avoid assuming that your default compiler spits out what you want :)
330 2014-11-19 23:50:46 <Luke-Jr> cfields: wait, it does? It shouldn't..
331 2014-11-19 23:51:00 <Luke-Jr> I'm using $CC after letting autoconf detect the CC var
332 2014-11-19 23:51:14 <Luke-Jr> in a cross environment, $CC should be the cross-compiler
333 2014-11-19 23:51:20 <cfields> no
334 2014-11-19 23:51:20 <Luke-Jr> which should work with -dumpmachine..
335 2014-11-19 23:51:24 <Luke-Jr> no?
336 2014-11-19 23:51:28 <cfields> it uses AC_CANONICAL_HOST to find the host compiler
337 2014-11-19 23:51:41 <Luke-Jr> ?
338 2014-11-19 23:51:47 <cfields> Luke-Jr: ./configure --host=arm-linux-gnueabihf
339 2014-11-19 23:51:52 <cfields> everything just works
340 2014-11-19 23:52:20 <Luke-Jr> yes, that still works
341 2014-11-19 23:52:43 <Luke-Jr> arm-linux-gnueabihf-gcc -dumpmachine => arm-linux-gnueabihf
342 2014-11-19 23:53:02 <cfields> CC isn't set to arm-linux-gnueabihf-gcc
343 2014-11-19 23:53:56 <Luke-Jr> cfields: it is