On 2010-03-04 14:51, paradox wrote:
#mkdir /usr/src/sys/arch
#mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
Would it ever done in freebsd?
Sure, right after the switch to git.
___
freebsd-curren
On 2010-03-05 13:18, Dag-Erling Smørgrav wrote:
Hmm, how does that work? Doesn't the BIOS spin the disks up long before
the kernel even loads? Can you set a flag on the disk to tell it not
to?
A jumper (marked PM2 on WD disks; no idea for other brands). From
Wikipedia:
"[PUIS] can usually b
On 2010-03-21 14:08, Gary Jennejohn wrote:
CPUTYPE=native
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
It "silences" make. See the man page. It's useful because basically only
errors are emitted.
Oops. That's wrong. I got confused. I'd like to know that myse
On 2010-03-21 22:20, Garrett Cooper wrote:
From gcc(1):
-s Remove all symbol table and relocation information from the exe-
cutable.
This is more or less the same as running strip(1) over the produced
executables. Usually one uses it for non-debug builds.
That seems a bit
On 2010-04-08 17:24, Gary Jennejohn wrote:
References
The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report
Advanced Format sector sizes and other performance optimization information.
These standards are used for SATA, SAS, USB, and IEEE 1394 based interface
technologies
On 2010-04-08 21:34, Alexey Tarasov wrote:
Thank you for the information.
In 8-STABLE snapshot 201002 diskinfo shows 512k sector size yet.
I will try CURRENT tomorrow.
It looks like the code was MFC'd to stable/8 in r199443. However, even
in -CURRENT, the sector size you see in diskinfo will a
On 2010-04-09 13:00, Alexey Tarasov wrote:
/dev/ad4
512 # sectorsize
1500301910016 # mediasize in bytes (1.4T)
2930277168 # mediasize in sectors
0 # stripesize
0 # stripeoffset
2907021 # Cylinders according to firmware
On 2010-04-16 18:08, Roman Divacky wrote:
cd clangbsd&& make buildworld
Buildworld all goes well, until this stage:
--
stage 4.2: building libraries
--
cd /home/di
On 2010-04-17 11:58, Roman Divacky wrote:
svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd
cd clangbsd&& make buildworld
echo NO_WERROR=>> /etc/make.conf
echo WERROR=>> /etc/make.conf
you have to do those echos before the buildworld of course..
On 2010-04-17 19:33, Roman Divacky wrote:
what version of clang/llvm are you using?
As I mentioned at the end of my previous post:
I'm using the llvm-devel-2.7.r100430 port.
This is the current devel/llvm-devel port, AFAICS? The system itself
runs -CURRENT as of r206706.
__
On 2010-04-17 20:13, Roman Divacky wrote:
I'm using the llvm-devel-2.7.r100430 port.
This is the current devel/llvm-devel port, AFAICS? The system itself
runs -CURRENT as of r206706.
sorry.. havent noticed that you wrote that in your first mail
yes, i386 has a problem. I am just distilling
On 2010-04-20 16:04, Roman Divacky wrote:
Tried again with llvm r101891, still the same error...
the problem is that gcc miscompiles llvm at -O3, I havent managed
to contact brooks@ to change the port to default to -O2
you can do that locally I guess
Tried llvm-devel-2.7.r101995 built with -
On 2010-04-21 17:24, Roman Divacky wrote:
Tried llvm-devel-2.7.r101995 built with -O2, but no difference in the
result. I guess it's a real bug in llvm. :)
can you try with LLVM svn trunk? it works for me ok (with -O2 compilation)
AFAICS the only change between r101995 and r102001 is in some
On 2010-04-21 20:20, Roman Divacky wrote:
[1m/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:140:1:
[0m[0;1;35mwarning: [0m[1mcontrol may reach end of non-void function
[-Wreturn-type]
[0m}
[0;1;32m^
[0m[1m/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc
re is such
a ports directory, with a ports.tgz file (and accompanying
CHECKSUM.MD5 and install.sh files).
Is this a deliberate omission on the FTP servers?
Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2
re is such
a ports directory, with a ports.tgz file (and accompanying
CHECKSUM.MD5 and install.sh files).
Is this a deliberate omission on the FTP servers?
Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2
ox, bind9 uses /dev/null and /dev/random. It
probably dups stdin, stdout and stderr to /dev/null at startup, and it
obviously uses /dev/random for random data. :) I presume this
behaviour will be exactly the same on -CURRENT.
Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http:
On 2010-08-14 17:53, Andrey Chernov wrote:
> From my point of
> view importing of the latest GNU grep instead would have more benefits.
Unfortunately GNU grep switched to GPLv3 as of version 2.5.3. The last
GPLv2 version of grep is 2.5.1, which is already in our tree.
__
On 2010-08-15 21:07, Dag-Erling Smørgrav wrote:
> I built a profiling version of BSD grep and ran it with a regexp that
> matches only the very last line in (my copy of) INDEX-9. The results
> are pretty clear:
[I also did precisely that, and I just read your mail when I was
composing the followi
On 2010-08-15 21:49, Dimitry Andric wrote:
> ...I
> have attached a more complete patch that:
>
> - Replaces the horrendously inefficient grep_fgetln() with mostly the
> same implementation as the libc fgetln() function.
> - Uses plain file descriptors instead of stru
Hi,
Since clang has gone into the tree, there has been an effort to get head
in a state where world can optionally be built with it. A number of
changes required for this have already been committed, mainly thanks to
Ed Schouten, Roman Divacky and Rui Paulo. Most of these changes were
adapted fr
On 2010-08-17 13:40, Ed Schouten wrote:
>> +#ifndef __FreeBSD__
>> + AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false);
>> +#endif
>>
>>// Builtin includes use #include_next directives and should be positioned
>>// just prior C include dirs.
>
> Hmmm... Do we really
On 2010-08-17 13:49, Bob Bishop wrote:
>> However, a disadvantage is that the built-in search paths of the
>> bootstrap compiler are not entirely disabled by using the -isysroot, -B
>> and -L flags,
>
> This could be viewed as a bug ...
It is probably a bit more complicated than that. Let me exp
On 2010-08-17 15:03, Daniel Nebdal wrote:
>>> However, a disadvantage is that the built-in search paths of the
>>> bootstrap compiler are not entirely disabled by using the -isysroot, -B
>>> and -L flags,
...
> For clarification, did you (Dimitry, that is) mean
> a) The paths are still there so the
On 2010-08-17 15:15, Alexander Kabaev wrote:
> Dimitry Andric wrote:
...
>> 1) The "isysroot" method: build a regular version of clang, and make
>>sure WMAKEENV contains something like:
>>
>>CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/
On 2010-08-17 16:28, Daniel Nebdal wrote:
> Mmh, I just read through the in-detail description you gave in another
> mail. It's a bit surprising that there isn't a simple and reliable way
> to disable/replace all hardcoded paths, but I guess it doesn't come up
> that often.
Well, except when you w
On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
> Dimitry Andric writes:
>> - Uses plain file descriptors instead of struct FILE, since the
>> buffering is done manually anyway, and it makes it easier to support
>> gzip and bzip2.
> It might be worth a shot adding mmap
On 2010-08-17 17:04, Eitan Adler wrote:
> what about -nostdinc ?
>Do not search the standard system directories for header files.
>
> Or will this also disable the command line equivalents ?
It seems that -isysroot doesn't work with that:
$ gcc -nostdinc -isysroot ${WORLDTMP} -S -v
On 2010-08-17 18:29, Alan Cox wrote:
> Try it again on a memory resident file with the MAP_PREFAULT_READ option
> that is provided by this patch:
>
> http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch
A time trial gives:
grep with normal mmap() 1396s
grep with prefault mmap() 1354
On 2010-08-18 11:15, Dag-Erling Smørgrav wrote:
> I'm not a big fan of "reasonable chances" when it comes to the
> toolchain.
Me neither, which is why I created method 2 originally. :) The
-isysroot method was invented by Roman Divacky in r198248.
> No, what is used is a variant of method 1 *on
On 2010-08-18 19:37, Rui Paulo wrote:
> I really don't know how compatible is the latest icc because no one
> ever updated the ports version. This is actually a hint that no one
> really uses this anymore.
I recently installed the port, which has icc 8.1, but it fails to
compile even simple C++ pr
On 2010-08-18 22:52, Peter Jeremy wrote:
>> grep with normal mmap() 1396s
>> grep with prefault mmap() 1354s
>> grep with regular read() 1354s
>
> Is this with uncached (ie remount the filesystem on each test) or cached
> data?
This is all on the same filesystem, and the test fi
On 2010-08-18 23:12, Dimitry Andric wrote:
>> And one trial is not statistically valid - especially given the small
>> differences. How about multiple multiple trials with ministat.
>
> The result were averages of three trials
Actually, since I kept using Doug's orig
On 2010-08-17 23:24, Alan Cox wrote:
>> So normal mmap is ~3% slower, and prefault mmap does not seem to make
>> any measurable difference. I guess the added complexity is not really
>> worth it, for now.
>
> Do you know what fraction of this time is being spent in the kernel?
I ran 100 trials a
On 2010-08-19 18:42, David Xu wrote:
> When will the grep -H print file name for me ? it is rather painful
> that the feature is missing. :-(
> So I can not use it with find:
>
> find . -exec grep -H {} world \;
> I don't know which file contains the word world.
I think you mean:
find . -exe
On 2010-08-20 23:07, b. f. wrote:
> The lisp category is the only category that causes a problem with the
> new bsdgrep, and I didn't take the time to analyze why ( which is why
> I was not more specific in my original message). 'lisp' is preceded by
> 'elisp', which would normally be a match for t
On 2010-09-10 15:50, Thomas E. Spanjaard wrote:
While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411,
the kernel hangs at some point when math/atlas tries to run some tests
(presumably the ones to profile the code and optimise). The kernel
spouts messages about Starting event t
On 2010-09-15 14:44, Dmitry Krivenok wrote:
I recently updated to r212634 and tried to build CURRENT tree with ccache.
...
/usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid
64 bit base/index expression
I assume this error occurs when building the 32-bit components on amd6
On 2010-09-20 10:43, Dmitry Krivenok wrote:
Your patch works fine for me, thanks!
Note this patch is just a workaround for now, I'm still working on the
proper solution. :)
However, I don't see any performance gain when using ccache:
...
cache miss225341
...
cache
Hi,
As of r212979, you should now be able to build world and kernel on i386
and amd64 with clang, without any additional patches!
To do so, make sure you have updated your installed world to at least
r212904 (which has the most recently imported clang/llvm snapshot), and
put the following in /et
On 2010-09-23 12:20, Bartosz Stec wrote:
--- /etc/csh.cshrc 2009-09-21 11:01:51.0 +0200
+++ ./etc/csh.cshrc 2010-09-23 12:12:47.553768640 +0200
@@ -1,6 +1,3 @@
-# $FreeBSD: src/etc/csh.cshrc,v 1.3 1999/08/27 23:23:40 peter Exp $
+# $FreeBSD$
(...)
On 2010-09-23 12:55, Bartosz Stec wrote:
0. Program arguments: /usr/bin/clang++ -cc1 -triple
i386-undermydesk-freebsd9.0 -S -disable-free -main-file-name APFloat.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-target-cpu i486 -resource-dir /usr/lib/clang/2.8 -D LLVM_ON
On 2010-09-23 13:24, Bartosz Stec wrote:
I cannot reproduce this here, running the exact command printed above.
What is the output of "/usr/bin/clang++ -v" ?
# /usr/bin/clang++ -v
FreeBSD clang version 2.8 (branches/release_28 114020) 20100917
Target: i386-undermydesk-freebsd9.0
Thread model: po
On 2010-09-24 13:24, Bartosz Stec wrote:
make.conf (note that NOCCACHE was defined in environment during all
builds so ccache wasn't used):
CPUTYPE=athlon-xp
# default build settings for ports collection
.if ${.CURDIR:M*/ports/*}&& !defined(NOCCACHE)
CFLAGS=-O2 -pipe
.
On 2010-09-24 14:13, Bartosz Stec wrote:
Could you please try to rename this make.conf to e.g. make.conf.disable,
and retry the world build?
Still the same without make.conf. My personal guess is, that clang
builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think
CFLAGS=-O2 -pip
On 2010-09-25 03:13, Mark Tinguely wrote:
I was inspired by the clang build world topic to try a cross build world
of ARM from a i386 computer.
I use the build command:
make TARGET_ARCH=arm TARGET_CPUTYPE=xscale buildworld
(I tried an "TARGET_CPUTYPE=cortex-a8" once also, I got the same er
On 2010-09-25 21:16, Paul B Mahol wrote:
On 9/22/10, Dimitry Andric wrote:
As of r212979, you should now be able to build world and kernel on i386
and amd64 with clang, without any additional patches!
...
When to expect to get rid of GNU as and other binutils tools?
Work is progressing
On 2010-09-27 09:32, Olivier Smedts wrote:
2010/9/23 Bartosz Stec:
...
Assertion failed: (false&& "Ran out of registers during register
allocation!"), function assignRegOrStackSlotAtInterval, file
/usr/src/lib/clang/libllvmcodegen/../../../contrib/llvm/lib/CodeGen/RegAllocLinearScan.cpp,
line
On 2010-09-29 02:28, Derek Tattersall wrote:
A test shell script using mktemp (1) works fine on current built with
clang today. The clang case produces a filename with all "A"'s rather
than the random letters expected.
I cannot reproduce this on a system compiled entirely with clang:
$ mktemp
On 2010-09-29 13:23, Renato Botelho wrote:
#!/usr/bin/perl
use File::Temp;
my ( $fh, $filename ) = File::Temp::tempfile();
print "$filename\n";
For me it works perfectly, though I am using perl 5.10:
$ cat foo.pl
#!/usr/bin/perl
use File::Temp;
my ( $fh, $filename ) = File::Temp::tempfile(
Hi,
I just encountered the following soft update panic while running perl
5.12's tests:
panic: indir_trunc: Index out of range -148 parent -2061 lbn -305164
cpuid = 3
KDB: enter: panic
[ thread pid 19 tid 100047 ]
Stopped at kdb_enter+0x3a: movl$0,kdb_why
db> bt
Tracing pid 19 tid 10004
On 2010-09-29 16:32, Dimitry Andric wrote:
It is consistently reproducible. This is on a -current system, at
r213139, on i386. Settings for the affected filesystem:
N.B: it only panics when using SU+J, not when using plain soft updates.
___
freebsd
On 2010-09-29 17:48, Renato Botelho wrote:
0. Program arguments: /usr/bin/clang -cc1 -triple
x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name ldexp.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/lib/clan
On 2010-09-29 20:35, Renato Botelho wrote:
Alternatively, just run "make test" in /usr/ports/lang/perl5.12.
Since i'm running -current with SUJ here, and built perl 5.12
recently without problems, maybe this can help you (I have
that patch applied locally since it was not committed yet).
http:
On 2010-09-29 20:22, Renato Botelho wrote:
It's using drand48() instead of rand()
...
GCC libc:
ga...@botelhor:~/testes> ./test
random value 0.396465
clang libc:
ga...@botelhor:~/testes> ./test
random value -inf
Renato, Derek, could you please apply the attached patch for ldexp,
rebuild yo
On 2010-09-29 21:47, Renato Botelho wrote:
Renato, Derek, could you please apply the attached patch for ldexp,
rebuild your libc (with clang), and run your random test program again?
Worked perfectly here \o/
And what about perl? :)
___
freebsd-curr
On 2010-09-30 23:07, Doug Barton wrote:
To what extent is HAL relevant here? I was sort of ambivalent about
using it in FreeBSD, but my recent experimentation with ubuntu is
starting to change my mind.
Please read this first: https://wiki.ubuntu.com/Halsectomy :)
_
On 2010-10-03 15:41, Derek Tattersall wrote:
In updating gnash to 8.8 the build failed while linking with libvgl.so. My
current system was built last week, with both kernel and world built
with clang. The linkage failure was due to an inlined function,
"set4pixels" which is only referred to, as
On 2010-10-03 17:21, Dimitry Andric wrote:
Since gnash has about a gazillion dependencies, and I have the idea that
after 12 hours of building stuff, I will not be able to reproduce your
error message anyway, could you please post it (or upload it, if it is
very large)?
I cannot reproduce your
On 2010-10-04 20:41, Renato Botelho wrote:
There is also a chance this might fix your issue, can you please try it
out?
Same problem here with this patch
It turns out it was an issue in libvgl, which should be fixed by
r213412. Can you please try to update to that revision, rebuild and
reinst
On 2010-10-07 09:27, Dmitry Krivenok wrote:
c++: Internal error: Killed: 9 (program ld)
Please submit a full bug report.
Seehttp://gcc.gnu.org/bugs.html> for instructions.
r...@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang # [1]
Have anyone seen this problem before? Any wor
On 2010-10-07 12:51, Dmitry Krivenok wrote:
I run ld under gdb and found the place where it fails:
...
Program received signal SIGKILL, Killed.
0x0042e093 in bfd_elf_final_link (abfd=0x800915140, info=0x66c900)
at
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/b
On 2010-10-22 12:54, Renato Botelho wrote:
I have a 9.0-current (r214167) amd64, kernel and world built
with clang and all ports built with gcc, and i cannot start
openoffice anymore, it shows splash, start to go up and die.
If I reinstall world+kernel built with gcc openoffice works fine.
The
Hi,
When I was doing my own ports sort-of-exp-run, using the binutils 2.17
branch, I encountered an issue with the glib20 port on amd64. Some
files in it failed to link with the error:
relocation R_X86_64_PC32 against `_g_atomic_thread_init' can not be used
when making a shared object; recompil
On 2010-11-17 23:04, John Baldwin wrote:
On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote:
panic: mtx_init: mtx_lock not aligned for netir_mtx: 0x8114791c
...
I'm guessing the recent changes to how the VNET stuff works have broken the
alignment of DPCPU and VNET structures aga
On 2010-11-22 21:28, FreeBSD Tinderbox wrote:
...
/src/sys/compat/linux/linux_emul.c: In function 'linux_proc_exec':
/src/sys/compat/linux/linux_emul.c:265: error: dereferencing pointer to
incomplete type
/src/sys/compat/linux/linux_emul.c:265: error: 'SV_ABI_MASK' undeclared (first
use in this
On 2010-12-03 10:58, Anton Shterenlikht wrote:
a.out: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically linked,
not stripped
...
The branding on ia64 is wrong. The executable is not marked as being
a FreeBSD executable. It's declared as SYSV, whereas on amd64 it's
properly declare
On 2010-12-31 22:35, René Ladan wrote:
somewhere between 9.0-amd64 r216351 and r216738, I've noticed some
userland weirdness.
Symptoms are:
- pseudo-random number generator not starting, preventing ssh(d) from working
- fonts in X.org (xfce4) missing or replaced
- mouse only working when hald is
Hi all,
For some time, I have been working on importing a newer version of
binutils into -current. This updates our quite ancient 2.15 version to
the last version available under GPLv2, 2.17.50. (Special thanks to
Nathan Whitehorn for his valuable feedback.)
As far as I know, all issues buildi
On 2011-01-07 22:22, Doug Barton wrote:
This is much appreciated work of course, but I'm wondering if you've
requested an experimental ports run with the change? It would be good to
know how much damage to expect before the change gets committed.
Yes, I submitted an exp-run request Nov 15, 2010
On 2011-01-07 22:21, Mehmet Erol Sanliturk wrote:
http://svn.freebsd.org/base/projects/binutils-2.17/
all of the Text files are seen as Binary files by Firefox in Linux
Try http://svn.freebsd.org/viewvc/base/projects/binutils-2.17/ instead.
For checking out the source tree, please use a Subve
On 2011-01-07 22:54, Ade Lovett wrote:
Most likely it's low priority given all the other exp-runs that affect
7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of
other infrastructure stuff. Not to mention the impending 7- and 8-
RELEASEs.
I understand, and there will probably a
On 2011-01-08 01:54, Anonymous wrote:
Looks like lang/sbcl doesn't like new ld(1), here on amd64.
Same error when building using devel/binutils. Can you reproduce?
...
//doing warm init - compilation phase
This is SBCL 1.0.43, an implementation of ANSI Common Lisp.
More information abo
On 2011-01-12 23:26, Matthew Fleming wrote:
This is me, but I'm rather puzzled why it's failing.
SYSCTL_UQUAD is in the sys/sysctl.h for the image we're building. And
why is there a file with SYSCTL_FOO being built as a library?
Any help?
During the build of cddl/lib/libzpool, it looks like
On 2011-02-02 19:04, Konference wrote:
Is there support for new Intel H67 chipset (SATA) ?
I didn't find anything relevant on google
Maybe after Intel finishes its recall? :)
I don't think you want to use those chips...
___
freebsd-current@freeb
On 2011-01-07 21:57, Dimitry Andric wrote:
For some time, I have been working on importing a newer version of
binutils into -current. This updates our quite ancient 2.15 version to
the last version available under GPLv2, 2.17.50.
The binutils 2.17 project branch has been cooking for quite
On 2011-02-18 17:36, Alexander Best wrote:
...
i'd say no. imo nothing from /usr/local/* should ever be invoked when compiling
a target in /usr/src. everything that's needed is in /usr/* (excluding local).
so $PATH should unconditionally be set to sth. like:
PATH=/sbin:/bin:/usr/sbin:/usr/bin;
On 2011-02-16 21:00, Dimitry Andric wrote:
So I plan to merge the binutils-2.17 project branch to head this
weekend, if there are no further objections. If you have found a
showstopper bug, please let me know ASAP. :)
Okay, binutils 2.17.50 has now been merged to head in r218822. If you
On 2011-02-19 15:35, Dimitry Andric wrote:
Okay, binutils 2.17.50 has now been merged to head in r218822. If you
compile kernels by hand, make sure to first run "make buildworld", or at
least "make kernel-toolchain", to get a new ld in /usr/obj. Otherwise,
linking yo
On 2011-02-21 11:33, Olivier Smedts wrote:
I can't buildworld with Clang since the last update.
...
%cat /etc/src.conf
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Try putting these lines i
On 2011-02-22 15:37, datastream datastream.freecity wrote:
I add '-no-integrated-as' in /etc/make.conf,but I still failed.
Don't do that. The few instances where the integrated assembler needs
to be disabled are already covered.
...
/usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference
On 2011-02-22 16:16, Manfred Antar wrote:
I too am having trouble with buildworld
I switched back to standard /usr/bin/cc, but make buildworld stops here:
c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/to
On 2011-02-22 18:38, datastream datastream.freecity wrote:
In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And removed
all files in /usr/obj. /usr/src sync with http://svn.freebsd.org/base/head.
#make buildkernel
Before you do "make buildkernel", always run "make buildworld", or
On 2011-02-22 20:23, Jung-uk Kim wrote:
Since binutils 2.17.50 import, WITH_CTF=1& buildworld on amd64 stops
like this:
...
cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT
-isystem /usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32
-B/usr/obj/usr/src/
On 2011-02-23 14:22, datastream datastream.freecity wrote:
I deleted all files in /usr/src and /usr/obj. it changes nothing, i still
get same error.
In /etc/make.conf:
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
# Don't die on warning
On 2011-02-24 08:26, datastream datastream.freecity wrote:
I removed /etc/src.conf.binutils is 2.15.
...
Ok, I managed to reproduce your error, on an old snapshot with clang 2.8
and binutils 2.15. It turns out it is caused by an upstream change,
which was intended to work around problems in th
On 2011-02-25 13:36, Boris Samorodov wrote:
I can't mount tmpfs from fstab if world/kernel are build by clang,
however just making world with gcc works fine.
The cause of this issue is a problem with the way clang's integrated
assembler handles global symbols that are not referenced.
This prob
On 2011-02-27 00:06, Michael Butler wrote:
/src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no
member named 'sctp_rttvar_eqret'
/src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no
member named 'sctp_rttvar_eqret'
...
While it's likely that this is not what
On 2011-02-25 16:58, Boris Samorodov wrote:
On Fri, 25 Feb 2011 14:33:38 +0100 Dimitry Andric wrote:
For now, please build kernels with "-no-integrated-as" added to
COPTFLAGS, that should fix it.
FYI unfortunately this does not help. Full build log is here:
ftp://ftp.bsam.
This weekend I updated our copy of llvm/clang again, from trunk r126079
to trunk r126547.
There are several bugfixes in this update, but the most important one is
to ensure __start_ and __stop_ symbols for linker sets and kernel module
metadata are always emitted in object files.
Before this fix
On 2011-02-28 04:30, Tim Kientzle wrote:
I have a FreeBSD-CURRENT AMD64 system here that was last updated at r215029.
I'm trying to update it to r219079, but the build fails in lib/libz when it
tries to compile gvmat64.S. It looks like the Makefile here has a workaround
for clang on AMD64, bu
On 2011-02-28 08:55, Doug Barton wrote:
I have a different problem on r219092. Everything builds find, but
"linking kernel.debug" hangs forever. It can't even be killed with ^C.
My existing system is r218985M, which was built with clang. This is my
first time trying to build a system with clang O
On 2011-02-28 15:35, Olivier Smedts wrote:
I now have problems building gnu/lib/libobjc. When using Clang, gcc is
still used to build gnu/lib/libobjc (see "XXX: clang cannot compile
libobjc yet"), but gcc core dumps at this stage on two different
computers, using the same CFLAGS "-O2 -pipe -march
On 2011-02-28 08:55, Doug Barton wrote:
I have a different problem on r219092. Everything builds find, but
"linking kernel.debug" hangs forever. It can't even be killed with ^C.
My existing system is r218985M, which was built with clang. This is my
first time trying to build a system with clang O
On 2003-08-24 at 11:27:05 Soren Schmidt wrote:
> ATAng has just been committed. You need to make world after this update
> as atacontrol etc needs to pick up the changes.
Building went fine here on my VMware test box, but the new kernel spat
out a warning (which wasn't fatal, as it doesn't panic)
While trying to build a -CURRENT release for my aging Pentium 150
router box on my substantially faster Athlon XP box, I ran into the
following problem.
I'm using CPUTYPE=i586 in /etc/make.conf, since the target box is not
even capable of doing MMX. However, when the build is complete and I
try to
On 2003-10-06 at 19:21:34 M. Warner Losh wrote:
> My bad. I've fixed it.
Builds fine now, thanks for the fast fix. :)
pgp0.pgp
Description: PGP signature
On 2003-10-15 at 03:30:54 Brian J. Creasy wrote:
>> What version of sys/i386/i386/pmap.c do you have? If you are getting
>> the "pmap_zero_page: CMAP3 busy", it should be fixed by version 1.446,
>> which phk checked in 2003/10/12 10:55:45.
> __FBSDID("$FreeBSD: src/sys/i386/i386/pmap.c,v 1.447 2
Hi,
Today I had a -CURRENT machine panic on me with a page fault, and
something happened that I have seen before: the machine refused to
come up afterwards. Closer inspection revealed that the MBR on the
boot disk was totally zapped, filled with seemingly random characters.
Luckily the disk label
On 2003-10-31 at 21:29:42 Brooks Davis wrote:
> Ok, we're mostly clear. World builds, but I've had to disconnect
> ipfstat, ipnat, and ipftest from the build because they need
> modifications and are on vendor branch. IP Filter users may wish to
> wait to upgrade until this issue is resolve or t
1 - 100 of 884 matches
Mail list logo
