Re: powerpc and powerpc64 builds broken
Konstantin Belousov kostik...@gmail.com wrote: I think trying to understand why the hack was added is not possible. In an ideal world, svn blame would identify the commit in which it was added, and that commit's log entry would explain why :) ___ 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: powerpc and powerpc64 builds broken
On Jun 30, 2015 1:11 AM, Perry Hutchison per...@pluto.rain.com wrote: Konstantin Belousov kostik...@gmail.com wrote: I think trying to understand why the hack was added is not possible. In an ideal world, svn blame would identify the commit in which it was added, and that commit's log entry would explain why :) The line existed from the beginning. My guess is to bootstrap on non-iconv freebsd. As Konstantin said, though, it's very fragile. -Justin ___ 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: powerpc and powerpc64 builds broken
On Tue, Jun 30, 2015 at 8:48 AM, Simon J. Gerraty s...@juniper.net wrote: Justin Hibbits jhibb...@freebsd.org wrote: Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit that doesn't. (powerpc64 runs fine in qemu-devel; people should try it!) r284345 (introduction of metamode) is the problem. I bisected it on the power8 and it reliably fails this way. Andreas tested it on his G4 (32-bit hardware) and it worked fine, so there's something introduced that just doesn't like powerpc64. Hmm, didn't touch usr.bin/mkesdb so must be something indirect. Is this with[out] NO_CLEAN ? Tried it both ways, with the same result. I don't think metamode necessarily is the cause of the problem, merely unmasking the latent problem. Though I've committed a fix for this, it would still be nice to understand what in r284345 exposed this. - Justin ___ 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: powerpc and powerpc64 builds broken
Justin Hibbits jhibb...@freebsd.org wrote: Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit that doesn't. (powerpc64 runs fine in qemu-devel; people should try it!) r284345 (introduction of metamode) is the problem. I bisected it on the power8 and it reliably fails this way. Andreas tested it on his G4 (32-bit hardware) and it worked fine, so there's something introduced that just doesn't like powerpc64. Hmm, didn't touch usr.bin/mkesdb so must be something indirect. Is this with[out] NO_CLEAN ? ___ 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: powerpc and powerpc64 builds broken
On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
On 28.06.15 21:32, Konstantin Belousov wrote:
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com
wrote:
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb. It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.
The error seen at this point is:
cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value
I've seen this both locally on my G5, and on the Power8 in the FreeBSD
cluster.
- What does file say when you run it on libc.so.7?
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped
I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.
Neither me.
Here with this mods it compiles:
Either:
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Or:
Index: Makefile
===
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
No, I mean that LDFLAGS explicitely listing supposed location for libc
is wrong, too much wrong. If mkesd is special, it might need to become
a bootstrap tool. But the hackery above is too fragile and it is surprising
that it went unnoticed for such long time (after the citrus enablement).
Would anyone object to me simply removing that line? This fixes the
build on powerpc64, and I highly doubt it would impact any other
build.
- Justin
___
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: powerpc and powerpc64 builds broken
On Mon, Jun 29, 2015 at 4:58 PM, Justin Hibbits jhibb...@freebsd.org wrote:
On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
On 28.06.15 21:32, Konstantin Belousov wrote:
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com
wrote:
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb. It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.
The error seen at this point is:
cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value
I've seen this both locally on my G5, and on the Power8 in the FreeBSD
cluster.
- What does file say when you run it on libc.so.7?
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped
I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.
Neither me.
Here with this mods it compiles:
Either:
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Or:
Index: Makefile
===
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
No, I mean that LDFLAGS explicitely listing supposed location for libc
is wrong, too much wrong. If mkesd is special, it might need to become
a bootstrap tool. But the hackery above is too fragile and it is surprising
that it went unnoticed for such long time (after the citrus enablement).
Would anyone object to me simply removing that line? This fixes the
build on powerpc64, and I highly doubt it would impact any other
build.
- Justin
A universe build on the cluster passed, I'm nuking it.
- Justin
___
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: powerpc and powerpc64 builds broken
On Mon, Jun 29, 2015 at 09:05:25PM -0700, Justin Hibbits wrote:
On Mon, Jun 29, 2015 at 4:58 PM, Justin Hibbits jhibb...@freebsd.org wrote:
On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov
kostik...@gmail.com wrote:
On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
On 28.06.15 21:32, Konstantin Belousov wrote:
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper
yaneurab...@gmail.com wrote:
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org
wrote:
Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb. It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.
The error seen at this point is:
cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value
I've seen this both locally on my G5, and on the Power8 in the
FreeBSD cluster.
- What does file say when you run it on libc.so.7?
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped
I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.
Neither me.
Here with this mods it compiles:
Either:
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Or:
Index: Makefile
===
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
No, I mean that LDFLAGS explicitely listing supposed location for libc
is wrong, too much wrong. If mkesd is special, it might need to become
a bootstrap tool. But the hackery above is too fragile and it is
surprising
that it went unnoticed for such long time (after the citrus enablement).
Would anyone object to me simply removing that line? This fixes the
build on powerpc64, and I highly doubt it would impact any other
build.
- Justin
A universe build on the cluster passed, I'm nuking it.
Fine with me. I think trying to understand why the hack was added is
not possible.
___
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: powerpc and powerpc64 builds broken
On 28.06.15 21:32, Konstantin Belousov wrote:
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote:
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb. It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.
The error seen at this point is:
cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value
I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster.
- What does file say when you run it on libc.so.7?
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped
I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.
Neither me.
Here with this mods it compiles:
Either:
--- Makefile(revision 284911)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Or:
Index: Makefile
===
--- Makefile(revision 284911)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Andreas
___
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
powerpc and powerpc64 builds broken
Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: could not read symbols: Bad value I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. - Justin ___ 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: powerpc and powerpc64 builds broken
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: could not read symbols: Bad value I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. - What does file say when you run it on libc.so.7? - What's your current revision? - Does it work when SRCCONF/__MAKECONF are set to /dev/null? Thanks! ___ 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: powerpc and powerpc64 builds broken
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: could not read symbols: Bad value I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped - What's your current revision? r284893 - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. Thanks! - Justin ___ 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: powerpc and powerpc64 builds broken
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: could not read symbols: Bad value I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped I think a libc linker could try for that command line lives in /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so or in /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so But, the reason for your troubles seems to come from the usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point to objdir/.../libc, I have no idea. - What's your current revision? r284893 - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. Thanks! - Justin ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ 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: powerpc and powerpc64 builds broken
On 28 Jun 2015, at 19:09 , Justin Hibbits jhibb...@freebsd.org wrote: On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped - What's your current revision? r284893 - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. I have not see this problem in my endless tinderbox run; I know the crossbuilds succeeded with r284913. — Bjoern A. Zeeb Charles Haddon Spurgeon: Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend. ___ 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: powerpc and powerpc64 builds broken
On 28 June 2015 at 15:52, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 28 Jun 2015, at 19:09 , Justin Hibbits jhibb...@freebsd.org wrote: On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped - What's your current revision? r284893 - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. I have not see this problem in my endless tinderbox run; I know the crossbuilds succeeded with r284913. Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit that doesn't. (powerpc64 runs fine in qemu-devel; people should try it!) -adrian — Bjoern A. Zeeb Charles Haddon Spurgeon: Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ 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: powerpc and powerpc64 builds broken
On Sun, Jun 28, 2015 at 3:59 PM, Adrian Chadd adrian.ch...@gmail.com wrote: On 28 June 2015 at 15:52, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 28 Jun 2015, at 19:09 , Justin Hibbits jhibb...@freebsd.org wrote: On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote: Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped - What's your current revision? r284893 - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. I have not see this problem in my endless tinderbox run; I know the crossbuilds succeeded with r284913. Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit that doesn't. (powerpc64 runs fine in qemu-devel; people should try it!) r284345 (introduction of metamode) is the problem. I bisected it on the power8 and it reliably fails this way. Andreas tested it on his G4 (32-bit hardware) and it worked fine, so there's something introduced that just doesn't like powerpc64. - Justin ___ 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: powerpc and powerpc64 builds broken
On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
On 28.06.15 21:32, Konstantin Belousov wrote:
On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com
wrote:
On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb. It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.
The error seen at this point is:
cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value
I've seen this both locally on my G5, and on the Power8 in the FreeBSD
cluster.
- What does file say when you run it on libc.so.7?
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped
I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.
Neither me.
Here with this mods it compiles:
Either:
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
Or:
Index: Makefile
===
--- Makefile (revision 284911)
+++ Makefile (working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../../lib/libc/iconv
PROG= mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc
NO_WMISSING_VARIABLE_DECLARATIONS=
No, I mean that LDFLAGS explicitely listing supposed location for libc
is wrong, too much wrong. If mkesd is special, it might need to become
a bootstrap tool. But the hackery above is too fragile and it is surprising
that it went unnoticed for such long time (after the citrus enablement).
___
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
