[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-01-30 01:44:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-30 01:44:41 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-01-30 01:44:41 - cleaning the object tree TB --- 2011-01-30 01:44:57 - cvsupping the source tree TB --- 2011-01-30 01:44:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-01-30 01:46:11 - building world TB --- 2011-01-30 01:46:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-30 01:46:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-30 01:46:11 - TARGET=powerpc TB --- 2011-01-30 01:46:11 - TARGET_ARCH=powerpc64 TB --- 2011-01-30 01:46:11 - TZ=UTC TB --- 2011-01-30 01:46:11 - __MAKE_CONF=/dev/null TB --- 2011-01-30 01:46:11 - cd /src TB --- 2011-01-30 01:46:11 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 30 01:46:11 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Jan 30 03:18:46 UTC 2011 TB --- 2011-01-30 03:18:46 - generating LINT kernel config TB --- 2011-01-30 03:18:46 - cd /src/sys/powerpc/conf TB --- 2011-01-30 03:18:46 - /usr/bin/make -B LINT TB --- 2011-01-30 03:18:46 - building LINT kernel TB --- 2011-01-30 03:18:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-30 03:18:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-30 03:18:46 - TARGET=powerpc TB --- 2011-01-30 03:18:46 - TARGET_ARCH=powerpc64 TB --- 2011-01-30 03:18:46 - TZ=UTC TB --- 2011-01-30 03:18:46 - __MAKE_CONF=/dev/null TB --- 2011-01-30 03:18:46 - cd /src TB --- 2011-01-30 03:18:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 30 03:18:46 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_console.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_disk.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_openpic.c cc1: warnings being treated as errors /src/sys/powerpc/mambo/mambo_openpic.c: In function 'openpic_mambo_attach': /src/sys/powerpc/mambo/mambo_openpic.c:177: warning: implicit declaration of function 'openpic_common_attach' /src/sys/powerpc/mambo/mambo_openp
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-01-30 01:37:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-30 01:37:15 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-30 01:37:15 - cleaning the object tree TB --- 2011-01-30 01:37:29 - cvsupping the source tree TB --- 2011-01-30 01:37:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-30 01:37:45 - building world TB --- 2011-01-30 01:37:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-30 01:37:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-30 01:37:45 - TARGET=powerpc TB --- 2011-01-30 01:37:45 - TARGET_ARCH=powerpc TB --- 2011-01-30 01:37:45 - TZ=UTC TB --- 2011-01-30 01:37:45 - __MAKE_CONF=/dev/null TB --- 2011-01-30 01:37:45 - cd /src TB --- 2011-01-30 01:37:45 - /usr/bin/make -B buildworld >>> World build started on Sun Jan 30 01:37:45 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jan 30 03:14:14 UTC 2011 TB --- 2011-01-30 03:14:14 - generating LINT kernel config TB --- 2011-01-30 03:14:14 - cd /src/sys/powerpc/conf TB --- 2011-01-30 03:14:14 - /usr/bin/make -B LINT TB --- 2011-01-30 03:14:15 - building LINT kernel TB --- 2011-01-30 03:14:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-30 03:14:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-30 03:14:15 - TARGET=powerpc TB --- 2011-01-30 03:14:15 - TARGET_ARCH=powerpc TB --- 2011-01-30 03:14:15 - TZ=UTC TB --- 2011-01-30 03:14:15 - __MAKE_CONF=/dev/null TB --- 2011-01-30 03:14:15 - cd /src TB --- 2011-01-30 03:14:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 30 03:14:15 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_console.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_disk.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/mambo/mambo_openpic.c cc1: warnings being treated as errors /src/sys/powerpc/mambo/mambo_openpic.c: In function 'openpic_mambo_attach': /src/sys/powerpc/mambo/mambo_openpic.c:177: warning: implicit declaration of function 'openpic_common_attach' /src/sys/powerpc/mambo/mambo_openpic.c:177: warning: nested extern declaration of 'open
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 21:20:12 +0100 Alexey Shuvaev wrote: > On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote: > > On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev > > wrote: > > > Hello! > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > > now [1]. Examining build log and reproducing it locally, the > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > > The linker fails to produce libxpcom_core.so although > > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > > further I found that ..o produced with [3] > > > fails to link with libiconv alone too [4] (note still unresolved > > > libiconv references). I'm not a compiler/linker guru and do not > > > understand what is happening here. As a workaroud I use the > > > attached patch which disables the usage of libiconv in > > > nsNativeCharsetUtils.cpp. > > > > ls /usr/local/lib/libiconv*so* ? > > > ~> ll /usr/local/lib/libiconv*so* > lrwxr-xr-x 1 root wheel 13 Jan 27 > 13:14 /usr/local/lib/libiconv.so -> libiconv.so.3 -r--r--r-- 1 root > wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3 > > I'm not so lame :) > > On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote: > > On Sat, 29 Jan 2011 13:21:44 -0500 > > Alexander Kabaev wrote: > > > > > On Sat, 29 Jan 2011 13:02:24 -0500 (EST) > > > Daniel Eischen wrote: > > > > > > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > > > > > > > Hello! > > > > > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 > > > > > month now [1]. Examining build log and reproducing it > > > > > locally, the problem is in the usage of libiconv in > > > > > nsNativeCharsetUtils.cpp. The linker fails to produce > > > > > libxpcom_core.so although -L/usr/local/lib and -liconv are > > > > > specified [2]. Examining this further I found that > > > > > nsNativeCharsetUtils.o produced with [3] fails to link with > > > > > libiconv alone too [4] (note still unresolved libiconv > > > > > references). I'm not a compiler/linker guru and do not > > > > > understand what is happening here. As a workaroud I use the > > > > > attached patch which disables the usage of libiconv in > > > > > nsNativeCharsetUtils.cpp. > > > > > > > > Yes, I had this problem also on -current. Does seamonkey build > > > > on recent 8.x? > > > > > > > > libxpcomio_s.a is a static library that has unresolved > > > > references to libiconv. I guess I'd expect those references to > > > > be resolved with a later -L/usr/local/lib -liconv when building > > > > the shared library (libxpcom_core.so), but they are not. > > > > > > > > > > My wild guess: seamonkey tries to hide symbols that are coming > > > from different .o file (this time one from libiconv.a) and that > > > fails with our toolchain. > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 > > > -- > > > Alexander Kabaev > > > > Follow-up to myself: Nope, the fix to said bug appears in our > > compiler. Can you make amd64 version of nsNativeCharsetUtils. > > -- > > Alexander Kabaev > > > ??? (It is already on amd64) Email was sent while not finished. Can you make amd64 version of nsNativeCharsetUtils.o available from somewhere along with corresponding .ii file? To get .ii file you can add -save-temps to GCC invocation used to compile nsNativeCharsetUtils.cpp. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
Alexey Shuvaev writes:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
[...]
/usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
/head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
Is someone going to commit this?
@${ECHO_CMD} "#pragma GCC system_header" >> ${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} "#pragma GCC visibility push(default)" >>
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} "#include \"${LOCALBASE}/include/iconv.h\"" >>
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} "#pragma GCC visibility pop" >> ${MOZSRC}/${subdir}/iconv.h
%%
Index: www/seamonkey2/Makefile
===
RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
retrieving revision 1.315
diff -u -p -r1.315 Makefile
--- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
+++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
@@ -28,11 +28,10 @@ ALL_TARGET= default
MAKE_JOBS_SAFE=yes
MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
MAKE_ENV= LD_LIBRARY_PATH=${WRKSRC}/dist/bin
-CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include/cairo"
+CONFIGURE_ENV= LOCALBASE=${LOCALBASE} CPPFLAGS="-I${LOCALBASE}/include/cairo" \
+ ac_cv_func__Unwind_Backtrace=no
USE_GCC= 4.2+
-CONFIGURE_ENV= LOCALBASE=${LOCALBASE}
-
MOZ_EXTENSIONS=default
MOZ_OPTIONS+= --with-default-mozilla-five-home=${PREFIX}/lib/${MOZILLA} \
--enable-svg \
@@ -121,11 +120,6 @@ post-patch:
${WRKSRC}/mozilla/storage/build/Makefile.in
@${REINPLACE_CMD} -e
'/accessibility.typeaheadfind.enablesound/s/true/false/' \
${WRKSRC}/mozilla/modules/libpref/src/init/all.js
- @${REINPLACE_CMD} -e 's||\"${LOCALBASE}/include/iconv.h\"|g' \
- ${WRKSRC}/configure \
- ${WRKSRC}/mozilla/configure \
- ${WRKSRC}/mozilla/intl/uconv/native/nsNativeUConvService.cpp \
- ${WRKSRC}/mozilla/xpcom/io/nsNativeCharsetUtils.cpp
@${REINPLACE_CMD} -e 's|libgnome-2.so.0|libgnome-2.so|' \
${WRKSRC}/mozilla/toolkit/xre/nsNativeAppSupportUnix.cpp \
${WRKSRC}/mozilla/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp
%%
This patch did it!
I have successfully rebuilt www/seamonkey2 with the above patch
applied to port's Makefile (and without my previous workaround).
Everything works!
As this hidden/visibility symbols are beyond my C/CPP foo,
I am leaving the final decision for the experts :)
Thanks,
Alexey.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote:
> On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev
> wrote:
> > Hello!
> >
> > It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
> > Examining build log and reproducing it locally, the problem is in the
> > usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
> > produce libxpcom_core.so although -L/usr/local/lib and -liconv
> > are specified [2]. Examining this further I found that
> > nsNativeCharsetUtils.o
> > produced with [3] fails to link with libiconv alone too [4] (note
> > still unresolved libiconv references).
> > I'm not a compiler/linker guru and do not understand what is happening
> > here. As a workaroud I use the attached patch which disables the usage
> > of libiconv in nsNativeCharsetUtils.cpp.
>
> ls /usr/local/lib/libiconv*so* ?
>
~> ll /usr/local/lib/libiconv*so*
lrwxr-xr-x 1 root wheel 13 Jan 27 13:14 /usr/local/lib/libiconv.so ->
libiconv.so.3
-r--r--r-- 1 root wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3
I'm not so lame :)
On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote:
> On Sat, 29 Jan 2011 13:21:44 -0500
> Alexander Kabaev wrote:
>
> > On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
> > Daniel Eischen wrote:
> >
> > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
> > >
> > > > Hello!
> > > >
> > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month
> > > > now [1]. Examining build log and reproducing it locally, the
> > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
> > > > The linker fails to produce libxpcom_core.so although
> > > > -L/usr/local/lib and -liconv are specified [2]. Examining this
> > > > further I found that nsNativeCharsetUtils.o produced with [3]
> > > > fails to link with libiconv alone too [4] (note still unresolved
> > > > libiconv references). I'm not a compiler/linker guru and do not
> > > > understand what is happening here. As a workaroud I use the
> > > > attached patch which disables the usage of libiconv in
> > > > nsNativeCharsetUtils.cpp.
> > >
> > > Yes, I had this problem also on -current. Does seamonkey build
> > > on recent 8.x?
> > >
> > > libxpcomio_s.a is a static library that has unresolved references
> > > to libiconv. I guess I'd expect those references to be resolved
> > > with a later -L/usr/local/lib -liconv when building the shared
> > > library (libxpcom_core.so), but they are not.
> > >
> >
> > My wild guess: seamonkey tries to hide symbols that are coming from
> > different .o file (this time one from libiconv.a) and that fails with
> > our toolchain.
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
> > --
> > Alexander Kabaev
>
> Follow-up to myself: Nope, the fix to said bug appears in our compiler.
> Can you make amd64 version of nsNativeCharsetUtils.
> --
> Alexander Kabaev
>
??? (It is already on amd64)
Well, I have fogotten to put my environment:
~> uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed
Jan 26 17:00:37 CET 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
> Alexey Shuvaev writes:
>
> > Hello!
> >
> > It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
> > Examining build log and reproducing it locally, the problem is in the
> > usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
> > produce libxpcom_core.so although -L/usr/local/lib and -liconv
> > are specified [2]. Examining this further I found that
> > nsNativeCharsetUtils.o
> > produced with [3] fails to link with libiconv alone too [4] (note
> > still unresolved libiconv references).
> > I'm not a compiler/linker guru and do not understand what is happening
> > here. As a workaroud I use the attached patch which disables the usage
> > of libiconv in nsNativeCharsetUtils.cpp.
> >
> [...]
> > /usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
>
> /head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
> Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
>
> @${ECHO_CMD} "#pragma GCC system_header" >> ${MOZSRC}/${subdir}/iconv.h
> @${ECHO_CMD} "#pragma GCC visibility push(default)" >>
> ${MOZSRC}/${subdir}/iconv.h
> @${ECHO_CMD} "#include \"${LOCALBASE}/include/iconv.h\"" >>
> ${MOZSRC}/${subdir}/iconv.h
> @${ECHO_CMD} "#pragma GCC visibility pop" >> ${MOZSRC}/${subdir}/iconv.h
>
> %%
> Index: www/seamonkey2/Makefile
> ===
> RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
> retrieving revision 1.315
> diff -u -p -r1.315 Makefile
> --- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
> +++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
> @@ -28,11 +28,10 @@ ALL_TARGET= default
> MAKE_JOBS_SAFE= yes
>
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. My amd64 system is a little out of date, but I'll give it a try. If it builds, I'll update to a recent -current and try rebuilding it. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen wrote: > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > Hello! > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > now [1]. Examining build log and reproducing it locally, the > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > The linker fails to produce libxpcom_core.so although > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > further I found that nsNativeCharsetUtils.o produced with [3] fails > > to link with libiconv alone too [4] (note still unresolved libiconv > > references). I'm not a compiler/linker guru and do not understand > > what is happening here. As a workaroud I use the attached patch > > which disables the usage of libiconv in nsNativeCharsetUtils.cpp. > > Yes, I had this problem also on -current. Does seamonkey build > on recent 8.x? > > libxpcomio_s.a is a static library that has unresolved references > to libiconv. I guess I'd expect those references to be resolved > with a later -L/usr/local/lib -liconv when building the shared > library (libxpcom_core.so), but they are not. > My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev wrote: > On Sat, 29 Jan 2011 13:02:24 -0500 (EST) > Daniel Eischen wrote: > > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > > > Hello! > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > > now [1]. Examining build log and reproducing it locally, the > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > > The linker fails to produce libxpcom_core.so although > > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > > further I found that nsNativeCharsetUtils.o produced with [3] > > > fails to link with libiconv alone too [4] (note still unresolved > > > libiconv references). I'm not a compiler/linker guru and do not > > > understand what is happening here. As a workaroud I use the > > > attached patch which disables the usage of libiconv in > > > nsNativeCharsetUtils.cpp. > > > > Yes, I had this problem also on -current. Does seamonkey build > > on recent 8.x? > > > > libxpcomio_s.a is a static library that has unresolved references > > to libiconv. I guess I'd expect those references to be resolved > > with a later -L/usr/local/lib -liconv when building the shared > > library (libxpcom_core.so), but they are not. > > > > My wild guess: seamonkey tries to hide symbols that are coming from > different .o file (this time one from libiconv.a) and that fails with > our toolchain. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 > -- > Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sun4v
TB --- 2011-01-29 15:50:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-29 15:50:48 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-01-29 15:50:48 - cleaning the object tree TB --- 2011-01-29 15:50:58 - cvsupping the source tree TB --- 2011-01-29 15:50:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-01-29 15:51:10 - building world TB --- 2011-01-29 15:51:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-29 15:51:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-29 15:51:10 - TARGET=sun4v TB --- 2011-01-29 15:51:10 - TARGET_ARCH=sparc64 TB --- 2011-01-29 15:51:10 - TZ=UTC TB --- 2011-01-29 15:51:10 - __MAKE_CONF=/dev/null TB --- 2011-01-29 15:51:10 - cd /src TB --- 2011-01-29 15:51:10 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 29 15:51:11 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 29 16:52:41 UTC 2011 TB --- 2011-01-29 16:52:41 - generating LINT kernel config TB --- 2011-01-29 16:52:41 - cd /src/sys/sun4v/conf TB --- 2011-01-29 16:52:41 - /usr/bin/make -B LINT TB --- 2011-01-29 16:52:41 - building LINT kernel TB --- 2011-01-29 16:52:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-29 16:52:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-29 16:52:41 - TARGET=sun4v TB --- 2011-01-29 16:52:41 - TARGET_ARCH=sparc64 TB --- 2011-01-29 16:52:41 - TZ=UTC TB --- 2011-01-29 16:52:41 - __MAKE_CONF=/dev/null TB --- 2011-01-29 16:52:41 - cd /src TB --- 2011-01-29 16:52:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 29 16:52:41 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:360: error: 'AR_PHY_CCA_MAX_GOOD_VAL_5416_2GHZ' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:360: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:360: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:361: error: 'AR_PHY_CCA_MIN_GOOD_VAL_5416_2GHZ' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:362: error: 'AR_PHY_CCA_NOM_VAL_5416_2GHZ' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:363: error: 'AR_PHY_CCA_MAX_GOOD_VAL_5416_5GHZ' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:364: error: 'AR_PHY_CCA_MIN_GOOD_VAL_5416_5GHZ' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c:365: error: 'AR_PHY_CCA_NOM_VAL_5416_5GHZ' undeclared (first use in this function) *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-29 16:57:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-29 16:57:00 - ERROR: failed to build lint kernel TB --- 2011-01-29 16:57:00 - 3007.35 user 628.41 system 3972.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: missing us.dvorakr.kbd
On Fri, 28 Jan 2011 14:28:09 -0800 (PST) Neil Short wrote: > us.dvorakr.kbd is missing from /usr/share/syscons/keymaps/ > > > I found one on the web; but wonder if it's been fixed. > > $ uname -a > FreeBSD carmen.opera 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Oct 13 20:48:24 > MST 2010 neshort@carmen:/usr/obj/usr/src/sys/CARMEN amd64 > Actually it's already present in /usr/src/share/syscons/keymaps, but for some reason it doesn't get installed. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2011-01-29 09:56:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-29 09:56:08 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-29 09:56:08 - cleaning the object tree TB --- 2011-01-29 09:56:10 - cvsupping the source tree TB --- 2011-01-29 09:56:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-01-29 09:56:26 - building world TB --- 2011-01-29 09:56:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-29 09:56:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-29 09:56:26 - TARGET=mips TB --- 2011-01-29 09:56:26 - TARGET_ARCH=mips TB --- 2011-01-29 09:56:26 - TZ=UTC TB --- 2011-01-29 09:56:26 - __MAKE_CONF=/dev/null TB --- 2011-01-29 09:56:26 - cd /src TB --- 2011-01-29 09:56:26 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 29 09:56:26 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] : multiple definition of `__floatdisf' _floatdisf.So(.text+0x0): first defined here floatdidf.So(.text+0x0): In function `__floatdidf': : multiple definition of `__floatdidf' _floatdidf.So(.text+0x0): first defined here fixunsdfsi.So(.text+0x0): In function `__fixunsdfsi': : multiple definition of `__fixunsdfsi' _fixunsdfsi.So(.text+0x0): first defined here *** Error code 1 Stop in /src/gnu/lib/libgcc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-29 10:10:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-29 10:10:01 - ERROR: failed to build world TB --- 2011-01-29 10:10:01 - 637.25 user 111.63 system 832.33 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cpufreq not working as module on i386/amd64
On Sat Jan 29 11, Jia-Shiun Li wrote: > Hi all, > > I found that cpufreq driver failed to attach when compiled as module > and loaded, but it works fine when compiled into kernel. I am > wondering if this is due to some kind of limitation, or can be fixed? that's rather odd. for me neither the module nor the kernel code works, since my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile cpus seem to be supported. maybe you can add some printf's to est.c:est_get_info() to identify at which point error gets set. also you might want to make "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); non-conditional. maybe the output differy in kernel/module mode. cheers. alex > > Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop > (amd64). Both got the same result. dmesg of T4200 attached. > > kldload module: > ->8->8->8- > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > -8<-8<-8<- > (repeated 6 times, kldload retries?) > > compiled into kernel: > ->8->8->8- > ... > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > coretemp0: on cpu0 > coretemp0: Setting TjMax=104 > p4tcc0: on cpu0 > est0: on cpu0 > coretemp1: on cpu1 > coretemp1: Setting TjMax=104 > p4tcc1: on cpu1 > est1: on cpu1 > Device configuration finished. > procfs registered > ... > -8<-8<-8<- > > Jia-Shiun. -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
