IRC channel logs

<Madsy>I'm getting a new weird error now when cross-compiling guile with posix threads

<Madsy> https://gist.github.com/Madsy/9298910

<Madsy>Not sure what's going on, but gc.h might be cached, and I recently reinstalled the library

<dje42>guile is providing its own implementation of somebody else's function, and defining it to be static, which conflicts with the decl in the header.

<dje42>My first guess is that Guile should use a different name since it's making the function static.

<Madsy>No, it's GC_set_finalizer_notifier, which is only provided by guile when HAVE_GC_SET_FINALIZER_NOTIFIER is not set

<dje42>Right.

<dje42>So there should be another condition in scm_init_finalizers that uses the differently named function in the !HAVE_GC_SET_FINALIZER_NOTIFIER case.

<dje42>Or just not define the function at all since it's a one-liner.

<dje42>(and its address isn't being passed to anyone)

<Madsy>The question is, why doesn't config.h set this #define all of a sudden

<dje42>Blech, $libgc/misc.c is a morass of conditional compilation.

<dje42>In your libgc build, can you "nm misc.o | grep GC_set_finalizer_notifier" ?

<dje42>[or just do it on the installed libgc of course]

<Madsy>Ah, the check for set_finalizer_notifier failed at ./configure time because the test didn't link in pthreads

<Madsy>As I said, -pthreads doesn't work :(

<Madsy>I can probably trick the tests by setting -lpthreads in LDFLAGS

<dje42>Still, you did find a bug: finalizer.c shouldn't provide its own GC_set_finalizer_notifier like that.

<dje42>1/2 :-)(

<Madsy>So --enable-threads=windows does indeed do the right thing

<Madsy>It tries different pthread implementations with -l instead of the compiler flag, or depend on implicit linking to pthreads

<dje42>Ah. --enable-threads when configuring libgc needs something different. Note to self: remember there's a difference.

<Madsy>Argh.. I can't fix the linking issue with LDFLAGS because LDFLAGS is added *before* all the other implicit libs

<Madsy>So -lpthread -lgc is the wrong order

*Madsy pulls his hair

<dje42>Yeah.

<dje42>Use LIBS instead of LDFLAGS?

<Madsy>If configure uses that. I'll give it a go

<Madsy>What the heck.. the linking is done in the right order, but ld doesn't find symbols that should be exported

<Madsy>Ah, I see now. I forgot to compile libgc with -DPTW32_STATIC_LIB

<Madsy>Damn dllexport craziness

<Madsy>There we go

<Madsy>I might compile win32 pthreads as shared just to save some space

<Madsy>Ok.. using posix threads for libgc and guile did not work. Guile just hangs

<Madsy>I might try compiling pthreads as a shared library

<dje42>IWBN to attach gdb and see where it hangs.

<Madsy>I got some output in GDB all of a sudden. It compiles all the modules, but they all fail for some reason

<Madsy>And afterwards it gets stuck in a thread

<Madsy>dje42: Also gdb on Windows is a sad affair. Ctrl-C interrupt in GDB quits the debugger instead of breaking

<dje42>Ouch.

<mark_weaver>Madsy: Guile can only use posix threads

<mark_weaver>I guess that one of the gnulib modules I recently imported pulled in gnulib's thread module.

<mark_weaver>so libgc will have to be configured to use posix threads

<Madsy>mark_weaver: I tried posix threads (W32 pthread which I had built statically) but guile just hanged then

<Madsy>mark_weaver: So I'm trying to rebuild the windows pthread library as a shared library now

<Madsy>Maybe that'll work better

<dje42>I still keep forgetting != doesn't exist.

<Madsy>Argh.. I think I give up for today

<Madsy>Threading does simply not work on Windows yet

<dje42>Sometimes I think "I really should set up a build environment for mingw (I run windows7 in vmplayer in order to use lightroom)." Then I think "Naaaaaa......." :-)

<Madsy>;-)

<Madsy>Ok, wishlish for Windows on guile 2.0: 1.) Threads 2.) Sockets 3.) Working run-server and spawn-server

<Madsy>wishlist*

<Madsy>Ok, when compiling guile and libgc with pthreads-win32 from https://www.sourceware.org/pthreads-win32/, guile gets stuck in ntdll!RtlExitUserThread

<didi>Is it possible to know if I'm running from a REPL?

<cluck>:)

<Madsy>hey cluck

<cluck>hi Madsy

<Madsy>I'm starting to think maybe this threading issue is a bug with mingw32 or w32-pthreads

<Madsy>64-bit support in w32-pthreads is shady

<Madsy>Weird.. the w32-pthread testsuite passed

<ijp>wingo: it's interesting you mentioned possibly eventually removing set-car!/-cdr! because I recently wrote http://shift-reset.com/blog/2014/2/28/List%20Mutation%20Public%20Service%20Announcement/

<ijp>I'd prefer check-then-iterate myself, but I suppose that was as obvious as the sun rising this morning

*didi approves the removal of mutable pairs

<didi>Not that it matters.

<taylanub>Wow, I didn't know reverse! could leave its argument in a state that's neither its original value nor the return value of the call. (Not that having it be either, randomly, is useful.)

<ijp>taylanub: presumably because you always used the return value like a good boy

<taylanub>Well there is nothing else to use, since the state of its argument is unspecified after the use. I just assumed it would be one or the other, for whatever reason.

<taylanub>BTW someone's asking about Guile/Emacs again on the ML .. bipt`: ping!

