Firefox 13

Warren Block wblock at wonkity.com
Fri Jun 8 14:50:59 UTC 2012


On Fri, 8 Jun 2012, Olivier Smedts wrote:

> 2012/6/7 Warren Block <wblock at wonkity.com>:
>> On Thu, 7 Jun 2012, Niclas Zeising wrote:
>>
>>> On 2012-06-07 17:47, Warren Block wrote:
>>>>
>>>> Yesterday, Firefox 13 built and installed quickly.  It was just the
>>>> running part that did not go so well.  Coredumps on start, it would
>>>> start with add-ons disabled, but then coredump while typing a URL, or
>>>> sometimes a few seconds later.  Rebuilding everything Firefox depends on
>>>> did not make any difference.
>>>>
>>>> Firefox 12 builds and runs fine, as do Chromium and xxxterm.
>>>>
>>>> This is on 9-stable from yesterday, amd64.  The next step is to build
>>>> with debug symbols; I was hoping the problem would have been experienced
>>>> by someone else by now.  Any ideas?
>>>
>>>
>>> Which compiler did you use, clang or gcc, and if gcc, which version?
>>> Regards!
>>
>>
>> gcc46, and I do have CPUTYPE?=native in make.conf...
>>
>> Interesting!  Built without CPUTYPE set, Firefox seems fine.  Compiler bug?
>
> /usr/share/mk/bsd.cpu.mk doesn't support CPUTYPE?=native :
> % make -VMACHINE_CPU CPUTYPE=native
> unknown amd64 sse2 sse mmx
> % make -VMACHINE_CPU CPUTYPE=core2
> ssse3 sse3 amd64 sse2 sse mmx
>
> But you can use a supported value, add -march=native to your CFLAGS
> and COPTFLAGS, and set NO_CPU_CFLAGS=yes and NO_CPU_COPTFLAGS=yes so
> that another -march won't be automatically added.
>
> And if you use the old base-system gcc, -march=native won't give
> proper results with a Core2 and a Corei7 (not tested other recent
> CPUs) because they'll use -mtune=generic instead of the good -mtune. I
> prefer setting a proper -march.
>
> I don't know if thta's related to your firefox problem though.

With CPUTYPE?=core2, Firefox 13 works fine.  That "native" setting has 
been in my make.conf for a long time, but this is the first time it ever 
caused a problem.


More information about the freebsd-ports mailing list