2010/6/2 Andrius Morkūnas :
> On Wed, 02 Jun 2010 18:23:19 +0300, Alexander Best
> wrote:
>>
>> it seems for some reason gcc44 gets chosen at some point as compiler
>> instead of the base gcc. i DO have CC, CXX and CPP defined in my
>> /etc/make.conf so that gcc44
rse commenting out those variables in
/etc/make.conf fixes the problem, but if i'm not mistaken 'buildworld'
should use /etc/src.conf at all times and thus should be aware that i
want it to use base gcc.
i've attached my make.conf and src.conf.
cheers.
--
Alexander Best
make.conf
D
On Wed, May 12, 2010 at 3:46 AM, Bernd Walter wrote:
> On Tue, May 11, 2010 at 10:15:13PM +0200, Alexander Best wrote:
>> i've posted a log here which is pretty self explanatory:
>>
>> http://pastebin.com/tn3NiDDW
>>
>> On Tue, May 11, 2010 at 10:13 PM, Alex
i've posted a log here which is pretty self explanatory:
http://pastebin.com/tn3NiDDW
On Tue, May 11, 2010 at 10:13 PM, Alexander Best
wrote:
> the problem is getting more awkward.
>
> if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a
> specific sect
ada0p1
label/swap N/A ada0p2
label/rootfs N/A ada0p3
cheers.
On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol wrote:
> On 3/29/10, Alexander Best wrote:
>> hi there,
>>
>> when doing fsck on my
Jaakko Heinonen schrieb am 2010-04-23:
> On 2010-04-23, Alexander Best wrote:
> > has anybody thought about adding scsi support to burncd(8)? i've
> > been using
> > ATA CAM for quite a while now and really love it. however i miss
> > burncd(8).
> I have tho
gt; > > buffer.c
> > > and
> > > compile them accordingly. Redo your tests till we know the single
> > > function(s)
> > > where clang produces bad code.
[snip]
--
Alexander Best
___
freebsd-current@freebsd.org
cam(4) i
guess the fate of ata(4) dependant binaries in the base should also be
discussed.
maybe somebody could put together a list of ata(4) dependant binaries
currently in base in addition to burncd(8) and atacontrol(8)?
--
Alexander Best
___
fr
Ulrich Spörlein schrieb am 2010-04-22:
> On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > > On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > > > Roman Divacky schrieb am 2010-04-21:
> >
Andrew Reilly schrieb am 2010-04-22:
> On Wed, Apr 21, 2010 at 05:23:38PM +0200, Roman Divacky wrote:
> > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote:
> > > i might have stumbled upon a problem with clang. i've compiled a
> > > kernel from
&g
Roman Divacky schrieb am 2010-04-21:
> On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > [snip]
> > > 1) cd modules/sound/sound && make CC=gcc
> > after this step these are the sizes of sound.ko*
Roman Divacky schrieb am 2010-04-21:
> On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > [snip]
> > > 1) cd modules/sound/sound && make CC=gcc
> > after this step these are the sizes of sound.ko*
Roman Divacky schrieb am 2010-04-21:
> On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > [snip]
> > > 1) cd modules/sound/sound && make CC=gcc
> > after this step these are the sizes of sound.ko*
all
and after this step:
-rw-r--r-- 1 root wheel 187480 Apr 21 21:37 sound.ko
-rw-r--r-- 1 root wheel 872983 Apr 21 21:37 sound.ko.debug
-rw-r--r-- 1 root wheel 792856 Apr 21 21:37 sound.ko.symbols
so quite some code is missing it seems.
[snip]
--
Alexander Best
Roman Divacky schrieb am 2010-04-21:
> On Wed, Apr 21, 2010 at 07:22:00PM +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote:
> > > > i might have stumbled upon a problem with
Roman Divacky schrieb am 2010-04-21:
> On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote:
> > i might have stumbled upon a problem with clang. i've compiled a
> > kernel from
> > the clang branch using `make kernel INSTKERNNAME=clang` and booted
> > f
disabled=1) gives me a system freeze.
--
Alexander Best
___
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"
Eitan Adler schrieb am 2010-04-20:
> > i was also wondering: what's the reason gcc is still being used
> > during step
> > "Building an up-to-date make(1)" and not clang?
> because make segfaults when using clang ;)
ah ok. that's qu
Roman Divacky schrieb am 2010-04-19:
> you have to use -O2
thanks a lot. using -O2 worked. :)
i was also wondering: what's the reason gcc is still being used during step
"Building an up-to-date make(1)" and not clang?
cheers.
> On Mon, Apr 19, 2010 at 02:29:07PM +0200,
* Error code 1
Stop in /usr/local/src/clangbsd/libexec.
*** Error code 1
Stop in /usr/local/src/clangbsd.
*** Error code 1
Stop in /usr/local/src/clangbsd.
*** Error code 1
Stop in /usr/local/src/clangbsd.
running llvm-devel-2.7.r100430 and clangbsd revision 206838.
--
Alexander Best
___
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"
tput of `dmesg -a|grep ada0`:
ada0 at ahcich2 bus 0 scbus3 target 0 lun 0
ada0: ATA-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C)
--
Alexander Best
_
Rui Paulo schrieb am 2010-03-26:
> On 26 Mar 2010, at 17:24, Alexander Best wrote:
> > hi there,
> > `netstat -i` reports:
> > NameMtu Network Address Ipkts Ierrs Idrop
> > Opkts
> > Oerrs Coll
> > ath0 2290 00:0f:b5:82
HEAD (r205561) on amd64. this is my card:
a...@pci0:5:1:0:class=0x02 card=0x5a001385 chip=0x0013168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = '802.11a/b/g Wireless Adapter (AR2312)'
class = network
subclass = eth
Scot Hetzel schrieb am 2010-03-23:
> On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best
> wrote:
> > i don't think conf/112997 and the issue where gcc segfaults are
> > directly
> > related to each other:
> > 1. if CPUTYPE is set to 'native' your pa
l -o /dev/null
> -mtune=generic
hmm...that's odd indeed. i finally was able to do some debugging. i've
attached two files:
running gcc -v -x c -E -mtune=native /dev/null and gcc -v -x c -E
-mtune=nocona /dev/null
> Peg
--
Alexander Best
`gdb -v -x c -E -mtune=native /dev/nul
ative
amd64 sse2 sse
otaku% make -V MACHINE_CPU -DCPUTYPE=nocona
amd64 sse2 sse
otaku% make -V MACHINE_CPU -DCPUTYPE=i386
amd64 sse2 sse
otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala
amd64 sse2 sse
..oh and of course i ran these commands with no C
Andriy Gapon schrieb am 2010-03-22:
> on 22/03/2010 00:12 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 23:11 Alexander Best said the following:
> >>> *hehe* that makes more sense. well i already sent you lp.
> &
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 23:11 Alexander Best said the following:
> > *hehe* that makes more sense. well i already sent you lp.
> > unfortunately str is
> > not available to gdb:
> > (gdb) print str
> > Variable "str" is not
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 20:46 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 14:53 Alexander Best said the following:
> >>> *lol* sorry. ;)
> >> No worries.
> >> BTW, whe
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 14:53 Alexander Best said the following:
> > *lol* sorry. ;)
> No worries.
> BTW, when that rash happens, are you able to examine the core with
> gdb?
> Is it possible to examine values of 's' and 'p'
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 14:35 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 13:43 Garrett Cooper said the following:
> >>> Works for me *shrugs*:
> >>> $ gcc -v -x c -E
ative
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
alex
> CPUTYPE?=core2
> NO_CPU_CFLAGS=
> CFLAGS= -mtune=native -O2 -fno-strict-aliasing -pipe -s
> Peg
--
Alexander Best
___
freebsd-current@free
Garrett Cooper schrieb am 2010-03-21:
> On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best
> wrote:
> > Garrett Cooper schrieb am 2010-03-21:
> >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
> >>
> >> wrote:
> >> > ok. i think i finally s
Garrett Cooper schrieb am 2010-03-21:
> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
> wrote:
> > ok. i think i finally solved this riddle. the cause for the problem
> > seems to
> > have been my CPUTYPE in /etc/make.conf. it is set to 'native'.
> >
ok. i think i finally solved this riddle. the cause for the problem seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
been using the 'native' keyword for years now and never had any problems with
it, but it seems a recent commit broke 'native' as CPUTYPE. for me
i still haven't been able to do a buildworld without cc segfaulting. :(
if i repeat the cc operation that segfaulted during buildworld with cc under
/usr/bin everything works fine. the segfault only occurs during buildworld
with the bootstrapped version of cc under /usr/ob/usr/src/tmp/usr/bin/cc.
pt in that directory
4. and replaced /etc with the backup version
yet gcc still segfaults during buildworld. :(
thanks go out to delphij, nox---, jilles, garrcoop, x6b and joerg on #bsddev
for helping me with this problem. :)
--
Alexander Best
___
freeb
hi there,
i'm having similar issues with libc. while doing buildworld i got this
segfault:
>>> stage 4.2: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE=native GROFF_BIN_PATH=/us
301 - 338 of 338 matches
Mail list logo
