64bit build errors

2011-12-06 Thread Da Rock
I'm trying to build some newer versions of ffserver. But I keep getting 
asm build errors when I get to libavcodec/vp*.


Error: `(%esi,%eax)' is not a valid 64 bit base/index expression

If I set it to build static it fails at h264.

"Error: `-1(%edi)'  is not a valid 64 bit base/index expression"

Googling hasn't proved helpful in finding an answer. I've tried setting 
some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, 
ebx, etc.


Any ideas how to fix this?

Cheers
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: strange printf(9) format specifier ("Z") in dev/drm code

2011-12-06 Thread Alexander Best
On Tue Dec  6 11, David Schultz wrote:
> On Sun, Dec 04, 2011, Alexander Best wrote:
> > ... i couldn't find a reference to an upercase "Z" in the printf(9) man 
> > page.
> > i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might
> > come from linux'es libc5 and is the equaivalent to glibc's "z".
> > 
> > can we adjust those lines, so the clang warnings disappear?
> 
> Yes, 'Z' is an alias for 'z' that is deprecated in glibc and
> unsupported in FreeBSD, so changing the case should fix it.

i guess turning the "Z"'s into "z"'s would be the best procedure then.

cheers.
alex
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: strange printf(9) format specifier ("Z") in dev/drm code

2011-12-06 Thread David Schultz
On Sun, Dec 04, 2011, Alexander Best wrote:
> ... i couldn't find a reference to an upercase "Z" in the printf(9) man page.
> i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might
> come from linux'es libc5 and is the equaivalent to glibc's "z".
> 
> can we adjust those lines, so the clang warnings disappear?

Yes, 'Z' is an alias for 'z' that is deprecated in glibc and
unsupported in FreeBSD, so changing the case should fix it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: CPUTYPE and friends, from 'make.conf' benchmark

2011-12-06 Thread Maxim Khitrov
On Tue, Dec 6, 2011 at 1:34 PM, Eitan Adler  wrote:
> 2011/12/6  :
>> # /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | 
>> grep mtune | sed -e 's/.*mtune=//'"
>> Test done once.
>
>> What do you think about this?
>
> As usual, it very well *may* be true, but please use ministat(1) to
> confirm. This requires more than one test. I'm not trying to be
> difficult - but statistics and benchmarking is non-trivial.

A few other good suggestions:

http://wiki.freebsd.org/BenchmarkAdvice

- Max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: CPUTYPE and friends, from 'make.conf' benchmark

2011-12-06 Thread Eitan Adler
2011/12/6  :
> # /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep 
> mtune | sed -e 's/.*mtune=//'"
> Test done once.

> What do you think about this?

As usual, it very well *may* be true, but please use ministat(1) to
confirm. This requires more than one test. I'm not trying to be
difficult - but statistics and benchmarking is non-trivial.

-- 
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: CPUTYPE and friends, from 'make.conf' benchmark

2011-12-06 Thread Chris Rees
On 6 Dec 2011 17:04,  wrote:
>
> # /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 |
grep mtune | sed -e 's/.*mtune=//'"
> generic
>
> For target machine, it returned 'generic'
>
> Now only with CPUTYPE in 'make.conf':
> --
> CPUTYPE?=core2
> --
>
> > Also, you should set these in src.conf.  Sticking them in make.conf is
> > going to annoy people when you ask why your ports are breaking ;)
> >
> > Chris
>
> I want my ports, to also be optimized for target CPU, not just base.
> None of my ports got broken yet.

I was referring to the other stuff, but CPUTYPE is fine, yes.

> Rebuilded can ...
>
> Tests are started AFTER a reboot!
> There is no bgfsck, as per rc.conf:
> --
> background_fsck=NO
> fsck_y_enable=YES
> fsck_y_flags=-C
> --
>
> Same multiuser enviroment
> Test done once.
>
> After running: '# time unixbench', final score was:
>395.4
> Completed in 22.8 min
>
> Time is SAME as with generic binaries, but score is just a 1.2 higher,
which is too small to be relevant.
> What do you think about this?
>

I think this is why most people don't bother with setting CPUTYPE ;)

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: CPUTYPE and friends, from 'make.conf' benchmark

2011-12-06 Thread rank1seeker
# /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep 
mtune | sed -e 's/.*mtune=//'"
generic

For target machine, it returned 'generic'

Now only with CPUTYPE in 'make.conf':
--
CPUTYPE?=core2
--

> Also, you should set these in src.conf.  Sticking them in make.conf is
> going to annoy people when you ask why your ports are breaking ;)
> 
> Chris

I want my ports, to also be optimized for target CPU, not just base.
None of my ports got broken yet.

Rebuilded can ...

Tests are started AFTER a reboot!
There is no bgfsck, as per rc.conf:
--
background_fsck=NO
fsck_y_enable=YES
fsck_y_flags=-C
--

Same multiuser enviroment
Test done once.

After running: '# time unixbench', final score was:
   395.4
Completed in 22.8 min

Time is SAME as with generic binaries, but score is just a 1.2 higher, which is 
too small to be relevant.
What do you think about this?



Domagoj Smolčić
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: boot0.S empty #ifdef

2011-12-06 Thread Gary Jennejohn
On Mon, 5 Dec 2011 12:54:15 -0800
some body  wrote:

> I sent this to freebsd-drives too but I think that might not be the right
> list for it so here it is: I am starting to learn how the kernel works and
> have started by going through the boot loader and I've noticed that between
> lines 21-32 in boot0.S there are some empty #ifdef statements. I was
> wondering a) where are these paramaters defined and if they are defined,
> what difference does it make since it looks like it doesn't change anything
> since they're empty?
> 
> 
> #ifdef SIO
> #endif
> 
> #ifdef CHECK_DRIVE
> #endif
> 
> #ifdef ONLY_F_KEYS
> #endif
>

These seem to be there to act as reminders for command line options which
can be used to build boot0.  They're also documented in Makefile.

These are actually used later in the code.

-- 
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"