Firefox Nightly

Jan Beich jbeich at vfemail.net
Thu Nov 26 14:07:14 UTC 2015


Irene Rüngeler <i.ruengeler at fh-muenster.de> writes:

>> Am 26.11.2015 um 10:14 schrieb Jan Beich <jbeich at vfemail.net>:
>> 
>> Michael Tuexen <tuexen at freebsd.org> writes:
>> 
>>> Dear all,
>>> 
>>> we are trying to compile Firefox Nightly on FreeBSD head and run
>>> into compile issues. Do you have any hints or documentation
>>> on how to compile Firefox from source? 
>>> Any pointers or hints appreciated...
>> 
>> |./mach boostrap; ./mach build| are supposed to be enough as long
>> as you stick to a simple or empty .mozconfig[1]. Documentation usually
>> goes directly to bugzilla.mozilla.org then dogfed to ports if affected.
>> 
>> With constant influx of new build issues writing about them elsewhere or
>> sitting on patches just doesn't scale. I'm no longer building and upstreaming
>> regularly, so things got out of whack. A not-so-quick buildtest revealed
>> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1228208
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1228227
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1228230
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1228255
>> 
>> The obvious hint: be prepared to deal with minor breakage.
>> 
>> [1] Non-default configurations are infested with even more issues e.g.,
>>    o --disable-pulseaudio doesn't build without --enable-alsa
>>    o --enable-system-sqlite doesn't build without --with-system-nss
>>    o --enable-system-cairo crashes with OMTC enabled
>>    o --enable-jemalloc crashes without "export MOZ_JEMALLOC4=1"
>>    o --enable-rust crashes with system jemalloc
> Hi Jan,
>
> thank you for your advice. I ran ./mach bootstrap and ./mach build with a mozconfig with just ac_add_options —enable-application=browser.

--enable-application=browser is default, see configure.in

  MOZ_ARG_ENABLE_STRING(application,
  [...],
  [ MOZ_BUILD_APP=$enableval ] )
  ...
  if test -z "$MOZ_BUILD_APP"; then
    MOZ_BUILD_APP=browser
  else
  ...

>
> I got the error message:
> /usr/include/c++/v1/typeinfo:72:7: error: visibility does not match previous declaration
> class _LIBCPP_EXCEPTION_ABI type_info
>        ^
>  /usr/include/c++/v1/__config:209:47: note: expanded from macro '_LIBCPP_EXCEPTION_ABI'
>  #define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
>                                                ^
>  /usr/home/ruengeler/firefox/config/gcc_hidden.h:6:13: note: previous attribute is here
>  #pragma GCC visibility push(hidden)
>              ^
>  nsToolkitCompsModule.o
>  1 error generated.
>
> Can you tell me what I can do to prevend this error?

Maybe try to apply patches listed in the upstream bugs quoted above.

Firefox builds everything with "hidden" visibility then explicitly
allowed headers are restored to "default" one[1]. It's a frequent source of
either linking or compilation issues. In desperate times you can jump on
OS X bandwagon by changing Darwin) to Darwin|FreeBSD) in the following

  $ cat configure.in
  ...
  if test "$GNU_CC" -a "$OS_TARGET" != WINNT; then
    case "$OS_TARGET" in
    Darwin)
      VISIBILITY_FLAGS='-fvisibility=hidden -fvisibility-inlines-hidden'
      ;;
    *)
      VISIBILITY_FLAGS='-I$(DIST)/system_wrappers -include $(MOZILLA_DIR)/config/gcc_hidden.h'
      WRAP_SYSTEM_INCLUDES=1
      ;;
    esac
  fi         # GNU_CC

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=273336
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 602 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-gecko/attachments/20151126/6f2f50a0/attachment.bin>


More information about the freebsd-gecko mailing list