<jlicht>I'm trying to build some octave/matlab modules using octave, and its internal mex compilation command (which is actually mkoctfile with some flags) cannot find the openblas library I have installed in my current guix profile.
<jlicht>Is anyone familiar with octave not respecting some of the paths/symlinks set by the current guix profile?
<lfam>jubalh: help-guix is a new mailing list for people to ask for help. Most discussion is on the guix-devel mailing list. The project started in 2012.
<lfam>jubalh: Are you trying to install the guix package manager on another distro, or the full system guixsd?
<lfam>If you want to install the package manager, follow the instructions in section 2. For the full system, section 7. And you can play with the full system on your current system with `guix system vm`
<jubalh>lfam: i would like to install it on a separate pc, so the full system
<mark_weaver>jlicht: does the error (about not finding the openblas library) occur while compiling/linking the modules, or when attempting to load/run the modules?
<mark_weaver>when compiling C/C++ code using the GNU toolchain, the LIBRARY_PATH variable tells the linker where to find libraries at compile/link time. As for run-time, the 'gcc-toolchain' meta-package includes the 'ld-wrapper' package, which has an 'ld' command that automatically adds options to set rpaths in the linked program, to help it find its shared libaries at run-time.
<jlicht>mark_weaver: it occurs when compiling the binaries. I verified that other things are working by manually adding the -L/gnu/store/etcetclibfolder flag to the compilation command
<mark_weaver>I can think of a couple of possible problems: (1) maybe LIBRARY_PATH is not set properly in the environment where you ran 'mex'. (2) maybe your 'ld' is from 'binutils' instead of from 'ld-wrapper' or 'gcc-toolchain'. (3) maybe 'mex' doesn't use the 'ld' in your PATH, and directly uses the one from 'binutils' or does its own thing.
<jlicht>(3) would mean I need to fix the script manually, I assume?
<mark_weaver>jlicht: well, if it's (3) then we should fix our package
<mark_weaver>jlicht: are you using GuixSD or Guix on top of another distro?
<jlicht>I'm currently using Guix on top of a 14.04 ubuntu base
<jlicht>I'm not totally sure how to evaluate that. Mex is called as an internal octave command, which seems to be translated to a call to the mkoctfile binary. Is it correct to assume this happens in my current profile?
<mark_weaver>jlicht: if 'mex' is an internal octave command, then I guess the environment where octave is run is the relevant one.
<mark_weaver>do you run octave from the command line or via something else (e.g. a desktop environment launcher)?
<mark_weaver>actually, I think I don't have time to diagnose this with you, and probably people who actually use octave with Guix would be able to investigate more efficiently. Can you email firstname.lastname@example.org about it?
<mark_weaver>make sure to mention that you're running Guix on top of ubuntu
<jlicht>mark_weaver: I *think* I might have found the issue: it seems that the openblas library (0.2.15) builds into an openblas.so file (and some other stuff), whereas other distributions and software depending on this library expects a blas.so file.
<mark_weaver>jlicht: ah, okay. well, if you could email email@example.com about it that would be helpful
<jlicht>mark_weaver: I'll look into that tomorrow, but thanks for your help!
<jubalh>It would be interesting to know whether you people run guix in guixsd or in another distro?
<jubalh>maybe it would be good to start with the latter and later transition when its more complete?
<jubalh>"On hosts using the systemd init system, drop ~root/.guix-profile/lib/systemd/system/guix-daemon.service in /etc/systemd/system. " instead of doing the line above (running the daemon by hand)?
<jubalh>hmm i am running a binary distribution but used funtoo before that. maybe guix is just perfect to what i need in many cases. one case is that i am not happy with the compilation defaults of some packages i use, and guix would be a nice way to gain control over it without getting trouble with the systems package manager (i suppose)
<gibal>greetings folks! life treating you all well i hope?
<gibal>i was thinking about trying guix - but i dont know any scheme or even lisp. i understand it is in beta, in your seasoned opinions do you think there is enough documentation on the net for me to learn as i go?
***exio4 is now known as y
***y is now known as hacker
***hacker is now known as init
***init is now known as exio4
<rekado>gibal: there's a pretty comprehensive manual included with Guix. I suggest reading/skimming the manual first.
<rekado>mark_weaver: thanks for merging the gtk-path-patch branch!
<gibal>thank you, think im going to give it a try today, i usually use slackware - great thing about it not being update for ages is any problems ive ran into someone else has already asked about it and had the question answered! guess a manual is the same thing but all in one place
<jubalh>Can somebody tell me how I can contribute to the git repo? I am used to GitHub and it's pull requests. how does it work on savannah?
<civodul>but it's interesting because by leaving so many degrees of freedom, their "distro" provides very few guarantees
<rekado>Recently I've been wishing for a little script that prepares a container with packages from the store linked to "expected" locations that would allow the user to run pre-built software for other distributions.
<rekado>(maybe this already works with "guix environment" and an explicit list of packages)
<rekado>but I suspect it's an issue with the board's firmware rather than the compiler I built.
<rekado>Today I updated a terrible piece of software at work and I even wished they provided a Docker image rather than this mess: bundled JDK, Mono for F#, Scala, Python, Perl, libgcc, libfortran, tons of Python packages such as scipy, Tomcat, ... and more.
<lfam>I'm trying to apply a bunch of patches to w3m. Some of then have a prefix of -p1 and other -p0. Is there a way to specify (patch-flags) multiple times?
<mark_weaver>lfam: no, sorry. the patches will need to be modified to all use the same -pN flag
<lfam>Hmm, I don't like this path. We are going to end up doing our own amount of non-trivial development trying to keep on top of all the important patches. I'm hoping that the old w3m authors declare the project abandoned so we can just use the Debian fork.
<rekado>sneek: later tell civodul I'm using the exact same SVN revision and branch of GCC as the binary declares to have used. But I'll again compare the tarball with the SVN checkout to see if there's anything else that needs patching.
<lfam>Guest65701: Almost! Make the title start with "doc:" and end with a period, as in commit daa8922abc. Usually, you also name the manual section where the changes are made, but since this is just correcting typos throughout the manual, I don't think that's necessary.
<lfam>So, just change the title. Listing all the occasions is not necessary here, in my opinion.
<Guest65701>lfam: oh my problem was that i looked at commit db5a94445f3b21b307c73ea72ed495bda891ef28
<lfam>In that commit, the changes to the docs are just describing the changes in the `guix package` code. They are not the focus of the changes so they don't get top billing
<sneek>civodul, rekado says: I'm using the exact same SVN revision and branch of GCC as the binary declares to have used. But I'll again compare the tarball with the SVN checkout to see if there's anything else that needs patching.
<rekado>no difference between the GCC sources; but the binutils sources probably do differ.
<rekado>I wonder if it wouldn't be best for me to use the tarball of source tarballs for this toolchain, rather than fetching from SVN and git directly.