Show Idle (>14 d.) Chans

← 2020-04-12 | 2020-04-14 →
asciilifeform: !w poll
watchglass: Polling 11 nodes...
watchglass: : Could not connect!
watchglass: : Alive: (0.082s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : Alive: (0.083s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776 (Operator: asciilifeform)
watchglass: : ( Alive: (0.097s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776 (Operator: asciilifeform)
watchglass: : ( Alive: (0.127s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=624128
watchglass: : Alive: (0.218s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : Alive: (0.195s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : ( Alive: (0.083s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : Alive: (0.361s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : ( Alive: (0.316s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=625776
watchglass: : Busy? (No answer in 20 sec.)
asciilifeform: thimbronion: answered.
thimbronion: asciilifeform: got it. for future reference, I am subscribed to the comments feed and will be notified of any comments.
asciilifeform: in other noose, RIP john conway.
Apocalyptic: RIP indeed
asciilifeform just like the last time, quite disgusted after reading the plankton commentaries
Apocalyptic: asciilifeform, is it an usual behaviour to have static libs not resolving symbols from other (static) libs ?
asciilifeform: Apocalyptic: occasionally one finds that a static build (necessarily on a nonstatic os) didn't actually work, and result uses e.g. dload
asciilifeform: Apocalyptic: why, didja catch one red-handed ?
Apocalyptic: I managed to build a static version of libgmp, but then I wanted to build a static lib of gmp-ecm, which did build
Apocalyptic: however when I do link -lecm , it complains about not resolving symbols from libgmp
asciilifeform: sounds like paths issue
Apocalyptic: when I do specify "-lecm -lgmp", it does link against gmp, but dynamically so
asciilifeform: see e.g. this example re use of static c libs.
Apocalyptic: asciilifeform, I may have a naive view of static libs, but I thought and suspected until now the second lib would have all the functions from the first inside
asciilifeform: Apocalyptic: the correct way to do these is on a box where the dynamic libs aint present anywhere
Apocalyptic: so libecm would bundle all the libgmp bits it needs
asciilifeform: so then certain they dun get linked in dynamically
asciilifeform: for gcc's linker, you need not only the lib (visible to linker) but the corresponding header (visible to compiler)
asciilifeform: only then get working build
asciilifeform: when you -lxyz , it will find whichever xyz is 1st in yer path
asciilifeform: if yer box has the dynamic one, that's likely to be it
Apocalyptic: today I learned that "Static libraries do not link with other static libraries. The only way to do this is to use your librarian/archiver tool (for example ar on Linux) to create a single new static library by concatenating the multiple libraries."
asciilifeform: aha, you get a '.a'
asciilifeform: see the mpi example.
Apocalyptic: I do have two '.a' currently
asciilifeform: so you want them, and only them, in yer libs path; and the corresponding headers in include path.
Apocalyptic: I should probably nuke all the .so present
asciilifeform: nix the '-l' , it expands to the dyn. linkable crapola
Apocalyptic: I was using opensores makefiles as is found in the gmp-ecm repo
asciilifeform: typically these are of 0 help when doing a static
Apocalyptic: so no doubt I should review all these gcc and libtool calls
Apocalyptic: I was trapped by a "--enable-static" nicely looking flag for a ./configure
asciilifeform: Apocalyptic: outta curiosity, what were you building ?
Apocalyptic: I'm building cado-nfs and some misc tools in it requires the present of said gmp-ecm lib
Apocalyptic: I'm experimenting to get fully-static build, (as far as the math libs goes at least)
Apocalyptic: there's gonna be dynamic dload,pthread crapolade left no matter what
asciilifeform wonders whether it'd build with his static mpi
asciilifeform: prolly you wouldn't want to , tho, i nuked the asm inlines
Apocalyptic: yeah this is actually needed for heavy fast computations
Apocalyptic: I discovered they have an almost complete implementation of DLP solvers in finite fields of the form GF(p^2)
Apocalyptic: and support for the more general GP(p^k) for small k
asciilifeform: bake a ecdsa phuctor, wainot
Apocalyptic: not easy to find those around, compared to Z/pZ implementations which there is plenty of
asciilifeform: if yer doing serious numerics, expect to write own stack eventually, the opensores crud is typically good for nuffin in particular
asciilifeform: (optimized neither for speed, nor compactness, nor 'fit in head')
asciilifeform: and ftr the use of cpp of any form in a speed-sensitive application is nuttery
Apocalyptic: I doubt I could beat all the asm-ism they have in libgmp
Apocalyptic: speed-wise
asciilifeform: on one occasion, i did, without even trying . their choice of algos is sometimes sad.
asciilifeform strongly suspects that an asm-massaged ~branch free~ numerics stack would beat the shit outta gmp, on current-day irons
asciilifeform: cache miss costs hell of a lot moar than a few thou. redundant ADDs etc
Apocalyptic: would you recommend such practices of bundling several static libs into one ?
asciilifeform: it's that, or actually fiddling w/ the coad, afaik
asciilifeform bbl,meat
Apocalyptic: for completeness: after using ar to create the megalib, it indeed links statically to both and no unresolved symbol errors
asciilifeform: Apocalyptic: neato, congrats
asciilifeform: fwiw this is what gnat does internally when building ffa.
asciilifeform: (you get a libFFA.a)
asciilifeform: (there is however no use of gnumake in ffa; instead uses the much saner 'gprbuild' mechanism that comes in gnat)
feedbot: << The Montevideo Standard -- UNASEV Reports Far Safer Roads This Semana de Turismo
feedbot: << Bingology - The Blog of Aaron 'BingoBoingo' Rogier -- Uruguay-SSR And The Hallucinated Seige
← 2020-04-12 | 2020-04-14 →