webkit-gtk 2.0.4 upgrade error: excess elements in struct initializer

[deesto (John S. De Stefano Jr.)]

I'm told this error is unique from the others being posted currently. See: ticket:39598#comment:75 ticket:39598#comment:77

2 warnings generated.
Source/WTF/wtf/FastMalloc.cpp:4927:7: error: excess elements in struct initializer
    , 0, 0, 0, 0 // These members will not be used unless the zone advertises itself as version seven or higher.
      ^
2 warnings and 1 error generated.
make: *** [Source/WTF/wtf/libWTF_la-FastMalloc.lo] Error 1
make: *** Waiting for unfinished jobs....
In file included from Source/WTF/wtf/GregorianDateTime.cpp:25:
In file included from ./Source/WTF/config.h:30:
In file included from ./Source/WTF/wtf/Platform.h:338:
/opt/local/include/AvailabilityMacros.h:108:14: warning: '__i386__' is not defined, evaluates to 0 [-Wundef]
        #if (__i386__ || __x86_64__) && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < MAC_OS_X_VERSION_10_4)
             ^
/opt/local/include/AvailabilityMacros.h:110:15: warning: '__ppc64__' is not defined, evaluates to 0 [-Wundef]
        #elif __ppc64__ && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < MAC_OS_X_VERSION_10_4)
              ^
mv -f Source/WTF/wtf/.deps/libWTF_la-DateMath.Tpo Source/WTF/wtf/.deps/libWTF_la-DateMath.Plo
2 warnings generated.
mv -f Source/WTF/wtf/.deps/libWTF_la-GregorianDateTime.Tpo Source/WTF/wtf/.deps/libWTF_la-GregorianDateTime.Plo
offlineasm: offset extractor DerivedSources/JavaScriptCore/LLIntDesiredOffsets.h successfully generated.
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_www_webkit-gtk/webkit-gtk/work/webkitgtk-2.0.4'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_www_webkit-gtk/webkit-gtk/work/webkitgtk-2.0.4" && /usr/bin/make -j4 -w all CC="/usr/bin/gcc-4.2 -arch x86_64" V=1 
Exit code: 2
Error: org.macports.build for port webkit-gtk returned: command execution failed
DEBUG: Error code: CHILDSTATUS 26729 2
DEBUG: Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Warning: targets not executed for webkit-gtk: org.macports.install org.macports.build org.macports.destroot

Also wondering why google-test is suddenly a requirement for some ports, and others won't build while it's active?

Thanks.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainer(s).

[cooljeanius (Eric Gallager)]

Also wondering why google-test is suddenly a requirement for some ports, and others won't build while it's active?

Well for the llvm ports it's because they include their own bundled copies of gtest...

[jeremyhu (Jeremy Huddleston Sequoia)]

/opt/local/bin/clang++-mp-3.3 -DHAVE_CONFIG_H -I. -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -DBUILDING_CAIRO__ -DBUILDING_GTK__ -I./Source -I./Source/WTF -I./Source/WTF/wtf -DGTEST_USE_OWN_TR1_TUPLE=1 -fno-rtti -fstrict-aliasing -O3 -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include -pipe -Os -Wno-c++11-extensions -arch x86_64 -Wno-c++11-compat -O2 -MT Source/WTF/wtf/libWTF_la-GregorianDateTime.lo -MD -MP -MF Source/WTF/wtf/.deps/libWTF_la-GregorianDateTime.Tpo -c Source/WTF/wtf/GregorianDateTime.cpp  -fno-common -DPIC -o Source/WTF/wtf/.libs/libWTF_la-GregorianDateTime.o

Source/WTF/wtf/FastMalloc.cpp:4927:7: error: excess elements in struct initializer
    , 0, 0, 0, 0 // These members will not be used unless the zone advertises itself as version seven or higher.
      ^

That seems to indicate that you're using an <Availability.h> from >= Lion and <malloc/malloc.h> from SnowLeopard.

It looks like you're on SnowLeopard, so the issue is that you have a newer <Availability.h> than you should have... probably because of the installation of the CarbonHeaders port.

I *STRONGLY* disapprove of these ports (CarbonHeaders, libc-headers, etc) and will not fix this issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

IMO, the only sane solution to this issue is the removal of ports which are conflicting with the system SDK. There is absolutely no need for them except for cases where they are needed for newer toolchains (eg: cctools_headers for newer mach o load commands).

[deesto (John S. De Stefano Jr.)]

Replying to jeremyhu@…:

That seems to indicate that you're using an <Availability.h> from >= Lion and <malloc/malloc.h> from SnowLeopard.

It looks like you're on SnowLeopard, so the issue is that you have a newer <Availability.h> than you should have... probably because of the installation of the CarbonHeaders port.

I *STRONGLY* disapprove of these ports (CarbonHeaders, libc-headers, etc) and will not fix this issue.

Correct: I'm on 10.6.8, and recently installed CarbonHeaders _only_ to correct a build problem with another port, and only at the recommendation of that port's maintainer; otherwise I would have been stuck with another broken port. I had to do this with google-test as well in order for yet another port to build. I don't recall having to deal with such issues and dependencies before upgrading base to 2.2.x.

[larryv (Lawrence Velázquez)]

Replying to deesto@…:

Correct: I'm on 10.6.8, and recently installed CarbonHeaders _only_ to correct a build problem with another port, and only at the recommendation of that port's maintainer; otherwise I would have been stuck with another broken port. I had to do this with google-test as well in order for yet another port to build.

Those ports are broken on 10.6 then. Installing CarbonHeaders is a hack. You should probably deactivate or uninstall it until the next time you need it.

I don't recall having to deal with such issues and dependencies before upgrading base to 2.2.x.

I don’t see how base has anything to do with this. You are using broken ports. Do you recall which ones you needed to install CarbonHeaders for (and the relevant tickets or mailing list threads, if any)?

[deesto (John S. De Stefano Jr.)]

Replying to larryv@…:

I don’t see how base has anything to do with this. You are using broken ports. Do you recall which ones you needed to install CarbonHeaders for (and the relevant tickets or mailing list threads, if any)?

clang-3.3:

​https://trac.macports.org/ticket/39605#comment:1

Given, this ticket was closed as invalid and clearly the use of CarbonHeaders is contended there, but it's also clear that installing and activating it helped more than one other user to get the port installed. I had no problems with "missing" headers or like upgrade problems until something changed with clang/llvm. If CarbonHeaders isn't a viable fix, what is?

[mf2k (Frank Schima)]

The CarbonHeaders port no longer exists.

[deesto (John S. De Stefano Jr.)]

Replying to mf2k:

The CarbonHeaders port no longer exists.

Perhaps because this ticket's last activity was four years ago, and it remained unresolved? This is some disappointing, RH-esqe triage.