From dm@home.dinoex.sub.org  Sun Mar 12 11:41:55 2000
Return-Path: <dm@home.dinoex.sub.org>
Received: from mail.dinoex.sub.org (mail.dinoex.sub.de [195.243.29.14])
	by hub.freebsd.org (Postfix) with ESMTP id AB4F637B8AC
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 12 Mar 2000 11:41:47 -0800 (PST)
	(envelope-from dm@home.dinoex.sub.org)
Received: (from uucp@localhost)
	by mail.dinoex.sub.org (8.9.3/8.9.3) with UUCP id UAA18200
	for FreeBSD-gnats-submit@freebsd.org; Sun, 12 Mar 2000 20:41:30 +0100 (CET)
Received: (from uucp@localhost)
	by net2.dinoex.sub.org (8.9.3/8.9.3) with UUCP id TAA05672
	for FreeBSD-gnats-submit@freebsd.org; Sun, 12 Mar 2000 19:09:25 +0100 (CET)
Received: (from dm@localhost)
	by home.dinoex.sub.org (8.9.3/8.9.3) id SAA92156;
	Sun, 12 Mar 2000 18:57:32 +0100 (CET)
Message-Id: <200003121757.SAA92156@home.dinoex.sub.org>
Date: Sun, 12 Mar 2000 18:57:32 +0100 (CET)
From: dirk.meyer@dinoex.sub.org
Sender: dm@home.dinoex.sub.org
Reply-To: dirk.meyer@dinoex.sub.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: devel/boehm-gc fails for www/w3m 3.4 STABLE
X-Send-Pr-Version: 3.2

>Number:         17344
>Category:       ports
>Synopsis:       devel/boehm-gc fails for www/w3m 3.4 STABLE
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jdp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 12 11:50:00 PST 2000
>Closed-Date:    Sat May 13 16:08:32 PDT 2000
>Last-Modified:  Sat May 13 16:11:22 PDT 2000
>Originator:     Dirk Meyer
>Release:        FreeBSD 3.4-STABLE i386
>Organization:
privat
>Environment:

	FreeBSD 3.4-STABLE #0: Sat Mar  4 11:43:51 CET 2000
	/usr/ports in sync with cvsup from 12.03.2000

>Description:

	compilation of w3m and w3m-ssl fails.
	after mktable is run.
	its output is trashed with control chars.

===>  Extracting for w3m-0.1.7
>How-To-Repeat:

	FreeBSD 3.4-STABLE #0: Sat Mar  4 11:43:51 CET 2000
	cd /usr/ports/www/w3m && make

>Fix:
	
	sorry, to deep for a quick fix form me.
	none so far.


>Release-Note:
>Audit-Trail:

From: John Polstra <jdp@polstra.com>
To: dirk.meyer@dinoex.sub.org
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: ports/17344: devel/boehm-gc fails for www/w3m 3.4 STABLE
Date: Wed, 15 Mar 2000 10:32:54 -0800 (PST)

 Could you please test this again with an up-to-date version of the
 boehm-gc port and let me know what happens?  I committed a change on
 11 March 2000 which might possibly fix the problem.
 
 Thanks,
 John
 

From: dirk.meyer@dinoex.sub.org (Dirk Meyer)
To: FreeBSD-gnats-submit@freebsd.org, jdp@polstra.com (John Polstra)
Cc:  
Subject: Re: ports/17344: devel/boehm-gc fails for www/w3m 3.4
	STABLE
