gcc34 isn't buildable on 4.10
Valentin Nechayev
netch at lucky.net
Fri Jul 16 16:11:09 UTC 2004
Fri, Jul 16, 2004 at 14:26:02, gerald wrote about "Re: gcc34 isn't buildable on 4.10":
>> does anybody see this?
[...]
>> ../.././..//gcc-3.4-20040709/libiberty/fibheap.c:166: warning: implicit declarat
>> ion of function `free'
>> ../.././..//gcc-3.4-20040709/libiberty/fibheap.c: In function `fibheap_delete_no
>> de':
>> ../.././..//gcc-3.4-20040709/libiberty/fibheap.c:285: error: `LONG_MIN' undeclar
[...]
> I don't see this, but my 4.x tester is running 4.9-RELEASE-p5 right now;
> I do have some doubts that this should be due to the difference from 4.9
> to 4.10, though. It seems you have some additional options set?
Well, I've already found that unsetting of CFLAGS in /etc/make.conf
fixes building. The values of CFLAGS was:
(both 4.10 hosts)
CFLAGS= -O -pipe -march=i586 -mcpu=i686 -mpreferred-stack-boundary=2
(4.8 host with the same problem! hence it isn't special for 4.10)
CFLAGS= -O2 -pipe -mcpu=i686 -march=i486 -mpreferred-stack-boundary=2
The strangeness is seen in libiberty config log diffs for good variant
(without CFLAGS) and bad variant:
configure:3410: checking for sys/file.h
-configure:3424: /usr/ports/lang/gcc34/work/build/gcc/xgcc -B/usr/ports/lang/gcc
34/work/build/gcc/ -B/usr/local/gcc34-port/i386-portbld-freebsd4.10/bin/ -B/usr/
local/gcc34-port/i386-portbld-freebsd4.10/lib/ -isystem /usr/local/gcc34-port/i3
86-portbld-freebsd4.10/include -isystem /usr/local/gcc34-port/i386-portbld-freeb
sd4.10/sys-include -E -O2 conftest.c
+configure:3424: /usr/ports/lang/gcc34/work/build/gcc/xgcc -B/usr/ports/lang/gcc
34/work/build/gcc/ -B/usr/local/gcc34-port/i386-portbld-freebsd4.10/bin/ -B/usr/
local/gcc34-port/i386-portbld-freebsd4.10/lib/ -isystem /usr/local/gcc34-port/i3
86-portbld-freebsd4.10/include -isystem /usr/local/gcc34-port/i386-portbld-freeb
sd4.10/sys-include -E -O2 -O -pipe -march=i586 -mcpu=i686 -mpreferred-stack-boun
dary=2 conftest.c
+`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
configure:3430: $? = 0
-configure:3450: result: yes
+configure: failed program was:
+| #line 3416 "configure"
+| /* confdefs.h. */
+|
+| #define PACKAGE_NAME ""
+| #define PACKAGE_TARNAME ""
+| #define PACKAGE_VERSION ""
+| #define PACKAGE_STRING ""
+| #define PACKAGE_BUGREPORT ""
+| #define BYTEORDER 1234
+| /* end confdefs.h. */
+| #include <sys/file.h>
+configure:3450: result: no
configure:3410: checking for sys/param.h
-configure:3424: /usr/ports/lang/gcc34/work/build/gcc/xgcc -B/usr/ports/lang/gcc
34/work/build/gcc/ -B/usr/local/gcc34-port/i386-portbld-freebsd4.10/bin/ -B/usr/
local/gcc34-port/i386-portbld-freebsd4.10/lib/ -isystem /usr/local/gcc34-port/i3
86-portbld-freebsd4.10/include -isystem /usr/local/gcc34-port/i386-portbld-freeb
sd4.10/sys-include -E -O2 conftest.c
+configure:3424: /usr/ports/lang/gcc34/work/build/gcc/xgcc -B/usr/ports/lang/gcc
34/work/build/gcc/ -B/usr/local/gcc34-port/i386-portbld-freebsd4.10/bin/ -B/usr/
local/gcc34-port/i386-portbld-freebsd4.10/lib/ -isystem /usr/local/gcc34-port/i3
86-portbld-freebsd4.10/include -isystem /usr/local/gcc34-port/i386-portbld-freeb
sd4.10/sys-include -E -O2 -O -pipe -march=i586 -mcpu=i686 -mpreferred-stack-boun
dary=2 conftest.c
+`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
configure:3430: $? = 0
-configure:3450: result: yes
+configure: failed program was:
+| #line 3416 "configure"
+| /* confdefs.h. */
+|
+| #define PACKAGE_NAME ""
+| #define PACKAGE_TARNAME ""
+| #define PACKAGE_VERSION ""
+| #define PACKAGE_STRING ""
+| #define PACKAGE_BUGREPORT ""
+| #define BYTEORDER 1234
+| /* end confdefs.h. */
+| #include <sys/param.h>
+configure:3450: result: no
configure:3410: checking for limits.h
All previous tests in libiberty/config.log shows identical results
for both cases! Difference begins only from testing for <sys/file.h>.
And, not all following tests fail.
The third attempt was on 4.10 with the following CFLAGS:
CFLAGS= -O -pipe -march=i686
It bypassed the problematic place. So, is it -mpreferred-stack-boundary?
I'll retest as soon as possible.
-netch-
More information about the freebsd-ports-bugs
mailing list