CPUTYPE?=native no longer safe

wblock@

wblock@

Developer
...and maybe it never was, but many of us used it without problems. I did, anyway, up until Firefox 13. On a Core i5, Firefox 12 was completely solid. Firefox 13 was exactly the opposite, coredumping on startup, or running a few seconds and then dying. It would run in "safe mode" with extensions disabled, but not reliably.

After posting a question on the freebsd-questions mailing list, I commented out CPUTYPE in /etc/make.conf and suddenly Firefox 13 was fine.

Olivier Smedts identified the problem: http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/075728.html

Firefox 13 is fine with CPUTYPE?=core2. It's just native that's a problem.
 
That's interesting. I posted a while ago that one of the ports did not want to run with core2 but I managed to run it with native.

Today I don't see any point in setting any flags unless there's a really good reason. And for average user there isn't.
 
Ah, I had the exact same problems with Firefox 13 and Thunderbird 13. I had to make packages for both on a different system that did not have these problems to get them to work again on the system that segfaulted/abort-trapped/coredumped (I've seen variations). And indeed, I had a dusty old 'native' in my make.conf.
 
I would say it's definitely not safe at all. I have been using "Athlon64" on previous builds (version <10) and this has been working fine on transmission (giving errors on a required library). I changed it to "athlon64-sse3" as a trial and it worked fine.

1. Does anyone know of similar experiences with other ports?

2. Is it better/recommended to not use CPUTYPE at all?

Thanks :)
 
The real problem is that Firefox does not work when compiled with AVX support. The solution is quite simple:

Code: 
% grep native /etc/make.conf; echo; grep -A1 -B1 avx /etc/make.conf                              
CPUTYPE?=native

.if !empty(.CURDIR:M/usr/ports/www/firefox)
  CFLAGS+= -mno-avx
.endif
%
 
But I just tried using "native" when compiling Transmission-daemon and one of the required libraries is giving weird behavior. I tried none and "athlon64-ss3" and no such problem.

All I'm saying is that the "native" problem is not limited to Firefox.
 
Performance gains by compiler optimization are quite neglible in most cases. One could say that if you trust the compiler to optimize your code you're not a programmer at all. The only time when you want to set CPUTYPE is when autodetection of CPU capabilities is not working for some reason, for example detection of special instruction sets that can be used for very fast CPU-assisted encryption.
 
You must log in or register to reply here.
Back
Top