IRC channel logs

2013-11-17.log

back to list of logs

<civodul>Hello Guix!
<mark_weaver>hi civodul!
<civodul>the libgcc_s mystery goes on: http://sourceware.org/ml/libc-help/2013-11/msg00023.html
<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.
<civodul>heh, ok
<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>oh, ok!
<civodul>i think i got it
<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ñ
<viric>dlopen
<viric>(I rolled the dice)
<mark_weaver>civodul: nice!
<gzg`>Yah? http://www.itwire.com/business-it-news/open-source/62297-developers-deny-gnome-dependent-on-systemd
<gzg`>Consolekit or like feature(s) in Dmd still looks like the way to go.
<civodul>viric: not so simple: http://sourceware.org/ml/libc-help/2013-11/msg00023.html
<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 ok
<civodul>the conclusion i reached: http://sourceware.org/ml/libc-help/2013-11/msg00026.html
<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>which means, we need a hack!
<civodul>:-)
<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 :-)
<mark_weaver>I don't know if it's possible though.
<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.
<mark_weaver>(even in the final system)
<civodul>s/LFS/FHS/
<civodul>no, that shouldn't happen
<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>so in that case there's duplication
<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>yeah, understood :-)
<civodul>viric was able to deploy Nix-built software on the Nanonote
<civodul>by cross-compiling everything
<mark_weaver>nice!
<viric>I deployed an OS
<viric>a GNU OS :)
<viric>system5, not system500
<civodul>system5 as in "System V"?
<civodul>as in "!systemd"? ;-)
<viric>civodul: sure. the system5 pieces. :)