21400+ entries in 0.044s
mod6: if you show me what enemy has via link, maybe i can replicate it?
mod6: that type of thing.
mod6: like they have: [CBase58Data] <--- [CBitcoinAddress]
mod6: so far, all i see are hierarchal graphs for base-classes/types. was trying to find something for CBlock, but I don't as of yet, see a graph.
mod6: i think it just ends up munging all of the file names and stuff.
mod6: yeah, i don't like that either.
mod6: i think i've seen it, one sec.
mod6: that link in there shows which patches were used, and how they are applied. couldn't find a better way to do this at the moment.
mod6: it's a goof-ball way to put in all the patches applied, but that link show's all the patches and how I applied them.
mod6: oh i think i know what i missed.
mod6: dpaste.com/0HMWFYN.txt
mod6: weird, same problem: dpaste.com/05ZZ443.txt
mod6: i'll take it down, and add the irc patch
mod6: <+ascii_field> dnsseed_snipsnip, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar << oh, well you didn' say it in here ;)
mod6: do you want me to post the doxy for that as well then?
mod6: <+ascii_field> dnsseed_snipsnip, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar << ok, yup, was able to extract v0.5.3.1-RELEASE and apply these four patches without incident.
mod6: ok, i'll give that a shot here quick.
mod6: (11:31) <+mod6> asciilifeform: I just did the following: extracted v0.5.3.1-RELEASE applied the following patches successfully { dnsseed_snipsnip, kills-integer-retardation, nubs-gentoo-sanity, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar } but when I added the patch for IRC demo, got the following error:
mod6: ascii_field: oh, i did have an issue patching in that last IRC demo patch.... im gonna try it again, but it complained about net.cpp:ThreadGetMyExternalIP
mod6: ascii_field: ok, i guess i didn't get that part about gcc/uclibc being in there with openssl/boost/bdb.
mod6: so gcc as well then.
mod6: mircea_popescu suggested that we should build uclibc statically itself inside of our bitcoin bundle.
mod6: our make file has -lpthread in there.
mod6: not sure if you caught this:
mod6: You'd think a linker should be able to produce a statically linked binary, weather itself is dynamcially built or statically built.
mod6: I wouldn't have thought that we'd have to include a statically built linker...
mod6: yeah, certainly could be something to this.
mod6: Ah... ok, i think I'm coming to some understanding here. I guess I didn't get that you were saying to compile uclibc /statically/ under our own project just the same as we have say, openssl or boost or bdb?
mod6: To be clear, shared libs /should/ be using -fPIC. If I understand this correctly.
mod6: i.e. ( [ jne 0xdeadbeef ]
mod6: ( for the example [ jne CURRENT+10 ] ), and for the non -fPIC code, the compiler will set these to specific memory addresses.
mod6: so a shared lib would be able to modfiy/change the addresses as needed to where the lib is loaded into memory.
mod6: <+mircea_popescu> what's -fPic anyway << position independant coe: Generated machine code is not dependant on located at a specific memory address to work. for example in the asm a jump can be to relitive address [ jne CURRENT+10 ] as opposed to say [ jne 0xDEADBEEF ]
mod6: while trying to figure out how to set "BUILD_SHARED_LIBS=false" or something, i ran into this; www.cmake.org/pipermail/cmake/2006-October/011418.html
mod6: anyway, will check back into that in a bit... maybe i did something weird. but i'm pretty sure it was the correct order.
mod6: asciilifeform: I just did the following: extracted v0.5.3.1-RELEASE applied the following patches successfully { dnsseed_snipsnip, kills-integer-retardation, nubs-gentoo-sanity, orphange-thermonuke, orphange-tx-amputation, dns-thermonyukyoolar } but when I added the patch for IRC demo, got the following error:
mod6: <+mircea_popescu> mod6 perhaps something as banal as turning off BUILD_SHARED_LIBS in cmake ? on the grounds that these libraries won't be shared anyway ? << yeah, worth a shot.
mod6: But anyone is welcome to patch on their own.
mod6: <+pete_dushenski> i figure that with all the traffic that the contravex '$20 node' article is receiving of late that it's time to update it with a proper install of 0.5.4 << We're not there yet.
mod6: There will be an update at somepoint once patches are ratified and a new milestone rolled.
mod6: Now, for all the patches that have been submitted post-release, you need to apply those patches directly from the mailing list. No guide as of yet.
mod6: But, it's probably just easier to download the tarball yourself and extract.
mod6: <+pete_dushenski> mod6: have you posted a foundation 'guide' since 0.0.5 that i'm not seeing on the mailing list ? << nope. that version should cover everything up through the v0.5.3.1 release.
mod6: im sure i'll get it figured out.
mod6: i've tried like 3 different versions of gcc, with and without my special gcc patch shoehorned in, 2 different versions of uclibc. not quite sure what to think yet.
mod6: im getting to the point of 'out of my depth'
mod6: yeah, im not really sure.
mod6: /lib/libuClibc-0.9.33.2.so
mod6: i think that's referring to uclibc which is an .so perhaps
mod6: i'll see if i can get to that here sometime today.
mod6: naw, haven't tried yet.
mod6: /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.8.4/../../../../x86_64-gentoo-linux-uclibc/bin/ld: /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.8.4/../../../libc.a(jmp-unwind.os): relocation R_X86_64_PC32 against undefined symbol `__GI___pthread_cleanup_upto' can not be used when making a shared object; recompile with -fPIC
mod6: just compiled it like 20 minutes ago again with my newest gentoo, still barfs.
mod6: well they work in the context that these files compile without /those/ specific problems (i.e. namespace problems with boost), but we still have the gcc/uclibc issue.
mod6: do you want me to add in the { Gentoo Sanity } patches as well?
mod6: asciilifeform: lemme see what i can do.
mod6: all the way up through the IRC demolition?
mod6: i generated some quick doxygen stuff... lemme put it up somewhere quick so you can look and see if it's ok.
mod6: so i create gentoo via stage3 whole process in an instance, then have to create snapshot & make image from snapshot. deploy new instance from image.
mod6: finally. new AMI created. that only took ... you don't wanna know.
mod6: Then I'm gonna need to cut away from working on that on Saturday afternoonish at the latest to work on the SoBA -- which is looking to be lengthy for this month.
mod6: im currenty building a new AMI for gentoo so I/we can test wtf is going on in there with gcc/uclibc. I should be done with that in a few hours.
mod6: this is a good idea though.
mod6: <+asciilifeform> unrelated: anybody try capping mempool size ? << not me yet. there's a laundry list of stuff to get through yet.
mod6: I don't think that's ever been attempted iirc.
mod6: we could try some other version like 1.0.0.0 and see what happens i guess.
mod6: well, my concerns were of a technical nature anyway.
mod6: And if we wanna call it version 69.69.69.69 then there was some sort of concerns here surrounding weather or not we'd be able to connect to other nodes. I'd have to go back and look and dig through the code a bit though, I can't recall it all off hand.
mod6: so we've talked about the versioning quite a bit since October. The deal is, if we talk about nothing other than just the format ( X.X.X.X ), we know that we'll have to change much more code than just one line to give it a new version number, as there is a bunch of stuff in there that is used to parse this value.