boehm-gc .comm problem

Robert Collins
Mon Jun 4 19:50:00 GMT 2001

Might I suggest using pthreads? They are the official threads for

Whilst much of cygwin should operate correctly with win32 threads, it's
not guaranteed. 

The cygwin pthreads is a wrapper around win32 threads, not emulated
threads, so there is little-or-no-performance reason to go with win32


> -----Original Message-----
> From: Tony Kimball [ ]
> Sent: Tuesday, June 05, 2001 11:57 AM
> To:
> Cc:
> Subject: boehm-gc .comm problem
> Here's a ball of confusion that I'm hoping a reader can help me
> unwind.  I am inclined to blame the cygwin-target binutils gas for
> this problem.  However, I'd like to work-around this for the nonce by
> not using commons.  Questions: Would this be an ABI problem?  Am I on
> the right track in blaming gas?
> With a cygwin target, linux host, win32 threads, building boehm-gc,
> allchblk.c, I get stuff like this:
> 	.comm	_A, 16	 # 4
> 	.comm	_A, 32	 # 24
> 	.comm	_A, 16	 # 4
> which results in stuff like this:
>   /usr/home/alk/tmp/ccZeLBab.s: Assembler messages:
>   /usr/home/alk/tmp/ccZeLBab.s:4478: Error: Length of .comm 
> "_A" is already 16. Not changed to 32.
> which is inconsistent with this (gas texinfo):
>  .comm symbol , length   
>  .comm declares a named common area in the bss section. Normally
>  reserves memory addresses for it during linking, so no partial
>  program defines the location of the symbol. Use .comm to tell that
>  it must be at least length bytes long.  will allocate space for each
>  .comm symbol that is at least as long as the longest .comm request
>  in any of the partial programs linked. length is an absolute
>  expression.
> The target linux version does not emit any .comms.  My reasoning is
> that existing cygwin libs must use .comm in such 
> circumstances, in order to
> get consistent storage for globals.
> If anyone can recommend pertinent reading, I would be appreciative.

Want to unsubscribe from this list?
Check out:

More information about the Cygwin mailing list