Bug 64619

Summary: Error building gcc 3.4 from ports collection
Product: Ports & Packages Reporter: Charlie & <root>
Component: Individual Port(s)Assignee: Gerald Pfeifer <gerald>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Charlie & 2004-03-23 14:10:11 UTC 
	When attempting to build the new gcc v 3.4, from the ports-collection, 
	it dies with this output:

	`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c: In function `fibheap_union':
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c:166: warning: implicit declaration of function `free'
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c: In function `fibheap_delete_node':
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c:285: error: `LONG_MIN' undeclared (first use in this function)
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c:285: error: (Each undeclared identifier is reported only once
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c:285: error: for each function it appears in.)
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c: In function `fibheap_consolidate':
	../.././..//gcc-3.4-20040310/libiberty/fibheap.c:395: warning: implicit declaration of function `memset'
	gmake[2]: *** [fibheap.o] Error 1
	gmake[2]: Leaving directory `/usr/ports/lang/gcc34/work/build/i386-portbld-freebsd5.2/libiberty'
	gmake[1]: *** [all-target-libiberty] Error 2
	gmake[1]: Leaving directory `/usr/ports/lang/gcc34/work/build'
	gmake: *** [bootstrap-lean] Error 2
	*** Error code 2

	Stop in /usr/ports/lang/gcc34.
	
	seemingly there are also other compile errors in /libiberty/, such as 'implicit declaration of function' type
	warnings, where various methods from stdlib is unavailable. Also the LONG_MIN is actually defined in a file
	which IS being included. (can't say it actually gets the file included, because the screen flies by so fast..)

	steffen [at] schumacher  [dot] denmark

Fix: 

Don't really know too much about gmake and make, but it seems like it doesn't get in config.h file
	properly included. This would explain why the include of stdlib.h fails (its wrapped in a HAVE_STDLIB_H 
	statement..)
How-To-Repeat: 	cd /usr/ports/lang/gcc34 ; make
Comment 1 Tilman Keskinoz freebsd_committer freebsd_triage 2004-04-25 14:20:23 UTC 
Responsible Changed
From-To: freebsd-i386->gerald

Over to maintainer
Comment 2 Gerald Pfeifer freebsd_committer freebsd_triage 2004-04-26 08:49:53 UTC 
State Changed
From-To: open->closed

This report is not against the current version of this port, which seems 
to build fine.  Plus, are you sure this is not caused by global setting 
of yours where you set these GCC flags?
Comment 3 quinot 2004-06-23 17:19:27 UTC 
I think the problem does not show when building under -CURRENT (as
gerald noted), but on the other hand I observed it with 5.2.1-REL.
A work-around might be to build the port with -DNO_CPU_CFLAGS.
This prevents bsd.cpu.mk from adding -mcpu=pentiumpro to the CFLAGS,
which would otherwise confuse the stage1 cpp and make it believe that
none of the standard system headers exist when configuring libiberty.

I am testing this workaround right now, and will send a followup.

Thomas.
Comment 4 quinot 2004-06-24 09:31:46 UTC 
I confirm that using -DNO_CPU_CFLAGS allowed a clean build of gcc34.