<marusich>Question about cross-compiling C code. If I need to cross-compile a piece of software for a target architecture, and this software needs to link against some library named libfoo is it normal to link against the same libfoo when cross compiling, or do you have to link against a special version of libfoo that has been built specifically for cross-compiling to that target architecture...?
<marusich>I mean, is it normal to link against the same libfoo you would normally link against when not cross compiling.
<marusich>My understanding is that gcc is "special" and has to be told when it is built what the build, host, and target triplets are, but for other libraries (like the hypothetical libfoo), that dance is not necessary.
<leoprikler>it's compilers and build tools in general, that make that distinction; otherwise it's more or less just host vs. target
<marusich>So, although I realize this may be a somewhat trivial question, is my understanding correct? That if libfoo is like most libraries, you would generaly link against the same one (e.g., the same .so file or .a file that you have on hand) regardless of whether you are cross-compiling or not?
<marusich>i.e. the linker options would not need to change
<leoprikler>I'm not quite sure if I understand, but you'd link against target libfoo regardless of host/build IIRC.
<leoprikler>I.e. you don't care if an i686 or amd64 produced your m68k code, but you have to link against m68k.
<leoprikler>Which would imply the "linker flags not needing to change" safe for stuff that depends on the architecture (like e.g. needing some arcane linker scripts)
<marusich>I guess what I mean is, if I'm on a given system and I'm just compiling for various targets, because I have multiple cross toolchains installed and I can do that, would I be using the same libfoo every time?
<marusich>Or, would I have to also install a different libfoo for each target architecture, which I then link when cross-building the software?
<marusich>I get that I need multiple cross toolchains, one for each target.
<marusich>What I am asking is, would I normally need one libfoo per target, also?
<marusich>I think the answer is "no" and am just hoping someone can confirm.
<leoprikler>I think the answer is "yes", your inputs need to match the target architecture.
<leoprikler>(Hence the distinction between inputs and native-inputs in Guix.)
<marusich>If that's the case, then why are so many c libraries listed as "inputs" in package definitions?
<marusich>e.g. emacs has many "inputs" and no "native-inputs" defined.
<marusich>ok, i see. So, it is probably the case that if you have some libfoo and you are compiling for 3 different target architectures, you actually would need to compile libfoo 3 times, once for each target architecture, and then you would also have to tell the linker to use the right one, in each of the 3 cases, right?
<marusich>For example, in a world where you had built 3 cross compilation toolchains manually and you manually built your libfoo. It sounds like you are saying you would have to cross-compile your libfoo 3 times, for the target architecture, to get 3 different libfoos, each specialized or the target architecture.
<marusich>But it's kind of like the Guile manual in that regard: it provides correct information.
<marusich>I won't complain much about it because I should try to improve it if I care that much, but my point is, if you aren't already a cross-compilation expert, that section of the Guix manual is not quite satisfactory.
<marusich>I've had to explain that section multiple times to people, and although I think I understand it correctly now, it took a while to sink in. My lack of cross-compilation experience probably didn't help.
<marusich>I wonder if it would be nice to have a brief intro to cross compilation, but that seems rather out of scope for the guix manual.
<kozo[m]>Hello, I've been testing an issue for 2 days now. If anyone is willing to participate, I'd like to know if the following command works for you: guix environment --ad-hoc --container --no-cwd --network hello.
<kozo[m]>Whethere it works or not, I'd like to know what kernel you are using, please and thank you
<kozo[m]> * Whether it works or not, I'd like to know what kernel you are using, please and thank you
<lfam>It works for me on Debian with 5.11.4 stable kernel
<sturm>hi folks, I just did a `sudo guix pull` and `sudo guix system reconfigure` and got "guix system: error: aborting reconfiguration because commit 090456dacb76160280a630d53f4f47b421281c66 of channel 'guix' is not a descendant of 8a920dc6716599e58776d41f73b0aff4281530ed"
<sturm>I'm not aware of anything unusual that may have led to this
<civodul>sturm: hi! this is preventing you from downgrading your system
<civodul>you're currently running commit 8a920dc6716599e58776d41f73b0aff4281530ed, which is newer than the other one
<civodul>note that when you run "sudo guix system reconfigure", you're running the user's 'guix', not root's
<civodul>IOW, you're not running the one you got with "sudo guix pull"
<civodul>try this instead: "guix pull && sudo guix system reconfigure ..."
<sturm>ooooh right, thanks for explaining - I did understand this a while back and forgot :)
<civodul>heh yw! sudo can lead to confusing situations
<jeko>some differences but I don't know how they impact the bsd compatibility
<leoprikler>If I read this correctly, it's a find-and-replace with the copyright holder, right?
<allana>Hi everyone. Are there any ungoogled-chromium users here? I may be having an issue with it. I say "may" because I am having quite a few problems at once that may be related. I am getting these errors when running chromium and visiting a site: [5508:5508:0308/111526.288773:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [5511:5530:0308/111529.047398:ERROR:ev_root_ca_metadata.cc(841)]
<leoprikler>koleesch: w.r.t. your question earlier, it's technically possible, but we can't in good conscience tell you (how) to do it
<koleesch>leoprikler: thx. jonsger told me it is possible. i understood your conscience. But i use old hardware and i want to run guix on it.
<nckx>Oh, I missed that question. Wasn't ignoring you, koleesch! We believe that non-free software is harmful, and don't believe in harming (or helping to harm) people in our IRC channel or mailing lists.
<alextee[m]>does guix use some kind of established standard for its commit message format?
<mothacehe> civodul: just added the wip-build-systems-gexp branch!
<Artemix>I was wondering about something... say I have a pretty long configuration that I would like to version / attach to my system config.scm, where should I usually store it? A subdirectory in /etc ?
<roptat>Artemix, personally, I have a git repository with all my config, and I store it in /root
<nckx>Artemix: It's entirely up to you. I put my entire Guix System configuration in /etc/guix, with my system.scm in a /etc/guix git repository along with about 20 other configuration files (I dislike writing them in Scheme).
<Artemix>I haven't gotten a hang of packaging yet, I should get back into the manual.
<roptat>basically, it's a cron job that periodically pulls the repo, build the website to the store, and symlinks a known directory to the result
<Artemix>My memories of packaging are .tar.gz/.deb level for now (ie building a release version, zipping it, and putting it on a mirror), I find it simpler and pretty cool to avoid installing build-only tools on my prod systems
<Artemix>I was originally thinking about making a small guix package mirror for the same deployment model