Re: Guile with win32 cross compiling
Hi Volker, Thanks for the report. On Tue 17 May 2011 01:01, Volker Grabsch writes: > "fix-include-error-in-gen-scmconfig.patch" > The patch re-introduces a change which I already proposed > in my last patch: You can't use $(AM_CPPFLAGS) for the native > build, because it adds "-I../lib" which means that > is taken from the local GNU-lib installation. The problem is > that the GNU-lib in "lib/" has been configured for MinGW, not > for the native system. So it performs some fixes which don't > work on non-MinGW systems, leading to strange, unhelpful error > messages. It took me quite some time to figure this out, mostly > because I thought that this should have already been fixed. H! Yes, sorry for overlooking this part of your patch. After thinking for a while about it I agree with you. I modified your patch to add a comment. > "remove-mingw-ifsock.patch" > This patch fixes an issue that also appears on native MinGW > build, because _S_IFSOCK simply isn't defined there. Note that > this issue was already reported, but hasn't been fixed up to > now, at least not in the stable-2.0 branch: > http://lists.gnu.org/archive/html/guile-devel/2011-01/msg00183.html I'll look at this when I'm back on the internet. > CC net_db.lo > net_db.c:460:1: error: 'AI_ALL' undeclared here (not in a function) > net_db.c:460:1: error: expression in static assertion is not an integer > net_db.c:482:33: warning: 'struct addrinfo' declared inside parameter list > [enabled by default] If your target does not have e.g. struct addrinfo, because it does not have IPv6, then you need to configure with ac_cv_type_struct_addrinfo=no. Check your config.log. Or should this be working somehow? There are other ac_cv_* for getaddrinfo and other routines. Happy hacking, Andy -- http://wingolog.org/
Re: Guile with win32 cross compiling
Hello Andy, thanks for the quick reply and for accepting and cleaning up my patches so far. Andy Wingo schrieb: > > CC net_db.lo > > net_db.c:460:1: error: 'AI_ALL' undeclared here (not in a function) > > net_db.c:460:1: error: expression in static assertion is not an integer > > net_db.c:482:33: warning: 'struct addrinfo' declared inside parameter list > > [enabled by default] [...] > If your target does not have e.g. struct addrinfo, because it does not > have IPv6, then you need to configure with > ac_cv_type_struct_addrinfo=no. Check your config.log. Or should this > be working somehow? > > There are other ac_cv_* for getaddrinfo and other routines. Okay, so I'm trying to get along without this ugly "ac_cv_type_struct_addrinfo" hack, hoping that the following error report will be more useful to you. 1) My first attempt is to enable threads via: ./configure --host=i686-pc-mingw32 --disable-shared --with-threads LIBS='-lunistring -lintl -liconv' This leads to the attached (compressed) config.log: config.log.with-threads.bz2 Make stops at this point: --- CC libguile_2.0_la-threads.lo threads.c: In function 'to_timespec': threads.c:245:15: error: dereferencing pointer to incomplete type threads.c:246:15: error: dereferencing pointer to incomplete type threads.c:253:15: error: dereferencing pointer to incomplete type threads.c:254:15: error: dereferencing pointer to incomplete type threads.c: In function 'launch_thread': threads.c:974:3: warning: implicit declaration of function 'GC_pthread_detach' [-Wimplicit-function-declaration] threads.c: In function 'scm_call_with_new_thread': threads.c:1009:3: warning: implicit declaration of function 'GC_pthread_create' [-Wimplicit-function-declaration] threads.c: In function 'scm_join_thread_timed': threads.c:1188:18: error: storage size of 'ctimeout' isn't known threads.c:1188:18: warning: unused variable 'ctimeout' [-Wunused-variable] threads.c: In function 'fat_mutex_lock': threads.c:1408:41: error: dereferencing pointer to incomplete type threads.c:1409:36: error: dereferencing pointer to incomplete type threads.c:1410:43: error: dereferencing pointer to incomplete type threads.c: In function 'scm_lock_mutex_timed': threads.c:1442:18: error: storage size of 'cwaittime' isn't known threads.c:1442:18: warning: unused variable 'cwaittime' [-Wunused-variable] threads.c: In function 'scm_try_mutex': threads.c:1476:18: error: storage size of 'cwaittime' isn't known threads.c:1476:18: warning: unused variable 'cwaittime' [-Wunused-variable] threads.c: In function 'scm_unlock_mutex_timed': threads.c:1619:18: error: storage size of 'cwaittime' isn't known threads.c:1619:18: warning: unused variable 'cwaittime' [-Wunused-variable] threads.c: In function 'scm_timed_wait_condition_variable': threads.c:1723:18: error: storage size of 'waittime' isn't known threads.c:1723:18: warning: unused variable 'waittime' [-Wunused-variable] threads.c: In function 'scm_pthread_cond_timedwait': threads.c:1924:3: warning: passing argument 3 of 'pthread_cond_timedwait' from incompatible pointer type [enabled by default] /home/vog/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include/pthread.h:1069:31: note: expected 'const struct timespec *' but argument is of type 'const struct scm_t_timespec *' --- 2) My second attempt is to build without threading: This leads to a slightly different config.log which I also attached: config.log.without-threads.bz2 Make then stops at the same point with just a few less error messages: --- CC libguile_2.0_la-threads.lo threads.c: In function 'to_timespec': threads.c:245:15: error: dereferencing pointer to incomplete type threads.c:246:15: error: dereferencing pointer to incomplete type threads.c:253:15: error: dereferencing pointer to incomplete type threads.c:254:15: error: dereferencing pointer to incomplete type threads.c: In function 'scm_cancel_thread': threads.c:1124:7: warning: statement with no effect [-Wunused-value] threads.c: In function 'scm_join_thread_timed': threads.c:1188:18: error: storage size of 'ctimeout' isn't known threads.c:1188:18: warning: unused variable 'ctimeout' [-Wunused-variable] threads.c: In function 'fat_mutex_lock': threads.c:1408:41: error: dereferencing pointer to incomplete type threads.c:1409:36: error: dereferencing pointer to incomplete type threads.c:1410:43: error: dereferencing pointer to incomplete type threads.c: In function 'scm_lock_mutex_timed': threads.c:1442:18: error: storage size of 'cwaittime' isn't known threads.c:1442:18: warning: unused variable 'cwaittime' [-Wunused-variable] threads.c: In function 'scm_try_mutex': threads.c:1476:18: error: storage size of 'cwaittime' isn't known threads.c:1476:18: warning: unused variable 'cwaittime' [
Re: Guile with win32 cross compiling
Volker Grabsch writes: > 1) My first attempt is to enable threads via: Just to remind you that we have an automated working mingw cross build setup here https://github.com/janneke/gub with guile-specific recipe and patches up at https://github.com/janneke/gub/blob/guile-2.0/gub/specs/guile.py https://github.com/janneke/gub/tree/guile-2.0/patches Jan Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: Guile with win32 cross compiling
On Fri 20 May 2011 14:48, Jan Nieuwenhuizen writes: > Volker Grabsch writes: > >> 1) My first attempt is to enable threads via: > > Just to remind you that we have an automated working mingw cross build > setup here > > https://github.com/janneke/gub Cool :-) Just to remind *you* that I have outstanding questions regarding your patches (3/5, 4/5, and 5/5) ;-) Cheers, Andy -- http://wingolog.org/
Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.
Andy Wingo writes: > I don't much like this approach. Besides mixing in a heuristic on all > machines that is win32-specific, it makes c:/foo.scm collide with > d:/foo.scm in the cache, and fails to also modify load.c which also does > autocompilation in other contexts. Yes, a newer version of this patch also includes load.c and boot-9.scm. Of course the drive letter should be kept. > Is anyone interested in implementing a path library? What's the status/estimate on this -- of course I agree this would be nicer, otoh, a patch to these three files is available that makes guile run on mingw right now. Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [PATCH 1/5] [mingw]: Add implementation of canonicalize_file_name.
Andy Wingo writes: > I read the thread and it looked like this patch was close to being > accepted Yes, it looks like that. My first simplistic patch to just make guile canonicalize_file_name work on mingw took my an hour to write and test. I spent four full working days arguing with gnulib of the necessity of the patch, writing tests, writing, talking, rewriting a new patch. It's my estimate that it will only take two to four working days to get this in gnulib. I'm not planning to do that without sponsoring, sorry. Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [PATCH 3/5] [mingw]: Do not export opendir, readdir etc., as dirents differ.
Andy Wingo writes: > If mingw defines variants of these routines, why are we not using them > directly? Good question. That may well be a better approach. Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.
Hi Jan, On Fri 20 May 2011 15:47, Jan Nieuwenhuizen writes: >> Is anyone interested in implementing a path library? > > What's the status/estimate on this -- of course I agree this would be > nicer, otoh, a patch to these three files is available that makes guile > run on mingw right now. Unclear :) I think the thing you did for your autobuilder was the right strategy for you and for lilypond, but that we can do even better in Guile if we give ourselves a bit of time. Andy -- http://wingolog.org/
Re: [PATCH 5/5] [mingw]: Use $LOCALAPPDATA as a possible root for cachedir.
Andy Wingo writes: >> * libguile/load.c (scm_init_load_path) [MINGW32]: Use $LOCALAPPDATA >> to avoid having a NULL cachedir, while still allowing override by >> using $XDG_CACHE_HOME. > > What sets LOCALAPPDATA? If it is the right thing on Windows then I am > OK with applying this patch. Asking google, it seems that this is a newer Windows versions thing. Quite probably using plain $APPDATA is better. Whether either one is the right thing on windows -- if there's even such a thing -- I really don't have a clue, you would need to ask a windows guru for that. Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [PATCH 4/5] [mingw]: Delete existing target file before attempting rename.
Andy Wingo writes: > This patch has the obvious race condition. Yes. > Why does the `rename' library routine not work on Win32? Good question. > The man page says > > CONFORMING TO >4.3BSD, C89, C99, POSIX.1-2001. > > so I am surprised about this behavior. Yes, that's interesting. Now what's broken here, the documentation, the implementation, some specific implementation, the one windows box that I tested on? Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [PATCH 1/5] [mingw]: Add implementation of canonicalize_file_name.
Hello Jan, On Fri 20 May 2011 15:56, Jan Nieuwenhuizen writes: > Andy Wingo writes: > >> I read the thread and it looked like this patch was close to being >> accepted > > Yes, it looks like that. Heh ;) > My first simplistic patch to just make guile canonicalize_file_name work > on mingw took my an hour to write and test. > > I spent four full working days arguing with gnulib of the necessity of > the patch, writing tests, writing, talking, rewriting a new patch. > > It's my estimate that it will only take two to four working days to get > this in gnulib. I'm not planning to do that without sponsoring, sorry. Understood. I have copied Bruno and the gnulib list for an update on what the status of this bug is, and what if anything is needed to fix canonicalize_path on mingw. The context: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/25451 I would appreciate it if Gnulib folk would have another look at this one. Thanks, Andy -- http://wingolog.org/
Re: Guile with win32 cross compiling
Jan Nieuwenhuizen schrieb: > https://github.com/janneke/gub/blob/guile-2.0/gub/specs/guile.py > https://github.com/janneke/gub/tree/guile-2.0/patches Thanks for pointing me to this project. This looks really promising and I would be glad for learning from that. 1) The pthread issue As far as I can see, you have patched libgc to support pthreads under MinGW. You forward-ported those patches from libgc-6.8 to 7.2, so I'm wondering why those patches didn't make it into upstream (i.e. the official libgc project) during that time. Are there any issues with those patches that I should know about? Also, have you actually offered these patches to upstream? If so, what's the URL to their bug tracker, or mailing list archive, where this issue has been discussed? I haven't been able to find any such information in neither the *.py file not the patch files. 2) The struct_timespec / ipv6 / etc. issues It seems that you solve those issues using an even uglier hack than I did. I'm wondering why it is necessary to manipulate the config.cache, as providing those variables as ./configure paramters worked quite well for me. Moreover, is this a sensible thing to do anyway? Shouldn't we try to fix the configure.ac to make it more portable and to make it properly detect those MinGW things in the first place? Greets, Volker -- Volker Grabsch ---<<(())>>---
Re: Indexing Scheme and C identifiers separately
David Pirotte writes: > Looking at 'Procedure Index', for example not really knowing what your > looking for > but presumably starting with letter 's', as a 'pure' scheme programmer, > reaching > scm-xxx, you'll have to hit more or less 33 times page down [depending on your > display and browser size obviously] to 'continue' with other 'scheme' indice > entries > [they may be other entries, at the beginning they are *scm_]. If you realize > you > probably have passed and missed the item you're looking for, you'll have to > hit 33 > times page-up ... not a big deal but it would be really nice to have 'per > language' > indices. > > If [and only if :-)] it can be easily done [which I assumed, but ...], i would > suggest the following [assuming a 'grouping' by language but i don't have a > problem > if it is by 'proc' 'var' and 'type' > > Indices > > . Concept Index > . Scheme Procedure Index > . Scheme Variable Index > . Scheme Type Index > . C Procedure Index > . C Variable Index > . C Type index > . R5RS Index I have supported this idea in the past, and I've recently taken a look at how it might be implemented. Unfortunately, I don't currently see a way of doing it. Unless the @deffns in the manual are restructured in some big way, it means that we'd need a @deffn command and one or more following @deffnx commands to generate entries in different indices. That appears to be not currently possible, and I've not managed to find any indication that it's even on Texinfo's radar. I'm happy to keep looking at this if people have other ideas about it; but at the moment I'm stuck. Regards, Neil
