Re: [RFU] (gcc-4.7.2-2 test) mpfr
Sorry, I made another mistake. Can the version in the setup.hint file for mpfr-debuginfo please be corrected to 3.1.2-1 (the release number is wrongly -2 at the moment)? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [RFU] (gcc-4.7.2-2 test) mpfr
On Apr 20 09:33, Achim Gratz wrote: Sorry, I made another mistake. Can the version in the setup.hint file for mpfr-debuginfo please be corrected to 3.1.2-1 (the release number is wrongly -2 at the moment)? No worries. Fixed on cygwin.com. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 19 22:27, Ken Brown wrote: On 4/19/2013 6:45 AM, Corinna Vinschen wrote: texlive texlive-collection-bibtexextra texlive-collection-binextra texlive-collection-latexextra texlive-collection-mathextra The 64-bit distro is still missing a few build dependencies for texlive: clisp libgd-devel libgs-devel libpoppler-devel libzzip-devel t1lib-devel Ok, so let's try to get these done in the next couple of days. Reini, any chance to have a look into porting clisp? Are there any dependencies missing? Volker, libgd, libgs and t1lib are yours, any chance to have a look into getting them built for 64 bit? libpoppler and libzzip are Yaakov's so I guess they are practically done ;) Aside from that, I'm about to do some traveling in which I will have only sporadic and limited internet access. So I probably won't be able to work on texlive until mid-May. Sorry. Same for me. I'm off-list the first two weeks of May. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
Op 19-4-2013 12:45, Corinna Vinschen schreef: Hi maintainers, the 64 bit Cygwin seems to be quite stable now. We're still suffering from a gcc problem which seems to affect C++ inline methods using templates, so some C++ packages might not be buildable yet(*), but other than that it looks pretty good. I would like to ask those of you owning a 64 bit Windows machine to have a look into the 64 bit distro and to try to build your packages. If dependencies are missing, please tell us here. We can look into fixing the missing deps together. If you have build problems other than due to missing deps, please report here, too. There are very likely still bugs in Cygwin and there might still lurk bugs in gcc. Just make sure that you eliminated problems in your project first. Datatype mismatches are pretty common bugs. Hi, Today I installed cygwin64 and had no problems. I only noticed that after I installed gcc-g++ 4.8.0 there was no 'cc' command available. I saw that dos2unix has already been ported to 64 bit. So I assume I don't need to take any action. I built them myself too to see if everything went fine. I saw no problems. I will build libunistring for 64 bit soon. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Re: [HEADSUP] Please try to build your packages for 64 bit
Op 19-4-2013 12:45, Corinna Vinschen schreef: Hi maintainers, the 64 bit Cygwin seems to be quite stable now. We're still suffering from a gcc problem which seems to affect C++ inline methods using templates, so some C++ packages might not be buildable yet(*), but other than that it looks pretty good. I would like to ask those of you owning a 64 bit Windows machine to have a look into the 64 bit distro and to try to build your packages. If dependencies are missing, please tell us here. We can look into fixing the missing deps together. If you have build problems other than due to missing deps, please report here, too. There are very likely still bugs in Cygwin and there might still lurk bugs in gcc. Just make sure that you eliminated problems in your project first. Datatype mismatches are pretty common bugs. If you have noarch packages (no binaries), please check if the dependencies for those packages are fullfilled and tell us here, too, so we can go ahead adding them to the 64 bit distro. Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: ImageMagick bash-completion cvsps dbus ghostscript libjbig-devel libjbig2 perl-Authen-SASL perl-DBD-SQLite perl-DBI perl-Net-SMTP-SSL subversion-perl terminfo-extra texlive texlive-collection-bibtexextra texlive-collection-binextra texlive-collection-latexextra texlive-collection-mathextra transfig w3m xemacs-emacs-common Hi, I need gperf for building libunistring. regards, Erwin Thanks in advance, Corinna (*) http://cygwin.com/ml/cygwin-developers/2013-04/msg00055.html http://cygwin.com/ml/cygwin-developers/2013-04/msg00056.html -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Re: [HEADSUP] Please try to build your packages for 64 bit
On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 Corinna Regards Marco
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 20 10:27, Erwin Waterlander wrote: Hi, I need gperf for building libunistring. I just uploaded a gperf package to the 64 bit release area. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
On Fri, Apr 19, 2013 at 6:45 AM, Corinna Vinschen wrote: ... Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: ... w3m ... Hi, I'm having trouble packaging 64-bit gc-7.2d libgc (upon which w3m depends). There are extensive 32-bit Cygwin adaptations to the upstream libgc code. After much trial and error it seems I lack the experience in Windows memory internals required to build a 64-bit port. I'll continue trying but in the interest of speed, at this point I would gladly turn over this 64-bit package to any volunteer. Bob
Re: [HEADSUP] Please try to build your packages for 64 bit
Hi Bob,
On Apr 20 11:24, Bob Heckel wrote:
On Fri, Apr 19, 2013 at 6:45 AM, Corinna Vinschen wrote:
...
Right now, we have a couple of missing dependencies in the 64 bit
distro. If one of the packages is yours, it would be nice if you could
try to build it. Here's the list of missing deps as of today:
...
w3m
...
Hi,
I'm having trouble packaging 64-bit gc-7.2d libgc (upon which w3m
depends). There are extensive 32-bit Cygwin adaptations to the upstream
libgc code. After much trial and error it seems I lack the experience in
Windows memory internals required to build a 64-bit port.
I'll continue trying but in the interest of speed, at this point I would
gladly turn over this 64-bit package to any volunteer.
I skimmed through the os_dep.c file and at first glance I only see
one problem:
# else /* CYGWIN32 */
/* An alternate version for Cygwin (adapted from Dave Korn's*/
/* gcc version of boehm-gc).*/
GC_API int GC_CALL GC_get_stack_base(struct GC_stack_base *sb)
{
extern void * _tlsbase __asm__ (%fs:4);
sb - mem_base = _tlsbase;
return GC_SUCCESS;
}
# endif /* CYGWIN32 */
This only works on i686, but not on x86_64. In theory, you could just
do something like this (x86_64 uses the %gs selector to point to the
Thread Environment Block, rather than %fs on i686, and the offset
reflects the different pointer size):
#ifdef __x86_64__
extern void * _tlsbase __asm__ (%gs:8);
#else
extern void * _tlsbase __asm__ (%fs:4);
#endif
But that's kind of dangerous, because the x86_64 gcc can optimize this
wrongly. We had this case in the 64 bit Cygwin as well at one point. I
suggest to change the above code to this target-independent expression:
extern void * _tlsbase = NtCurrentTeb()-Tib.StackBase;
If you have more strange problems, feel free to explain them here.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
cloog-ppl vs. cloog-isl
I've realized that both packages try to install /usr/share/info/cloog.info. Simply renaming the file doesn't work since the directory entry will be wrong. I could drop libcloog-ppl-doc and only provide this via libcloog-isl-doc or I'd have to patch the texinfo sources to change the directory entry. A third possibility is to offer libcloog-doc (since the info file makes no mention of the implementation details anyway) and always have that track the latest version we deliver for either libcloog-ppl or libcloog-isl. Please let me know if you have a strong preference for either solution. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 20 18:49, Corinna Vinschen wrote:
On Apr 20 11:24, Bob Heckel wrote:
I'm having trouble packaging 64-bit gc-7.2d libgc (upon which w3m
depends). There are extensive 32-bit Cygwin adaptations to the upstream
libgc code. After much trial and error it seems I lack the experience in
Windows memory internals required to build a 64-bit port.
I'll continue trying but in the interest of speed, at this point I would
gladly turn over this 64-bit package to any volunteer.
I skimmed through the os_dep.c file and at first glance I only see
one problem:
# else /* CYGWIN32 */
/* An alternate version for Cygwin (adapted from Dave Korn's*/
/* gcc version of boehm-gc).*/
GC_API int GC_CALL GC_get_stack_base(struct GC_stack_base *sb)
{
extern void * _tlsbase __asm__ (%fs:4);
sb - mem_base = _tlsbase;
return GC_SUCCESS;
}
# endif /* CYGWIN32 */
[...]
suggest to change the above code to this target-independent expression:
extern void * _tlsbase = NtCurrentTeb()-Tib.StackBase;
If you have more strange problems, feel free to explain them here.
I just found two more. include/gc.h uses __CYGWIN32__:
#ifdef __CYGWIN32__
/* Similarly gnu-win32 DLLs need explicit initialization from the */
/* main program, as does AIX. */
extern int _data_start__[], _data_end__[], _bss_start__[], _bss_end__[];
# define GC_DATASTART (_data_start__ _bss_start__ ? \
(void *)_data_start__ : (void *)_bss_start__)
# define GC_DATAEND (_data_end__ _bss_end__ ? \
(void *)_data_end__ : (void *)_bss_end__)
# define GC_INIT_CONF_ROOTS GC_add_roots(GC_DATASTART, GC_DATAEND); \
GC_gcollect() /* For blacklisting. */
/* Required at least if GC is in a DLL. And doesn't hurt. */
#elif defined(_AIX)
__CYGWIN32__ is extremly outdated, only kept for backward compatibility
on i686, and it's not defined anymore for 64 bit. Always use __CYGWIN__
instead.
However, the code in include/gc.h guarded by __CYGWIN32__ wouldn't work
on 64 bit anyway. All symbols need an additional underscore when
building on 64 bit Cygwin, due to the fact that under x86_64, symbols
are not prepended with an underscore, as on i686.
So the code should be changed to something along the lines of
#ifdef __CYGWIN__
/* Similarly gnu-win32 DLLs need explicit initialization from the */
/* main program, as does AIX. */
#ifdef __x86_64__
# define GC_DATASTART (__data_start__ __bss_start__ ? \
(void *)__data_start__ : (void *)__bss_start__)
# define GC_DATAEND (__data_end__ __bss_end__ ? \
(void *)__data_end__ : (void *)__bss_end__)
#else
# define GC_DATASTART (_data_start__ _bss_start__ ? \
(void *)_data_start__ : (void *)_bss_start__)
# define GC_DATAEND (_data_end__ _bss_end__ ? \
(void *)_data_end__ : (void *)_bss_end__)
#endif
# define GC_INIT_CONF_ROOTS GC_add_roots(GC_DATASTART, GC_DATAEND); \
GC_gcollect() /* For blacklisting. */
/* Required at least if GC is in a DLL. And doesn't hurt. */
#elif defined(_AIX)
Also, there's this block in include/private/gcconfig.h:
# if defined(__CYGWIN32__) || defined(__CYGWIN__)
# define I386
# define CYGWIN32
# define mach_type_known
# endif
This needs extending to handle the new CPU type:
# if defined(__CYGWIN__)
# if defined(__LP64__)
# define X86_64
# else
# define I386
# endif
# define CYGWIN32
# define mach_type_known
# endif
And ask upstream if it's really necessary...
# ifdef CYGWIN32
# define OS_TYPE CYGWIN32
... to call the OS CYGWIN32, despite the fact that it's not called
Cygwin32 but Cygwin since 1998 (15 years!). CYGWIN would make more
sense.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
Hi Marco, On Apr 20 10:43, marco atzeri wrote: On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 did you try to build anything of them yourself? Thx, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
cygport rpm-style
Hi Yaakov, as you know I have been using a modified version of cygport to make more extensive use of version-less cygport files and patches and to more generally allow the omission of the .cygport suffix on the command line. For want of a better word I've called these changes rpm-style. To avoid the clutter of sending patches to the list, please have a look at: (Browse) http://repo.or.cz/w/cygport/rpm-style.git (HTTP) http://repo.or.cz/r/cygport/rpm-style.git (GIT)git://repo.or.cz/cygport/rpm-style.git I am using this version to keep track of over 300 (mostly auto-generated) Perl Distribution packages and it's really making my workflow more efficient. I know you're having a different opinion and I concur that it probably doesn't matter for your workflow, but I hope you might reconsider your position. Also, there are some additional changes that keep downloaded files in a cache directory $DISTDIR and use files from that cache without copying them into the work tree, these patches should be more generally useful and I would ask you to accept them upstream. I can put them into a separate branch if you like. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
No cc command.
Op 20-4-2013 10:21, Erwin Waterlander schreef: Hi, Today I installed cygwin64 and had no problems. I only noticed that after I installed gcc-g++ 4.8.0 there was no 'cc' command available. I have in a Makefile: CC ?= gcc And this leads to an error: make: cc: Command not found. So when CC is by default set to cc on Cygwin64 there should be a cc command (like on Cygwin32). regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
libqhull-devel
Hi Marco, the includes are in /usr/include/libqhull on Cygwin, but all software using it I've found so far expects to find them in /usr/include/qhull instead. I've simply dropped a link on my system, but could you explain why you've chosen libqhull? Regards Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: No cc command.
On Apr 20 20:41, Erwin Waterlander wrote: Op 20-4-2013 10:21, Erwin Waterlander schreef: Hi, Today I installed cygwin64 and had no problems. I only noticed that after I installed gcc-g++ 4.8.0 there was no 'cc' command available. I have in a Makefile: CC ?= gcc And this leads to an error: make: cc: Command not found. So when CC is by default set to cc on Cygwin64 there should be a cc command (like on Cygwin32). Yes, known problem. cc is only missing for the time being. So far it was created by alternatives (to support gcc-3 vs. gcc-4 on 32 bit), but in future I guess we should simply create cc as symlink to gcc right in the gcc-core package. Just create the symlink manually for now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 20 20:28, Corinna Vinschen wrote: And ask upstream if it's really necessary... # ifdef CYGWIN32 # define OS_TYPE CYGWIN32 This entire ifdef CYGWIN32 block is in another block handling I386. It needs to be copied verbatim to the X86_64 block. This header file is a big mess! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: cloog-ppl vs. cloog-isl
On Apr 20 19:39, Achim Gratz wrote: I've realized that both packages try to install /usr/share/info/cloog.info. Simply renaming the file doesn't work since the directory entry will be wrong. I could drop libcloog-ppl-doc and only provide this via libcloog-isl-doc or I'd have to patch the texinfo sources to change the directory entry. A third possibility is to offer libcloog-doc (since the info file makes no mention of the implementation details anyway) and always have that track the latest version we deliver for either libcloog-ppl or libcloog-isl. #3 sounds good to me. However you do it, it might be preferable to get always the latest version of the docs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
On Sat, Apr 20, 2013 at 2:52 PM, Corinna Vinschen wrote: This entire ifdef CYGWIN32 block is in another block handling I386. It needs to be copied verbatim to the X86_64 block. This header file is a big mess! I couldn't agree more :) I thought I had it figured out a few times, adding CYGWIN64 as a new platform, etc. but it has surprised me more than once. It is including a win32 threads file at some point. Thanks for the assistance Corinna. Bob
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 20 15:29, Bob Heckel wrote: On Sat, Apr 20, 2013 at 2:52 PM, Corinna Vinschen wrote: This entire ifdef CYGWIN32 block is in another block handling I386. It needs to be copied verbatim to the X86_64 block. This header file is a big mess! I couldn't agree more :) I thought I had it figured out a few times, adding CYGWIN64 as a new platform, etc. but it has surprised me more than once. Just keep the CYGWIN32 define for both platforms. Look out for assumptions that something is 4 bytes where it might be 8 bytes now (long, pointers) and assumptions that CYGWIN32 is equivalent to I386 in CYGWIN32 bracketed code. That should get you a lot further. It is including a win32 threads file at some point. Yes, but it uses Cygwin-specific code in that file, using pthreads. That should still work, just have an eye on the datatype divergence: While the long/unsigned long datatype is 8 byte in 64 bit Cygwin (LP64(*)), they are 4 byte in native Windows (LLP64). Therefore the Windows datatypes DWORD, LONG, and ULONG are still 4 byte on x86_64. Using pointers to long where a pointer to LONG is expected will result in undefined behaviour. Thanks for the assistance Corinna. You're welcome. I'm through to a lot of the above in the meantime, so it makes sense to share this experience, I think. Corinna (*) http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Please try to build your packages for 64 bit
On 4/20/2013 8:29 PM, Corinna Vinschen wrote: Hi Marco, On Apr 20 10:43, marco atzeri wrote: On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 did you try to build anything of them yourself? no. I had no much time on last weeks Thx, Corinna
Re: [HEADSUP] Please try to build your packages for 64 bit
On Apr 20 22:29, marco atzeri wrote: On 4/20/2013 8:29 PM, Corinna Vinschen wrote: Hi Marco, On Apr 20 10:43, marco atzeri wrote: On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 did you try to build anything of them yourself? no. I had no much time on last weeks Yeah, never mind, just a question. It's quite certainly still a lot to do to get all the libraries up and running on x86_64. Lazy assumptions like in Bob's libgc are not really helpful... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: libqhull-devel
marco atzeri writes: upstream decision not mine on latest versions; for that reason on octave the qhull check is like this: OCTAVE_CHECK_LIB(qhull, QHull, [Qhull library not found -- this will result in loss of functionality of some geometry functions.], [libqhull/libqhull.h qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h], [qh_qhull], [], [], [warn_qhull= as you can see they changed the include 3 times from qhull/qhull.h - qhull/libqhull.h - libqhull/libqhull.h OK, thanks for the answer — the old new is the new old or something like that. I'll have to massage the CMake configury for the packages I was looking at to adjust their expectations in that case. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cloog-ppl vs. cloog-isl
On 2013-04-20 12:39, Achim Gratz wrote: I've realized that both packages try to install /usr/share/info/cloog.info. Simply renaming the file doesn't work since the directory entry will be wrong. I could drop libcloog-ppl-doc and only provide this via libcloog-isl-doc or I'd have to patch the texinfo sources to change the directory entry. A third possibility is to offer libcloog-doc (since the info file makes no mention of the implementation details anyway) and always have that track the latest version we deliver for either libcloog-ppl or libcloog-isl. cloog-ppl is deprecated, so I suggest shipping it only with cloog-isl. Yaakov
Re: No cc command.
On 2013-04-20 13:46, Corinna Vinschen wrote: Yes, known problem. cc is only missing for the time being. So far it was created by alternatives (to support gcc-3 vs. gcc-4 on 32 bit), but in future I guess we should simply create cc as symlink to gcc right in the gcc-core package. Just create the symlink manually for now. Fixed in git. Yaakov
Re: [HEADSUP] Please try to build your packages for 64 bit
On 2013-04-20 03:43, marco atzeri wrote: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 librsvg deps pango which deps harfbuzz, so we need to fix the C++ template issue first. Yaakov
Re: GCC-4.7.2-2: Go/No-go?
On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:32, Dave Korn wrote: On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: Your boehm-gc patch can replace my java-libgc-win32.patch, provided it works properly. It appears to, libjava testsuite results are as good as they've ever been, although I don't know whether or not the testsuite checks the invocation API. It's certainly the more complete approach to take than just not supporting the register/unregister methods, as confirmed by the fact that upstream boehm-gc has implemented it for Cygwin. There is a mistake in that patch. The DEBUG_CYGWIN_THREADS conditionals need to be if, not ifdef, as elsewhere in the same source file. Oops, that was a cut'n'paste error when I copied the skeleton of those functions from pthread_support.c, where #ifdef DEBUG_THREADS is the form to use. Thanks for spotting it; fixed in my repo ready for next release. cheers, DaveK
