<bsima>does anyone know how to tell guild to look for a shared lib in a non-standard path? <bsima>and if so, how do I hook that sort of thing into the usual ./configure workflow? <bsima>for context: I'm packaging inspekt3d for nixpkgs and it's failing to find libfive during the buildPhase <mwette>bsima: try LD_LIBARY_PATH=/path/to/lib guild compile foo.scm <bsima>mwette: thanks, i'm trying that but overwriting LD_LIBRARY_PATH just leads to other compilation errors <bsima> In procedure scm_lreadr: #<unknown port>:410:18: unknown character name ?? <bsima> make: *** [Makefile:768: inspekt3d/library.go] Error 1 <bsima>I'm looking for a way to prepend to the var in nix currently <mwette>can you do this? LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH <bsima>no the $ gets escaped, anyway i learned in #nixos that the correct way to do this is using the autoreconfHook functions they give you <bsima>has anyone seen 'unknown character name ??' when compiling guile code? <bsima>unfortunately it was not solved :) but it's the same library inspekt3d that i'm working on <daviid>bsima: the message tells you to lok at the specific line and column, identify what is the character there, and that, very liely, the guild process does not 'know' that character because it is being run under a 'wrong' locale ... you really have food for thought there ... <bsima>i found that adding glibLocales to buildInputs fixed that <bsima>i think the guile support in nixpkgs just needs a bit of work <ryanprior>Can you use define-public inside a let form? <ryanprior>My feeling is no, but maybe I'm just doing something wrong. ***apteryx is now known as Guest92284
***apteryx_ is now known as apteryx
***hugh_marera_ is now known as hugh_marera
<lloda>ryanprior: you can use define outside and export inside if that doesn't work <leoprikler>ryanprior: no, because you can't top-level (define ) inside a let IIRC <spk121>janneke: have you done any more work on guile mingw? <janneke>spk121: it depends, i have my work on gitlab: <janneke>that's all on top of "your" 2.2.3 branch <spk121>janneke: lol okay. I've been working on this again. Today I got a 3.0.4 to complete 'make check' with many many failures. But at least it ran to completion <spk121>janneke: you got an x86_64 mingw guile to work? If so, that's awesome! <GewaltDisney>hi everyone, i'm hoping to give Guile Emacs a try, but when trying to DL from guix it always gets stuck in the build phase. does anyone have any advice on this? <leoprikler>I don't know anything about getting stuck in the build phase, but Guile Emacs as a project has sadly collected a lot of dust and would need to be revitalized. <GewaltDisney>leoprikler: yes, it would be cool for this project to be revitalized, some folks in #emacs said that terpri was discussing crowdfunding it, so i've offered my ux/ui design skills to make a slick presentation if thats desired <GewaltDisney>ran through the guix install again in verbose and heres where it hits a snag if anyone is familiar <GewaltDisney>Generating /tmp/guix-build-guile-emacs-0.0.0-0.41120e0.drv-0/guile-emacs-0.0.0-0.41120e0-checkout/lisp/international/uni-name.el... <rekado_>GewaltDisney: I’ve got some WIP that at least lets the build pass. <rekado_>but the resulting Guile Emacs is very prone to segfaults, so there’s something I must have missed <civodul>you can try it with --with-git-url and --with-branch maybe <rekado_>I had started to rebase the Guile Emacs commits on top of the nearest Emacs release, but gave up half way through <rekado_>it may be easier to port the required changes “manually” <GewaltDisney>yeah, i'll probably give it a go for a few hours this weekend. its obviously a match made in heaven! <rekado_>GewaltDisney: if there’s any value in looking at my rebase attempts I’ll gladly make the mid-rebase state of my repository available for download <janneke>spk121: yes, guile 2.2 assumed that sizeof (long) == sizeof (void *) <janneke>which is true on all sane systems and breaks on mingw <davexunit>awhile back I tried using guix to build guile for mingw but the resulting binary never worked <janneke>guile 2.2 builds fine from my tree; it broke ootb after 2.0.9 or so <janneke>i haven't looked at spk121's 3.0.4 work yet <davexunit>a guile 3 build that worked on windows would be really great. <janneke>i'd much rather have people stop using windows, but yeah <leoprikler>I think there are some Guile 3 builds for windows out there <davexunit>I'd like to know how they were built so I can replicate it with guix <davexunit>that's promising. I should try it out sometime. <davexunit>if I could get that + builds of all the C libraries I use I just might be able to ship a game written in guile. <leoprikler>oh, i just now realized, there's a 0.6.0 release <davexunit>if I could cobble together a runtime base for chickadee games for linux, macos, and windows then it would make writing games in guile a lot more appealing. <davexunit>a tool could just combine the game's source, .go files, and assets with the various platform bases and bam, ready to ship. <davexunit>for games, anything more than "extract and run executable" is asking too much <leoprikler>I get that, but that mindset leads to some very questionable decisions. <davexunit>binary bundles are just the convenient option, not the sole means of distribution. <spk121>davexunit: I only just started playing with guile 3.0.x mingw yesterday. Largely the same patches as janneke has for 2.2 <spk121>so I've got nothing ready for inspection <davexunit>leoprikler: sure, but that seems orthogonal to the general topic? <davexunit>however you produce it, it's a big ol' binary bundle that can be dumped onto the target system <leoprikler>Well, sure, but in my opinion who produces those bundles does make a difference. <leoprikler>In the CI case, you get a machine running your target OS doing the job for you. <davexunit>I don't know how this turned into a debate or what we're debating <davexunit>spk121: wow. so this was run on a windows machine as opposed to being cross compiled from linux? <spk121>Yeah. On the mingw32 environment that msys2 provides <davexunit>does guile's jit work in a 32bit environment? <leoprikler>it should but I don't know about the specifics on windows where a 32bit binary is run on 64bit arch all of the time <spk121>davexunit: Guile 3.0.x jit on mingw doesn't work for me. But I've barely worked on it. <davexunit>yeah that's a blocker for me. I feel like I just don't know enough about windows/mingw to work through the issues. <davexunit>like I need to educate myself on the differences between mingw and cygwin, because apparently cygwin has a guile 3 build <spk121>davexunit: here's big difference. Cygwin maintains a bit library that emulates posix with win32 calls, so getting cygwin to run is easier. mingw links to directly to a Windows library, so you have to replace a lot of posix calls with win32 calls. For example, mingw doesn't have pthreads <davexunit>spk121: so does that mean that threads don't work when you build guile for mingw? <davexunit>I vaguely remember seeing a mingw pthreads library before. do you know about it? <spk121>davexunit: yes, so far, as far as I know, there is no mingw guile where threads work right. <spk121>I'm aware of mingw's winpthreads library, but last time I tried it with guile (and it has been some years) there was a difficult to debug crash. I suspected GC problems, but, never really ran it to ground <davexunit>makes me wonder how other programs deal with this? <davexunit>I guess cygwin is the direction I'd want to explore, then. <spk121>if you can figure out which DLLs you need to bundle up, cygwin could work. I can't say I've worked on Cygwin much beyond patching Guile for cygwin (and cygwin for Guile). <davexunit>spk121: do you happen to know if dynamic-link works in cygwin? <spk121>davexunit: yes, they dynamic-link test passes on cygwin <spk121>but, the difference is that on linux shared objects, you can link a top-level library and it will search recursively to other libraries. For DLLs, you need to dynamic link to the specific DLL to find a symbol. (If I recall correctly) <leoprikler>meaning you won't get glibc symbols from mylib.dll? <spk121>leoprikler: again going from memory, here, I think so <davexunit>I'm trying to compile my guile-sdl2 project and it fails to find libsdl2. the directory is correct, it's in /usr/lib. going to try something... <davexunit>(dynamic-link "/usr/lib/libSDL2") and (dynamic-link "/usr/lib/libSDL2.dll.a") fail <davexunit>what's up with the .a after the dll? in linux land that would mean it's a lib for static linking. is it the same here? <davexunit>I installed libwhatever packages with cygwin, so presumably that gives me the shared libs <davexunit>every single library file in /usr/lib is a .dll.a <leoprikler>interesting, perhaps that's a cygwin convention then <spk121>davexunit: the *.dll.a files contain the information that you need to link to a dll, they are like a table of contents for the DLL <spk121>You probably just need to add the directory where the actual DLLs live to you LTDL_LIBRARY_PATH or LD_LIBRARY_PATH. On cygwin this might be something like /usr/bin <davexunit>the pkgconfig files for the libraries say /usr/lib is the libdir <spk121>I'm probably giving you bad info, since I'm not sitting in front of a windows box <davexunit>spk121: weird! they are in /usr/bin but prefixed with "cyg" instead of "lib" <spk121>davexunit: oh right! Cygwin. Yeah dynamic link to "cygxxx.dll" <davexunit>spk121: for sdl2, I need to do this: (dynamic-link "/usr/bin/cygSDL2-2-0-0") <davexunit>now if I could figure out how to make my configure script figure this out... <davexunit>the pkg-config file doesn't refer to this file or /usr/bin at all <davexunit>it's a binary file that I don't know how to read <spk121>objdump -x libxxx.dll.a will tell you what's in it, mostly <davexunit>seems very complicated. this can't be how other people handle this. <spk121>just go with (or (dynamic-link "libsdl") (dynamic-link "cygsdl")) or something like that <davexunit>after hardcoding some library file names into the libraries I was building, I got everything to compile. <davexunit>unfortunately, sdl2 is unable to open a window. says there is no available video device. <davexunit>a quick search lead to discourse thread where someone says the cygwin sdl2 is broken <davexunit>if guile could just build on windows natively then it would be smooth sailing <davexunit>I'm just going to guess that it would be a ton of work otherwise someone would have done that by now <leoprikler>Perhaps not a ton, but probably still a decent amount. <davexunit>any parts that use pthreads would need an alternative implementation, for example. <civodul>i think nobody wrote the three magic letters: WSL <leoprikler>Is the only Windows implementation of pthreads in MinGW/Cygwin? <davexunit>WSL does not yet work well for graphical programs <davexunit>for optimal performance, a native port would be best. <oni-on-ion>hmm distro the libs in a kind of package, likely theres way <davexunit>but like... I'm not really a windows person. I just want to publish to windows. <oni-on-ion>a lot faster than Cygwin for sure (which is layers) and mingw is already itself as close to the "windows metal" as possible <davexunit>lots of languages have native windows ports. python, ruby, common lisp (sbcl at least) <civodul>to me, WSL means that "porting" is no longer a thing, or at least for non-graphical programs <civodul>(i know nothing about Windows but this time i take Microsoft's word :-)) <spk121>civodul: I think that is a fair statement. WSL works well. But, I think WSL makes cygwin obsolete. <davexunit>there's issues when it comes to graphical programs. those programs need to talk to an x server and the whole darn linux graphics stack. <davexunit>all this compatibility layering is no substitute for a native port. <davexunit>it's a problem of my own design but sometimes it sucks that everything I depend on compiles natively on windows... except guile. <civodul>yes, but, let's say you're a Guile maintainer, it's very tempting to say goodbye to Cygwin/MinGW and all, isn't it? :-) <oni-on-ion>ocaml still has some trouble as a windows port, from what i hear <davexunit>civodul: that would be the case with WSL and a native port :) <oni-on-ion>yeah dave, that X11 stuff can be quite heavy and is mostly the worst of it. not sure if wayland helps, but i can imagine non-issues with SDL or Raylib <civodul>can't you mix the POSIX/Linux/glibc API and the native graphical API? <oni-on-ion>well thing is, UNIX is essentially the C VM. just that most systems already come with all of it <civodul>"the C VM", that's very 2020 parlance, no? ;-) <davexunit>my fear is that it's not just guile that would need porting, probably some of the libraries do as well. <spk121>davexunit: sdl is maintained on windows, of course, as are all of Guile's dependencies <davexunit>spk121: libunistring, libgc, etc. can compile with msvc? <davexunit>just verified that libunistring has build instructions for msvc <spk121>leoprikler: gnulib is great when there is actually underlying win32 API that can be mapped to POSIX API. For some things, the models are so different that they don't sync up. But largely we're using gnulib already to provide missing functionality for mingw <spk121>as an aside, the gnulib that guile is using could use a refresh. There have been some decent bugfixes since it was last updated