IRC channel logs


back to list of logs

<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>I found at least one other person that has had this problem
<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>Also there are more issues with packaging inspekt3d in nixpkgs, here is more info for anyone interested
<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.
<gagbo>wasamasa wrote a little snippet that can act as a good starting point for a test suite :
<dsmith-work>Hey Hi Howdy, Guilers
<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
<rekado_>GewaltDisney: this is the latest Guile wip-elisp branch I’m using:;a=log;h=refs/heads/wip-elisp
<GewaltDisney>sweet thank you rekado
<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!
<GewaltDisney>thanks guys
<GewaltDisney>i'll be back when i have some updates
<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: oh 3.0.4, that's great!
<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>is guile 3 better 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
<davexunit>of course :)
<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
<leoprikler>Ah, yes, cygwin has guile 3.
<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>based on chickadee?
<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.
<leoprikler>Why not just `guix pack` a docker container? :D
<davexunit>won't work well on windows or macos
<davexunit>and the user would need docker
<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.
<leoprikler>See renpy and node-webkit.
<davexunit>I don't like it, but it's the way it is.
<davexunit>binary bundles are just the convenient option, not the sole means of distribution.
<leoprikler>How about using a CI to do that, though?
<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
<spk121>davexunit: this monstrosity was my build script to package up a win32 guile game for some jam a few years ago...
<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>ah, okay.
<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>I'm hopeful that all that you need is to add the fastcall patch from
<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.
<davexunit>got it.
<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>pthreads are pretty commonly used
<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?
<davexunit>^ if anyone else knows, chime in.
<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?
<leoprikler>I don't think dll.a is something that exists
<leoprikler>.dll is roughly equal to .so
<davexunit>right I know that
<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
<leoprikler>tbf i know nothing about cygwin
<davexunit>join the club :)
<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
<davexunit>spk121: thanks for the explanation
<davexunit>I don't understand what I'm doing wrong.
<spk121>they are used at link time
<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
<davexunit>so I guess I have to ignore that on windows
<davexunit>libraries in /usr/bin? what a world.
<davexunit>thanks I'll take another stab at it
<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
<leoprikler>Does the lib.a refer to this file?
<leoprikler>If so you could add a --cygwin switch
<leoprikler>[and then parse the lib.a]
<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>I tried but it didn't work
<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>so ends another windows build adventure.
<leoprikler>how does renpy do it then?
<davexunit>leoprikler: probably a more native build?
<davexunit>I really have no idea
<leoprikler>Yep, Visual Studio
<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>I think it would get hairy pretty quickly.
<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?
<leoprikler>Okay, but how do you package WSL for a game? ;)
<davexunit>civodul: hehe ;)
<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>WSL is near native or is native.
<davexunit>yes but there are some caveats
<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
<leoprikler>MinGW is lacking Guile 3 currently, though
<oni-on-ion>ah. guile sure does depend on many unixisms
<davexunit>lots of languages have native windows ports. python, ruby, common lisp (sbcl at least)
<davexunit>guile should too :)
<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>that's good news
<davexunit>just verified that libunistring has build instructions for msvc
<leoprikler>but what about gnulib?
<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