Build failure on mips64/octeon
Hello, I'm trying to compile the current tree for my octeon device and
get the following error:
cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I.
-I/usr/home/m/Ubiquity/10/sys -I/usr/home/m/Ubiquity/10/sys/contrib/altq
-I/usr/home/m/Ubiquity/10/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=1 --param
large-function-growth=10 --param max-inline-insns-single=1
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8010
-march=octeon -mabi=64 -msoft-float -ffreestanding -Werror vnode_if.c
${NORMAL_CTFCONVERT} expands to empty string
: hack.c
cc -shared -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8010
-march=octeon -mabi=64 -nostdlib hack.c -o hack.So
rm -f hack.c
sed s/KERNLOADADDR/0x8010/g
/usr/home/m/Ubiquity/10/sys/conf/ldscript.mips.octeon1
ldscript.mips.octeon1
MAKE=make sh /usr/home/m/Ubiquity/10/sys/conf/newvers.sh OCTEON1
cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I.
-I/usr/home/m/Ubiquity/10/sys -I/usr/home/m/Ubiquity/10/sys/contrib/altq
-I/usr/home/m/Ubiquity/10/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=1 --param
large-function-growth=10 --param max-inline-insns-single=1
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8010
-march=octeon -mabi=64 -msoft-float -ffreestanding -Werror vers.c
${NORMAL_CTFCONVERT} expands to empty string
linking kernel.debug
hack.So: could not read symbols: File in wrong format
*** [kernel.debug] Error code 1
Stop in /usr/home/m/Ubiquity/obj/mips.mips/usr/home/m/Ubiquity/10/sys/M.
*** [buildkernel] Error code 1
Stop in /usr/home/m/Ubiquity/10.
*** [buildkernel] Error code 1
Stop in /usr/home/m/Ubiquity/10.
I build with TARGET=mips and TARGET_ARCH=mipseb.
My kernel config:
#
# OCTEON1 -- Generic kernel configuration file for FreeBSD/MIPS on
Cavium Octeon
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: stable/10/sys/mips/conf/OCTEON1 253845 2013-07-31 17:21:18Z
obrien $
ident OCTEON1
makeoptions ARCH_FLAGS=-march=octeon -mabi=64
makeoptions LDSCRIPT_NAME=ldscript.mips.octeon1
# Don't build any modules yet.
makeoptions MODULES_OVERRIDE=
makeoptions KERNLOADADDR=0x8010
# We don't need to build a trampolined version of the kernel.
makeoptions WITHOUT_KERNEL_TRAMPOLINE=1
include ../cavium/std.octeon1
hints OCTEON1.hints #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
# Board-specific support that cannot be auto-detected at runtime.
#optionsOCTEON_VENDOR_LANNER# Support for Lanner boards.
#optionsOCTEON_VENDOR_RADISYS # Support for Radisys boards.
options OCTEON_VENDOR_UBIQUITI # Support for Ubiquiti boards.
#optionsOCTEON_VENDOR_GEFES # Support for GE LANIC boards
#optionsOCTEON_BOARD_CAPK_0100ND# Support for CAPK-0100nd.
# Compile for a specified Octeon model. If not specified, support for
# detection at runtime will be used instead, which may give inferior
# performance.
#
# See sys/contrib/octeon-sdk/octeon-model.h for possible values.
#optionsOCTEON_MODEL=OCTEON_CN58XX_PASS1_1
options SCHED_ULE # ULE scheduler
options PREEMPTION # Enable kernel thread preemption
options INET# InterNETworking
options INET6 # IPv6 communications protocols
options SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control
Re: PathScale EKO Path 5 not for FreeBSD anymore?
On 20/02/2013 13:00, freebsd-current-requ...@freebsd.org wrote: Gathering informations from many places - as it is with WHICH PROFESSIONAL COMPILER WORKS ON FREEBSD WITH PROFESSIONAL HIGH PERFORMANCE MATH LIBS is horrible and time consuming. try it on Google with the tag Linux makes you happy within seconds. So true...I found that when the first search for a FreeBSD thing doesn't yield results, I search for Linux and then either check if the results work here or, having some well known name, look for alternatives. -- Twoje radio ___ 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: freebsd-current Digest, Vol 464, Issue 3
On 2012-09-05 09:34, freebsd-current-requ...@freebsd.org wrote: Hi all, I recently performed a series of compiler performance tests on FreeBSD 10.0-CURRENT, particularly comparing gcc 4.2.1 and gcc 4.7.1 against clang 3.1 and clang 3.2. Hey, you've got a cool idea, but the implementation ain't good...you can't compare optimising compilers w/out comparing optimisation quality. If you don't go all-out in one dimension, both are necessary. You conclude that Clang is faster. But maybe if you lowered optimisation level on gcc, it would become faster and stronger than Clang at the same time? We don't know, it hasn't been tested. Regards, -- Twoje radio ___ 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: [HEADSUP][CFT] pkgng beta1 is out
On 2012-02-06 08:40, Matt Thyer wrote: On Feb 6, 2012 3:50 AM, Radio młodych bandytów radiomlodychbandy...@o2.pl mailto:radiomlodychbandy...@o2.pl wrote: I wonder if I'm the only one thinking about a decentralised package management First, a decentralised transport layer. Torrents are faster and more reliable than servers. Second, decentralised management when anybody can upload a port directly into the system. -- Twoje radio Such a system would need to support traditional protocols such as FTP HTTP due to many corporate environments not allowing anything else. I'm all for a distributed system but you can't forget the corporate users. True. While some corporations are moving to P2P software distribution already, it's a long way before it becomes standard. -- Twoje radio ___ 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: [HEADSUP][CFT] pkgng beta1 is out
I wonder if I'm the only one thinking about a decentralised package management First, a decentralised transport layer. Torrents are faster and more reliable than servers. Second, decentralised management when anybody can upload a port directly into the system. -- Twoje radio ___ 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: freebsd-current Digest, Vol 429, Issue 8
On 2012-01-05 21:03, kab...@gmail.com wrote: On Wed, 04 Jan 2012 14:31:55 -0800 matt...@phoronix.com wrote: Thanks for the comment Arnaud. For comparative benchmarking on[1]Phoronix.com, Michael inva configuration 'in the way the developers or production'. This is by rule. However, i poor scores on be 'it should be tuned, is configured for a diffe The response from us to this comes in two forms.nb 1) If it is the wrong workload for the platform, do a public pos explaining and analysing the results. Highlighting the rationale fo r the concious reduction in performance (ie: journaling filesystems with ba filesystem integrity 2) If tuning can have a material impact on the results, post a t uning guide with step by step and rationale. Ie: educate the communit Michael and I have had many discussions with vendors an on this. In almost all cases, the vendor has either cha default configuration or accepted the results as valid. Asguide, Micha comparison. To dat offer. In part, thi public, but that is more of a result of a one sided d party external to a particular community (with a healthy tou journalisticly pumped compare contrast). For the FreeBSD community, who else outside of the FreeBSD community actually runs public c Matthew Not really related to the discussion on hand, but the above about the most unreadable email I am yet to read on the public mailing list. Yeah, I actually ignored it because of poor readability. -- Twoje radio ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux, 6.1 Server
Well, the post is OT, but I need some vent. On 2011-12-19 18:34, dan...@digsys.bg wrote: For example, few checkboxes with common sysctl tuning would be perfect, even if they would be marked as Experimental, or not recommended. By following this, we push FreeBSD into the Linux style of doing things: someone else decides what is good for you, without having a clue of your circumstances. It's nice to see sb. with similar thoughts. I too find the freedom to administer your system the way you see fit to be very important. I was very saddened when I discovered that in some ways FreeBSD also forces specific behaviour and in some others builds barriers to prevent people from doing things the authors considered stupid. I don't view it as Linux way vs. FreeBSD way ( though it may be because I don't know either too well ). Rather, I see it as the MacOS way. Education is much better than building barriers and it's never true that a developer can predict all the uses of their code. And different uses call for different configurations, artificially limiting it is a time invested to reduce code's value. -- Twoje radio ___ 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
