Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 4/4/14, 11:01 am, Stefan Bruda wrote: At 00:54 +0200 on 2014-4-4 Martin Costabel wrote: I have also a patch for both of them that allows me to build webkit-1.0.2. I think the patch is non-toxic for previous build tools and OS versions, so I am just checking it in to CVS and wait what happens (webkit-1.0.2-1.2.7-6) :-) Indeed, it builds fine for me (Mac OS 10.8.5, Xcode command-line tools 5.1.0.0.1.1393). Many thanks! I have finally had the opportunity to try the build, and it built for me as well (OS X 10.9.2, Xcode 5.0.2, command-line tools 5.0.1). Thanks muchly! Mark D. McKean qpa...@quantumpanda.com -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
Hello, At 00:54 +0200 on 2014-4-4 Martin Costabel wrote: I have also a patch for both of them that allows me to build webkit-1.0.2. I think the patch is non-toxic for previous build tools and OS versions, so I am just checking it in to CVS and wait what happens (webkit-1.0.2-1.2.7-6) :-) Indeed, it builds fine for me (Mac OS 10.8.5, Xcode command-line tools 5.1.0.0.1.1393). Many thanks! Cheers, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass No HTML emails and proprietary attachments please http://bruda.ca/ascii -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 3/04/14 01:27, Mark D. McKean wrote:
On 4/2/14, 5:38 pm, Daniel Macks wrote:
But one on the previous tools is new information. Anyone with ideas is
welcome to contribute, anyone who wants to fix it is welcome to assist.
webkit-1.0.2-1.2.7-5 does not build for me with the latest xcode either.
Thsi is 5-year-old code, so it isn't surprising that it has more and
more problems with up-to-date OS and compiler versions. There are
several different problems mentioned on the list. The one shown here
[]
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/cctype:50:72:
error:
use of undeclared identifier
'isalnum_WTF_Please_use_ASCIICType_instead_of_ctype_see_comment_in_ASCIICType_h'
inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
isalnum(...
^
./JavaScriptCore/wtf/DisallowCType.h:57:17: note: expanded from macro
'isalnum'
#define isalnum isalnum_WTF_Please_use_ASCIICType_instead_of_ctype_see_c...
comes from libc++ on MacOSX 10.9. I don't know why it was not an error
on 10.9 back in December.
The other one was shown by Stefan Bruda:
In file included from WebCore/css/CSSComputedStyleDeclaration.cpp:24:
./WebCore/css/CSSComputedStyleDeclaration.h:36:52: error: friend declaration
specifying a default
argument must be a definition
friend PassRefPtrCSSComputedStyleDeclaration
computedStyle(PassRefPtrNode, bool allo...
^
./WebCore/css/CSSComputedStyleDeclaration.h:76:48: error: friend declaration
specifying a default
argument must be the only declaration
inline PassRefPtrCSSComputedStyleDeclaration computedStyle(PassRefPtrNode
node, bool all...
^
./WebCore/css/CSSComputedStyleDeclaration.h:36:52: note: previous declaration
is here
friend PassRefPtrCSSComputedStyleDeclaration
computedStyle(PassRefPtrNode, bool allo...
This one comes from the growing intolerance of clang and wasn't
forbidden in the previous version of xcode.
I am seeing both of these errors, too.
I have also a patch for both of them that allows me to build
webkit-1.0.2. I think the patch is non-toxic for previous build tools
and OS versions, so I am just checking it in to CVS and wait what
happens (webkit-1.0.2-1.2.7-6) :-)
--
Martin
--
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
System info:
Mac OS: 10.8.5
Package manager version: 0.36.3.1
Distribution version: selfupdate-rsync Wed Apr 2 09:07:17 2014, 10.8, x86_64
Trees: local/main stable/main
Xcode.app: 5.1
Xcode command-line tools: 5.1.0.0.1.1393561416
webkit-1.0.2-1.2.7-5 is set to build with only one job.
Failure:
CXXWebCore/css/libwebkit_1_0_la-CSSComputedStyleDeclaration.lo
In file included from WebCore/css/CSSComputedStyleDeclaration.cpp:23:
In file included from ./WebCore/config.h:115:
./JavaScriptCore/wtf/FastMalloc.h:224:1: warning: replacement function
'operator new' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void* operator new(size_t size) throw (std::bad_alloc) {
return fastMallo...
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:225:1: warning: replacement function
'operator new' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void* operator new(size_t size, const std::nothrow_t)
throw() { return f...
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:226:1: warning: replacement function
'operator delete' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void operator delete(void* p) throw() { fastFree(p); }
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:227:1: warning: replacement function
'operator delete' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void operator delete(void* p, const std::nothrow_t) throw()
{ fastFree(p); }
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:228:1: warning: replacement function
'operator new[]' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void* operator new[](size_t size) throw (std::bad_alloc) {
return fastMal...
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:229:1: warning: replacement function
'operator new[]' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void* operator new[](size_t size, const std::nothrow_t)
throw() { retur...
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:230:1: warning: replacement function
'operator delete[]' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void operator delete[](void* p) throw() { fastFree(p); }
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
./JavaScriptCore/wtf/FastMalloc.h:231:1: warning: replacement function
'operator delete[]' cannot be
declared 'inline' [-Winline-new-delete]
WTF_PRIVATE_INLINE void operator delete[](void* p, const std::nothrow_t)
throw() { fastFree(p); }
^
./JavaScriptCore/wtf/FastMalloc.h:200:47: note: expanded from macro
'WTF_PRIVATE_INLINE'
#define WTF_PRIVATE_INLINE __private_extern__ inline
__attribute__((always_inline))
^
In file included from WebCore/css/CSSComputedStyleDeclaration.cpp:24:
./WebCore/css/CSSComputedStyleDeclaration.h:36:52: error: friend declaration
specifying a default
argument must be a definition
friend PassRefPtrCSSComputedStyleDeclaration
computedStyle(PassRefPtrNode, bool allo...
^
./WebCore/css/CSSComputedStyleDeclaration.h:76:48: error: friend declaration
specifying a default
argument must be the only declaration
inline PassRefPtrCSSComputedStyleDeclaration computedStyle(PassRefPtrNode
node, bool all...
^
./WebCore/css/CSSComputedStyleDeclaration.h:36:52: note: previous declaration
is here
friend PassRefPtrCSSComputedStyleDeclaration
computedStyle(PassRefPtrNode, bool allo...
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 4/2/14, 12:00 pm, Stefan Bruda wrote: System info: Mac OS: 10.8.5 Package manager version: 0.36.3.1 Distribution version: selfupdate-rsync Wed Apr 2 09:07:17 2014, 10.8, x86_64 Trees: local/main stable/main Xcode.app: 5.1 Xcode command-line tools: 5.1.0.0.1.1393561416 webkit-1.0.2-1.2.7-5 is set to build with only one job. Okay, this makes, by my count, at least three of us who have posted about webkit-1.0.2-1.2.7-5 build failures, two on the March 10 Xcode tools and one on the previous tools, in just over two weeks (my own post on March 16, another on March 20, and now this one), and none of these posts have received any on-list responses from the package maintainer or anyone who might be able to offer any advice. Are messages containing webkit getting filtered out or something? I'm not trying to be accusatory--I just want to get this webkit update to build. I understand that the clang issue has grabbed most of the attention lately, but could someone please at least acknowledge that the webkit build failure is not just in our heads? Mark D. McKean qpa...@quantumpanda.com -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 4/2/14, 2:08 PM, Mark D. McKean wrote: On 4/2/14, 12:00 pm, Stefan Bruda wrote: System info: Mac OS: 10.8.5 Package manager version: 0.36.3.1 Distribution version: selfupdate-rsync Wed Apr 2 09:07:17 2014, 10.8, x86_64 Trees: local/main stable/main Xcode.app: 5.1 Xcode command-line tools: 5.1.0.0.1.1393561416 webkit-1.0.2-1.2.7-5 is set to build with only one job. Okay, this makes, by my count, at least three of us who have posted about webkit-1.0.2-1.2.7-5 build failures, two on the March 10 Xcode tools and one on the previous tools, in just over two weeks (my own post on March 16, another on March 20, and now this one), and none of these posts have received any on-list responses from the package maintainer or anyone who might be able to offer any advice. Are messages containing webkit getting filtered out or something? I'm not trying to be accusatory--I just want to get this webkit update to build. I understand that the clang issue has grabbed most of the attention lately, but could someone please at least acknowledge that the webkit build failure is not just in our heads? Mark D. McKean qpa...@quantumpanda.com (CCing people who reported this) How much are you paying? :-) But, seriously, not all maintainers have access to all platforms, which slows the ability to test updates. And not all maintainers are experts in the innards of the packages they maintain. When errors are due to sloppy declarations and the like in the source files, it can take a bit of tracking down to fix them properly, in my experience. Personally, I didn't reply because I was busy--I do see the same thing with 10.9/Xcode 5.1 but I don't really know how to fix it. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 4/2/14, 5:38 pm, Daniel Macks wrote: But one on the previous tools is new information. Anyone with ideas is welcome to contribute, anyone who wants to fix it is welcome to assist. Below my sig I've appended a copy of the email I sent to fink-users on March 16. This is on the 5.0 tools (Xcode 5.0.2, command-line tools 5.0.1), without the March 10 update--I have avoided installing the update because of all the clang issues that cropped up almost immediately. So my error messages are a little different from the others that were posted. Back in November, there had been an build issue with webkit-1.0.2-1.2.7-4 (posted to fink-users on Nov 10 by Kevin Horton, and to fink-beginners by myself). The error was different, but I couldn't explain what the difference is. That one was fixed by a patch submitted by Martin Costabel, who I've cc'ed here in the hopes that he might have an idea of how to proceed on this. I'd love to be able to help fix it, but I'm still a major newbie in this level of coding, so I don't have any idea where to begin trying to fix it. I'm more than happy to test things, though. Mark D. McKean qpa...@quantumpanda.com [First attempt to submit this was rejected as too large, so I've trimmed the install text to just the portion relating to JavaScriptCore, which is where the error occurred. Let me know if there are any other portions of the text that would be helpful.] After several days of no package updates coming through (because of the lack of rsync update propagation), I finally got wise and switched my updates to cvs. And now, I'm getting a compile failure on webkit-1.0.2-1.2.7-5. This initially happened after a selfupdate and update-all, after several other packages had been updated. I ran selfupdate and update-all again, and failed with the same error, again after several other packages were successfully updated. I will probably run update-all again overnight to clean up the packages that have not fully installed, but in the meantime I'm submitting this report now. I will point out up front that I am on OS X 10.9.2 and have *not* installed the March 10 updates to Xcode and the command-line developer tools. Relevant install text: CXXJavaScriptCore/interpreter/libJavaScriptCore_la-Interpreter.lo In file included from JavaScriptCore/interpreter/Interpreter.cpp:33: ./JavaScriptCore/runtime/Arguments.h:105:22: warning: 'JSC::Arguments::put' hides overloaded virtual function [-Woverloaded-virtual] virtual void put(ExecState*, unsigned propertyName, JSValue, Put... ^ ./JavaScriptCore/runtime/JSObject.h:106:22: note: hidden overloaded virtual function 'JSC::JSObject::put' declared here virtual void put(ExecState*, unsigned propertyName, JSValue value); ^ JavaScriptCore/interpreter/Interpreter.cpp:2045:28: warning: unused variable 'end' [-Wunused-variable] ScopeChainIterator end = scopeChain-end(); ^ JavaScriptCore/interpreter/Interpreter.cpp:2068:28: warning: unused variable 'end' [-Wunused-variable] ScopeChainIterator end = scopeChain-end(); ^ 3 warnings generated. CXXJavaScriptCore/bytecode/libJavaScriptCore_la-Opcode.lo CXXJavaScriptCore/bytecode/libJavaScriptCore_la-SamplingTool.lo CXXJavaScriptCore/debugger/libJavaScriptCore_la-DebuggerActivation.lo CXXJavaScriptCore/debugger/libJavaScriptCore_la-DebuggerCallFrame.lo CXXJavaScriptCore/assembler/libJavaScriptCore_la-ARMAssembler.lo CXXJavaScriptCore/assembler/libJavaScriptCore_la-MacroAssemblerARM.lo CXXJavaScriptCore/pcre/libJavaScriptCore_la-pcre_compile.lo CXXJavaScriptCore/pcre/libJavaScriptCore_la-pcre_exec.lo CXXJavaScriptCore/pcre/libJavaScriptCore_la-pcre_tables.lo CXXJavaScriptCore/pcre/libJavaScriptCore_la-pcre_ucp_searchfuncs.lo CXXJavaScriptCore/pcre/libJavaScriptCore_la-pcre_xclass.lo CXXJavaScriptCore/profiler/libJavaScriptCore_la-Profile.lo CXXJavaScriptCore/profiler/libJavaScriptCore_la-ProfileGenerator.lo CXXJavaScriptCore/profiler/libJavaScriptCore_la-ProfileNode.lo CXXJavaScriptCore/profiler/libJavaScriptCore_la-Profiler.lo CXXJavaScriptCore/interpreter/libJavaScriptCore_la-CallFrame.lo CXXJavaScriptCore/runtime/libJavaScriptCore_la-ExceptionHelpers.lo CXXJavaScriptCore/runtime/libJavaScriptCore_la-Executable.lo CXXJavaScriptCore/runtime/libJavaScriptCore_la-InitializeThreading.lo CXXJavaScriptCore/runtime/libJavaScriptCore_la-JSActivation.lo In file included from JavaScriptCore/runtime/JSActivation.cpp:32: ./JavaScriptCore/runtime/Arguments.h:105:22: warning: 'JSC::Arguments::put' hides overloaded virtual function [-Woverloaded-virtual] virtual void put(ExecState*, unsigned propertyName, JSValue, Put... ^ ./JavaScriptCore/runtime/JSObject.h:106:22: note: hidden overloaded virtual function
Re: [Fink-users] Failed: phase compiling: webkit-1.0.2-1.2.7-5 failed
On 4/2/14, 5:47 pm, Alexander Hansen wrote: How much are you paying? :-) For a fix or an acknowledgement of the existence of the issue? Hey, I'm not asking for a quick fix--just an acknowledgement that someone besides myself has read the report of an issue. We ask for help here because we don't know how to fix it ourselves. But, seriously, not all maintainers have access to all platforms, which slows the ability to test updates. Understandable. I'm more than happy to test updates on my platform. (Speaking of which, I apologize that I've not been able to test your patch for the clang problems from the other day. I've been immersed in a separate project for the past two weeks that has limited the time I can put into most other things. I've had time to read email and run updates, but that's about it. I should have the opportunity to test that by next week, though.) And not all maintainers are experts in the innards of the packages they maintain. When errors are due to sloppy declarations and the like in the source files, it can take a bit of tracking down to fix them properly, in my experience. Again, understandable. That's why I'm not looking for an instant fix on this or any other issue. I'm willing to wait for a fix, as long as I know that someone will be looking into it at some point. Not getting any acknowledgement or response from anyone on the fink side of things kind of makes us feel like we're just calling into the aether, hoping that someone somewhere is hearing us. Personally, I didn't reply because I was busy--I do see the same thing with 10.9/Xcode 5.1 but I don't really know how to fix it. And I wasn't necessarily expecting a reply from you specifically. I've been reading the lists--I see all the work you've been doing to deal with the clang problems Apple created, and I applaud you for it. Lately, you've made the phrase above and beyond seem inadequate. I wish I could afford to buy you a beer, at least. :-) But you can't do everything on your own. It seems like nine-tenths of the fixes here come from either you or Hanspeter. I wish I could jump in and take some of the load, but I've got a lot to learn before I would be of any real help in that regard. If you have any suggestions for other ways I could help with these things, though, I'm interested. Mark D. McKean qpa...@quantumpanda.com -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
