IRC channel logs
2013-11-17.log
back to list of logs
<civodul>mark_weaver: are you familiar with the loader? <mark_weaver>well, I know the fundamentals of how loaders work (was the head TA for an OS class which involved writing a loader about 25 years ago :), but I can't say that I'm super familiar with GNU ld. <mark_weaver>if the folks on libc-help don't have an answer, I'll take a look later, but today I must rest. I stayed up all night working on (ice-9 popen), so I've had essentially no sleep. <civodul>now to find a reasonable workaround... <viric>I think that libgcc_s for pthread_cancel is dlopened, so it has to be in the runpath of the shared object calling the dlopenñ <gzg`>Consolekit or like feature(s) in Dmd still looks like the way to go. <viric>civodul: is it really the guile elf doing the pthreads_cancel? Not a libguile.so or so? <civodul>libguile.so, but it has libgcc_s in its RUNPATH too <viric>ah quite far. a lot further than me :) <civodul>first time i dig this deep in ld.so ;-) <mark_weaver>civodul: so, should libpthread's -rpath include the directory with libgcc_s ? <mark_weaver>or is this a circular dependency that's hard to deal with in guix? <civodul>that's not possible, because glibc-final would retain a reference to gcc-boot0 <civodul>i think the hack will be to not use "--as-needed -lgcc_s", but just "-lgcc_s" <civodul>sounds like a reasonable solution to me <civodul>but maybe we should take that as an opportunity to get toolchain people on board ;-) <mark_weaver>it would be good if guix had a better way to cope with circular dependencies. <civodul>there's no such thing as circular dependencies :-) <civodul>the dlopen hack in glibc is precisely to avoid circular dependencies <civodul>that works fine in an LFS setup, but not so well for us <mark_weaver>well, it seems to me that the current strategy is just go round around the circle a few times during bootstrap, possibly leading to multiple copies of some libraries being loaded into the system. <civodul>normally only glibc-final is actually loaded in a live system <civodul>likewise, only gcc-final's run-time support libs are loaded <mark_weaver>hmm, okay. maybe the duplication is just in the tools, like compilers. <mark_weaver>(I've noticed that a different compiler is used to compile things in guix than the compiler I get from "guix build gcc") <mark_weaver>which would lead me to believe that there are at least two copies of the gcc runtime, assuming that you compile some things from the gcc in ~/.guix-profile/bin/ <mark_weaver>but the gcc runtime is relatively small, so that's probably not a big deal. <civodul>the problem is that there's gcc-final, and there's gcc-4.8 <civodul>when you run "guix package -i gcc", you typically get the latter <civodul>but we should fix that, perhaps in "guix package" <mark_weaver>it's a slightly bigger deal that the tools are duplicated, meaning that if I'm compiling things outside of guix and within guix at the same time, there are two copies of a lot of binaries in memory. <mark_weaver>anyway, just something to keep in the back of my mind: wondering if there's a better way to deal with graphs that are not DAGs. <mark_weaver>but obviously, it would be a very fundamental change in the concepts of nix/guix. <mark_weaver>(I think more about these things because I'm using less powerful hardware :) <civodul>viric was able to deploy Nix-built software on the Nanonote <viric>civodul: sure. the system5 pieces. :)