<Madsy>Does anyone have an idea what guile expects of pthread when it comes to exception handling? I'm doing my best to get threads to work on Windows.

<Madsy>And I built w32-pthreads without exception handling support. Could that explain why guile hangs?

<dje42>What does "exception handling support" mean in this context?

<Madsy>dje42: I'm unsure myself. There are different builds for w32-pthreads for with/without exception handling

<Madsy>Scroll down to library naming: https://github.com/GerHobbelt/pthread-win32

<Madsy>I'm not using that fork, I'm using the original library. But the README/explanation is the same for both.

<Madsy>dje42: I suppose it could be exception handling for C++ only?

<Madsy>With catch/throw

<dje42>That's my reading. It's c++ exceptions.

<Madsy>So compiling the pure C version should work then.

<Madsy>The w32-pthreads testsuite passes, except for a test that requires openmp. So I'm not sure what's wrong :(

<wingo>Madsy: did you build libgc with posix threads and did its test suite pass?

<Madsy>wingo: I did build libgc and guile with posix threads. I did not know libgc had a testsuite. I'll test that right away, thank you

<stis>evening guilers!

<Madsy>wingo: I need some advice. libgc has its own thread solution for Windows. Should I still build libgc with posix threads so that libgc and guile uses the same thread system?

<Madsy>I seem to have some issues with compiling the tests, but I'll probably get them working this evening

<Madsy>hey stis

<wingo>Madsy: yes, use the pthreads interface even on windows

<cluck>wingo: is there anyone working on getting guile to run on android?

<Madsy>cluck: Wow.. that sounds slow :D

<wingo>cluck: not that i know of, ask on the list though

<cluck>wingo: i was just curious. since gsoc is close it'd be a neat idea to get new people involved (i'm assuming guile already works on arm without major issues)

<Madsy>wingo: Any idea how I build libgc's testsuite when all it has is a test.am file?

<Madsy>It seems unfinished

<Madsy>That is, the ./tests directory has a testsuite, but I don't see an obvious way to build them

<dje42>.am == automake (presumably)

<wingo>Madsy: no idea, try a fresh checkout

<dje42>At least in 7.2, looks like they ran automake to get ./Makefile.in, but didn't run automake in tests/

<dje42>Plus ./configure.ac doesn't generate tests/Makefile. Hmmm...

<Madsy>dje42: Yes, exactly

<dje42>Easy enough to hack around (theoretically :-)).

<Madsy>I really suck at using the autotools. I know my way around invoking ./configure and doing cross-compilation, but that's it

<Madsy>For my own projects I use CMake, for better or worse

<dje42>Oh, interesting. ./Makefile.am includes tests/tests.am.

<Madsy>dje42: Any idea what the target is?

<dje42>What happens if you type "make check".

<dje42>That's the conventional entry point for running the tests.

<Madsy>dje42: Ah, that did it. Thanks.

<Madsy>Now I just have to run that on Windows

<Madsy>wingo: I ran all the libgc test, and they passed

<Madsy>tests*

<Madsy>Here's how I build libgc and guile. If anyone notice something obvious I've missed, I would love to know https://gist.github.com/Madsy/9312506

<Madsy>It's libgc 7.2a and the latest guile-2.0.9.219-e1bb-dirty release

<dje42>7.2e is the latest stable 7.2 release (IIUC). I'd check what the differences are b/w 7.2a and 7.2e.

<Madsy>dje42: Derp, sorry, I mean e.

<dje42>Ah.

<taylanub>7.4 is released too, counts as stable, but 7.2e has higher stability guarantees from what I understand.

<Madsy>The ./configure tests for _GC_pthread_exit, _GC_pthread_cancel, _GC_pthread_sigmask fail. The tests for _pthread_attr_getstack, _pthread_getattr_np, _pthread_get_stackaddr_np, _pthread_attr_get_np, _pthread_sigmask also fail. Is that significant?

<wingo>heya civodul :)

<civodul>howdy wingo!

<cluck>civodul: guix seems to be picking some steam lately, lots of new faces on #hurd. congrats :D

<civodul>cluck: cool :-)

<civodul>Guix or the Hurd is picking steam? ;-)

<civodul>Madsy: did you have a chance to try that patch for c-tokenize?

<cluck>civodul: err... both?! (afaiu they were trying to package hurd as nix/guix package/system)

<cluck>civodul: (and by lots i'm using hurd units of measure, i mean 2, maybe 3 people. i assumed you knew them because your nick came up on the chat log)

<civodul>heh, yeah :-)

<Madsy>civodul: No, not yet. I'm busy getting threads to work on Windows. Which is easier said than done

<civodul>i can imagine ;-)

<Madsy>civodul: Any idea what could be wrong? Both the w32-pthread and libgc tests pass, but guile built with MT support and thread features hangs in RtlExitUserThread

<Madsy>I'm doing a last ditch effort to use w32-pthreads as a shared DLL instead of linking statically. After that I'm out of ideas

<civodul>no idea

<Madsy>There's a slight bug with the configure script. Some checks link with pthread and some don't. So since libgc depends on pthread, the checks like GC_set_finalizer_notifier fails

<Madsy>I can set LIBS or LDFLAGS, but then some tests (and the final executable) links to pthreads twice

<dsmith>Howdy Guilers

<Madsy>hey dsmith

<dsmith>Aww. What happened to sneek?

IRC channel logs

2014-03-02.log