Date: Wed, 15 Mar 2000 21:13:25 +0100

 Hi John Polstra,
 
 > Could you please test this again with an up-to-date version of the
 > boehm-gc port and let me know what happens?  I committed a change on
 > 11 March 2000 which might possibly fix the problem.
 
 As far as I can check it,
 my test included your latest patch.
 
 I used the current version,
 this is what cvsup.de.freebsd.org gave me:
 
 I haven't found a never version,
 but there might be a file missing or out of date?
 
 total 4
 drwxr-xr-x  2 dm  dm  512 Jul 29  1999 pkg/
 drwxr-xr-x  2 dm  dm  512 Nov 10 22:41 files/
 -rw-r--r--  1 dm  dm  711 Nov 10 22:41 Makefile
 drwxr-xr-x  2 dm  dm  512 Mar 12 08:21 patches/
 
 /src/ports/devel/boehm-gc/pkg:
 total 4
 -rw-r--r--  1 dm  dm  1107 Nov 16  1996 DESCR
 -rw-r--r--  1 dm  dm    56 Aug 12  1998 PLIST
 -rw-r--r--  1 dm  dm    59 Jun 26  1999 COMMENT
 
 /src/ports/devel/boehm-gc/files:
 total 1
 -rw-r--r--  1 dm  dm  60 Nov 10 22:41 md5
 
 /src/ports/devel/boehm-gc/patches:
 total 7
 -rw-r--r--  1 dm  dm  2061 Apr 20  1998 patch-ab
 -rw-r--r--  1 dm  dm   352 Aug  1  1999 patch-ac
 -rw-r--r--  1 dm  dm  2764 Mar 12 08:21 patch-aa
 
 kind regards Dirk
 
 - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
 - Tel. +49-5606-6512
 - Tel. +49-177-6923813
 
 -- 
 less: sendmail.cf may be a binary file. See it anyway?
 

From: John Polstra <jdp@polstra.com>
To: (Dirk Meyer) <dirk.meyer@dinoex.sub.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: ports/17344: devel/boehm-gc fails for www/w3m 3.4 STABLE
Date: Wed, 15 Mar 2000 21:24:22 -0800 (PST)

 Dirk Meyer wrote:
 > 
 >> Could you please test this again with an up-to-date version of the
 >> boehm-gc port and let me know what happens?  I committed a change on
 >> 11 March 2000 which might possibly fix the problem.
 > 
 > As far as I can check it,
 > my test included your latest patch.
 
 You are right -- my mistake.  I read the date 12.03.2000 in the P/R
 and my feeble American brain thought it saw December 3.
 
 In that case I wonder if my recent update broke the program.  Would
 you mind backing out my change and testing it?  To do that, replace
 "ports/devel/boehm-gc/patches/patch-aa" with revision 1.4 of that
 file.  In case you don't have a CVS repository, you can get revision
 1.4 from the web site at:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/boehm-gc/patches/patch-aa?rev=1.4
 
 Or, just edit your current patch-aa file and remove the string
 "-DREDIRECT_MALLOC=GC_malloc" from it.  That's the only change I made.
 
 To give you a little background:  The boehm-gc port originally was
 configured to replace malloc(), realloc(), calloc(), and free()
 directly with garbage-collected versions, so that all memory
 allocation calls would use the GC.  When the port was updated
 for a newer version of boehm-gc last year, the configuration was
 accidentally changed so that these functions were not overridden
 directly.  My patch a few days ago restored the original behavior.
 But it is possible that the w3m port relied on the accidental behavior
 from late last year.  If that is the case then my update probably
 caused the breakage.
 
 Regards,
 John
 

From: dirk.meyer@dinoex.sub.org (Dirk Meyer)
To: FreeBSD-gnats-submit@freebsd.org, jdp@polstra.com (John Polstra),
	nobutaka@nobutaka.com
Cc:  
Subject: Re: ports/17344: devel/boehm-gc fails for www/w3m 3.4
	STABLE
Date: Thu, 16 Mar 2000 08:55:36 +0100

 John Polstra wrote:
 > Could you please test this again with an up-to-date version of the
 > boehm-gc port and let me know what happens?  I committed a change on
 > 11 March 2000 which might possibly fix the problem.
 
 Dirk Meyer wrote:
 > As far as I can check it,
 > my test included your latest patch.
 
 John Polstra wrote:
 > In that case I wonder if my recent update broke the program.  Would
 > you mind backing out my change and testing it?
 
 I fetched the given URL and changed the patch-aa
 w3m and w3m-ssl seem to build without problem now.
 A quick test run showed no problem.
 
 How sould we solve this?
 Two diffrent ports of the library?
 
 I can see the benefit of having both memory-systems around.
 -> PR to mainter w3m/w3m-ssl ?
 Can the program be easyly changed to work with the option?
 
 kind regards Dirk
 
 - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
 - Tel. +49-5606-6512
 - Tel. +49-177-6923813
 

