IRC channel logs


back to list of logs

<civodul>some C++ hacking is in order!
<civodul>in, can you add some printfs? :-)
<civodul>namely under "case wopSetOptions"
<civodul>maybe it's a 32-bit thing
<civodul>in the RPCs
<Steap>settings.useSubstitutes is set to "0" in "case wopSetOptions"
<civodul>damn, then i'm lost
<civodul>i think i got it
<civodul>Hello Guix!
<civodul>hey hey!
<bubu>hi hi
<civodul>aaaaahhh :-)
<bubu>you are not alone !
<civodul>good to know!
<bubu>most stupid film i watched for months :/
<bubu>too bad all other (decent) films were full at the time i went to the cinema...
<bubu>hum civodul you're an autotools expert i guess ?
<civodul>a complete expert yeah
<civodul>i could add that to my CV
<civodul>why? :-)
<bubu>because i have some optimization issues
<bubu>i have split my project in two parts
<bubu>most of it in lib/
<bubu>and a command line interface in src/
<bubu>the thing is that it highly vectorizable (4 levels of loops performing additions and multiplications)
<bubu>so I have my code in a .a
<bubu>and link it to the binary build in src/
<bubu>but gcc doesn't optimize this well
<bubu>if now i build everything in a single binary it seems to work
<civodul>hey, that's not an autotools question, is it? :-)
<bubu>instead of LDADD = ../lib/
<bubu>more a gcc one i guess
<bubu>i suppose
<civodul>so, i'm tempted to answer "-flto"
<bubu>if i project_SOURCES = ../lib/files.c
<civodul>at least that's what i would try
<bubu>optimisation is ok
<bubu>yes I have added -flto
<civodul>so run "make clean && make CFLAGS="-g -O2 -flto" LDFLAGS=-flto"
<civodul>doesn't that help?
<bubu>but i'm suspecting it is because for building the library gcc cannot inline too much or something like
<bubu>all symbols must be exported no ?
<bubu>I would like to have only the symbol in my _public.h header
<bubu>so I guess I should everything else properly organised in files and static all the functions ?
<civodul>well, if the lib contains LTO objects, then it can perform inlining & co. in the final binary
<bubu>oh !
<bubu>yes I added flto both in cflags and ldflags
<civodul>functions have to be either static or __attribute__((hidden)) to be subject to inlining
<civodul>("hidden" or similar)
<bubu>hum, yes i suspected something like this so i have to figure out how to properly handle this for functions between files that i don't want to export
<bubu>well seems ok if i handle this properly
<bubu>is there a way to display the build process in a more synthetic way ?
<bubu>CC file.c
<bubu>but otherwise i must admit it seems quite good
<bubu>i yet didn't understand how to properly make a "release" archive containing the configure etc... and the sources files
<civodul>just type "make dist"
<civodul>the Auto* manuals are very good
<bubu>yes they are
<bubu>but they are also very dense !
<civodul>yep :-)
<bubu>nevertheless more doc in better than less !
<bubu>next step will be texinfo
<civodul>so what's your project?
<bubu>data treatment
<bubu>putting everything in big columns
<bubu>and heating the room with the cpu looping on them
<civodul>heh, ok
<bubu>nothing amazing :s
<bubu>it's octave-like in a sense
<bubu>but a bit faster
<bubu>i was impressed by new intel cpus and SIMD
<bubu>and gcc to use them quite properly
<bubu>I didn't find a way to use -std=gnu11 instead of gnu99 i suppose this will come in an ulterior version ?
<civodul>hmm, dunno
<bubu>make dist is so cool !
<bubu>i like it :)
<civodul>-std=c11 probably works though
<civodul>and you've not seen "make distcheck" yet! ;-)
<bubu>but how to make the auto* to use it ?
<civodul>use what?
<bubu>c11 or gnu11 instead of gnu99
<civodul>ah, just add AM_CFLAGS = -std=c11 in a
<bubu> not yet any references to c11
<bubu>how is the work on guix going on ?
<civodul>with cross-compilation in place, we're close to the next release
<civodul>and then closer to a bootable thing as well ;-)
<bubu>good to know
<bubu>really willing to try this an OS without mixing package managers