<codemac>nvm figured it out, bad ctrl-left in paredit
<amz3>I find editing with paredit more difficult, right now, I need to get more confortable with guile I think
<mark_weaver>codemac: I wish you had consulted with us about how best to go about writing the 'go' package. it's a bad idea to use the trivial-build-system for this. I'm afraid this is the wrong approach.
<mark_weaver>gnu-build-system takes care of the rpath issues automatically in various ways, and you're reinventing the wheel here I'm afraid.
<mark_weaver>for example, we have something called 'ld-wrapper' that automatically adds the rpaths to the linker commands.
<mark_weaver>you are having to use patchelf, which is very non-portable and currently only works on intel systems, to work around your lack of ld-wrapper usage.
<mark_weaver>and of course, you're having to reinvent things that are done in the early phases of gnu-build-system, e.g. setting environment variables
<codemac`>mark_weaver: no worries, I'm just learning things here. I wasn't anywhere near ready to post that to guix-devel or anything.
<codemac`>mark_weaver: the problem is that the go binary doesn't have the same elf sections that things notice, and go does not use ./configue, make, or any of the stuff in gnu-build-system so this was my experiment to figure out what it *did* need.
<codemac`>mark_weaver: any pointers about ld-wrapper?
<codemac`>mark_weaver: not to mention building go doesn't use gcc ld, it uses their own ld that uses different commands. I'm not sure I see how gnu-build-system helps a ton here, but I don't know much about the packaging system yet.
***codemac` is now known as codemac
<davexunit>does anyone have a good resource for understanding how psuedo-terminals work?
<davexunit>I'm reading the gnu libc manual, but I feel like I need more background to really grok it.
<codemac>davexunit: another thing that probably cares a lot about this is things like logind? maybe they have more resources too?
<davexunit>codemac: are you saying that the logind source code might have good information?
<codemac>yea, beacuse they have to open ttys / ptys to open consoles, and they may have docs that explain it since systemd is rewriting the globe for whatever reason. xterm / ssh may be interesting as well.
<yenda>I get this error : "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory". It's wierd because libgcc_s.so.1 seems to be included in gcc (according to debian packages)
<codemac>yenda: did you get the runtime/cgo.a errors?
<codemac>I used the external linker to get things building & running correctly.
<codemac>they all run now successfully during build, but everything segfaults when I run them after install. I think mark_weaver had suggestions for me, but a lot of the gnu-build-system stuff is invalid for go's completely non-gnu build
<davexunit>codemac: maybe you should take a look if Nix has a go package
<codemac>bavier: because it's not just another compiler, it's also another runtime (as of 1.4, this may change for 1.5 as the compiler & runtime will be written in go). So basically anyone using go doesn't use it.
<rekado->codemac: and you cannot use it for bootstrapping either?
<rekado->for the JDK I used GCJ for bootstrapping.
<rekado->GCJ + classpath is also not used by anyone in production, but it's sufficient to compile the JDK.
<codemac>rekado-: I'm not sure, go combines their build and run steps, and include their own go_bootstrap. It's a very convoluted build system so I haven't exhausted all options yet.