From: John Polstra <jdp@polstra.com>
To: (Dirk Meyer) <dirk.meyer@dinoex.sub.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: ports/17344: devel/boehm-gc fails for www/w3m 3.4 STABLE
Date: Thu, 16 Mar 2000 12:01:25 -0800 (PST)

 Dirk Meyer wrote:
 
 > I fetched the given URL and changed the patch-aa
 > w3m and w3m-ssl seem to build without problem now.
 > A quick test run showed no problem.
 
 Thanks for testing it!
 
 > How sould we solve this?
 > Two diffrent ports of the library?
 
 I am going to revert the change I made to patch-aa until a better
 solution can be found.
 
 John
 --
   John Polstra                                               jdp@polstra.com
   John D. Polstra & Co., Inc.                        Seattle, Washington USA
   "Disappointment is a good sign of basic intelligence."  -- Chgyam Trungpa
 
 
State-Changed-From-To: open->analyzed 
State-Changed-By: knu 
State-Changed-When: Tue Apr 25 21:53:38 JST 2000 
State-Changed-Why:  
A workaround had been made.  Groping for a nicer solution. 
Responsible-Changed-From-To: freebsd-ports->jdp 
Responsible-Changed-By: jseger 
Responsible-Changed-When: Wed May 10 15:06:25 PDT 2000 
Responsible-Changed-Why:  
jdp is the one who is "anaylizing" this  :-) 
State-Changed-From-To: analyzed->closed 
State-Changed-By: jdp 
State-Changed-When: Sat May 13 16:08:32 PDT 2000 
State-Changed-Why:  
This particular problem was fixed in revision 1.6 of 
"ports/devel/boehm-gc/patches/patch-aa".  I am not 100% satisfied 
with the current state of the boehm-gc port.  But that is a separate 
issue, and this PR can be closed. 
>Unformatted:
 >> Checksum OK for w3m-0.1.7.tar.gz.
 ===>   w3m-0.1.7 depends on file: /usr/local/lib/libgc.a - found
 ===>  Patching for w3m-0.1.7
 ===>  Applying FreeBSD patches for w3m-0.1.7
 ===>  Configuring for w3m-0.1.7
 ===>  Building for w3m-0.1.7
 [...]
 ./mktable 100 tagtable.tab > tagtable.c
 cc -O -pipe  -I/usr/local/include -I. -c tagtable.c
 tagtable.c:8: parse error before character 0340
 tagtable.c:11: parse error before character 0320
 tagtable.c:11: warning: initialization makes integer from pointer without a cast
 tagtable.c:17: `HTML_N' undeclared here (not in a function)
 tagtable.c:17: initializer element for `MyHashItem[12].value' is not constant
 tagtable.c:17: parse error before character 0370
 tagtable.c:22: `HTML' undeclared here (not in a function)
 tagtable.c:22: initializer element for `MyHashItem[17].value' is not constant
 tagtable.c:22: parse error before charactER 0220
 tagtable.c:24: `tfoot' undeclared here (not in a function)
 tagtable.c:24: initializer element for `MyHashItem[19].value' is not constant
 tagtable.c:24: parse error before `h'
 tagtable.c:30: `HTML_N_COLGcolgroup' undeclared here (not in a function)
 tagtable.c:30: initializer element for `MyHashItem[25].value' is not constant
 tagtable.c:41: parse error before `,'
 tagtable.c:41: warning: initialization makes integer from pointer without a cast
 tagtable.c:45: `HXg' undeclared here (not in a function)
 tagtable.c:45: initializer element for `MyHashItem[40].value' is not constant
 tagtable.c:45: parse error before character 07
 tagtable.c:49: parse error before character 0200
 tagtable.c:49: warning: initialization makes integer from pointer without a cast
 tagtable.c:55: `H0g' undeclared here (not in a function)
 tagtable.c:55: initializer element for `MyHashItem[50].value' is not constant
 tagtable.c:55: parse error before character 07
 tagtable.c:56: `HTML_E' undeclared here (not in a function)
 tagtable.c:56: `tbody' undeclared here (not in a function)
 tagtable.c:56: initializer element for `MyHashItem[51].value' is not constant
 tagtable.c:56: parse error before `HTML_N'
 tagtable.c:57: `HHh' undeclared here (not in a function)
 tagtable.c:57: initializer element for `MyHashItem[52].value' is not constant
 tagtable.c:57: parse error before character 07
 tagtable.c:69: `Hthead' undeclared here (not in a function)
 tagtable.c:69: initializer element for `MyHashItem[64].value' is not constant
 tagtable.c:91: `HTMLhf' undeclared here (not in a function)
 tagtable.c:91: initializer element for `MyHashItem[86].value' is not constant
 tagtable.c:91: parse error before character 07
 tagtable.c:94: `h' undeclared here (not in a function)
 tagtable.c:94: initializer element for `MyHashItem[89].value' is not constant
 tagtable.c:94: parse error before character 07
 tagtable.c:105: `HTML_N_ST' undeclared here (not in a function)
 tagtable.c:105: initializer element for `MyHashItem[100].value' is not constant
 tagtable.c:105: parse error before character 0270
 tagtable.c:106: `HTML' undeclared here (not in a function)
 tagtable.c:106: initializer element for `MyHashItem[101].value' is not constant
 tagtable.c:106: parse error before `g'
 tagtable.c:112: `HHh' undeclared here (not in a function)
 tagtable.c:112: initializer element for `MyHashItem[107].value' is not constant
 tagtable.c:112: parse error before character 07
 tagtable.c:118: `HTML_THEA' undeclared here (not in a function)
 tagtable.c:118: initializer element for `MyHashItem[113].value' is not constant
 tagtable.c:118: parse error before character 0250
 *** Error code 1
 
 Stop.
 
 Trying to run test in /usr/ports/devel/boehm-gc/work
 generates more than 50509425 bytes output ...
 
 ./setjmp_test
 This appears to be a I386 running FREEBSD
 Stack appears to grow down, which is the default.
 A good guess for STACKBOTTOM on this machine is 0xbfbfe000.
 Note that this may vary between machines of ostensibly
 the same architecture (e.g. Sun 3/50s and 3/80s).
 On many machines the value is not fixed.
 A good guess for ALIGNMENT on this machine is 4.
 Generic mark_regs code may work
 ./gctest
 Switched to incremental mode
 Emulating dirty bits with mprotect/signals
 Leaked composite object at 0x8079ffc (appr. size = 4)
 Leaked composite object at 0x8078fd0 (appr. size = 16)
 Leaked composite object at 0x8078fe0 (appr. size = 16)
 Leaked composite object at 0x8078ff0 (appr. size = 16)
 Leaked composite object at 0x8077ff8 (appr. size = 8)
 Leaked composite object at 0x807a000 (appr. size = 4)
 Leaked composite object at 0x807a004 (appr. size = 4)
 Leaked composite object at 0x807a008 (appr. size = 4)
 Leaked composite object at 0x807a00c (appr. size = 4)
 Leaked composite object at 0x807a010 (appr. size = 4)
 Leaked composite object at 0x807a014 (appr. size = 4)
 Leaked composite object at 0x807a018 (appr. size = 4)
 Leaked composite object at 0x807a01c (appr. size = 4)
 Leaked composite object at 0x807a020 (appr. size = 4)
 Leaked composite object at 0x807a024 (appr. size = 4)
 Leaked composite object at 0x807a028 (appr. size = 4)
 Leaked composite object at 0x807a02c (appr. size = 4)
 [....]
 Leaked atomic object at 0x8076000 (appr. size = 48)
 Leaked atomic object at 0x8076030 (appr. size = 48)
 Leaked atomic object at 0x8076060 (appr. size = 48)
 Leaked atomic object at 0x8076090 (appr. size = 48)
 [...]
 Leaked composite object at 0x80d8560 (appr. size = 16)
 Leaked composite object at 0x80d8570 (appr. size = 16)
 Leaked composite object at 0x80d8580 (appr. size = 16)
 Leaked composite object at 0x80d8590 (appr. size = 16)
 Leaked composite object at 0x80d85a0 (appr. size = 16)
 Leaked composite object at 0x80d85b0 (appr. size = 16)
 [...]
 
 I aborted after 946998 Lines ...
 
 
