On Mar 11, 2006, at 11:05 AM, Mike Emmel wrote:
After making the change below and upgrading the port I now compile
and run under
gcc-3.4 (GCC) 3.4.5 (Debian 3.4.5-1)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
We're not really maintaining gcc 3.x support for WebKit - lots of
things are likely not to work right. I recommend working with gcc 4.x
instead.
I'll try 4.1.0 later. I think change is okay since the real type will
be picked up on the template return value but dunno for sure.
[EMAIL PROTECTED] kxmlcore]$ svn diff HashMapPtrSpec.h
Index: HashMapPtrSpec.h
===================================================================
--- HashMapPtrSpec.h (revision 13261)
+++ HashMapPtrSpec.h (working copy)
@@ -204,7 +204,7 @@
iterator find(const KeyType& key) { return m_impl.find((void
*)(key)); }
const_iterator find(const KeyType& key) const { return
m_impl.find((void *)(key)); }
bool contains(const KeyType& key) const { return
m_impl.contains((void *)(key)); }
- MappedType get(const KeyType &key) const { return
reinterpret_cast<MappedType>(m_impl.get((void *)(key))); }
+ MappedType get(const KeyType &key) const { return
(MappedType)(m_impl.get((void *)(key))); }
I'm not sure it is a good idea to change a reinterpret_cast to a C-
style cast. It was a bug in gcc 3.x that it made this error apply to
casting between void* and a function pointer.
Regards,
Maciej
std::pair<iterator, bool> set(const KeyType &key, const
MappedType &mapped)
{ return m_impl.set((void *)(key), (void *)(mapped)); }
[EMAIL PROTECTED] kxmlcore]$
On 3/11/06, Mike Emmel <[EMAIL PROTECTED]> wrote:
I switched to gcc3.4 checking for compiler bugs and here is the
error I got
dom/NodeImpl.h:525:8: warning: extra tokens at end of #endif
directive
../build/include/JavaScriptCore/HashMapPtrSpec.h: In member function
`Q* KXMLCore::HashMap<P*, Q*, KXMLCore::PtrHash<P*>,
KXMLCore::HashTraits<P*>, KXMLCore::HashTraits<Q*> >::get(P* const&)
const [with P = WebCore::AtomicStringImpl, Q =
KXMLCore::PassRefPtr<WebCore::HTMLElementImpl> ()(const
WebCore::AtomicString&, WebCore::DocumentImpl*,
WebCore::HTMLFormElementImpl*, bool)]':
khtml/html/htmlfactory.cpp:425: instantiated from here
../build/include/JavaScriptCore/HashMapPtrSpec.h:207: error: ISO C++
forbids casting between pointer-to-function and pointer-to-object
gcc-3.4 (GCC) 3.4.5 (Debian 3.4.5-1)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Trying 4.1.0 now...
Mike
On 3/9/06, Mike Emmel <[EMAIL PROTECTED]> wrote:
On 3/9/06, Kimmo Kinnunen <[EMAIL PROTECTED]> wrote:
Mike Emmel wrote:
Hi all I'm having a strange problem with the linux port and maybe
someone can help.
The problem is that the macros in
khtml/html/htmlnames.cpp fail under linux
I dumped the cpp code and I'm getting generated code like the
following.
new ((void*)&abbrTag) QualifiedName(nullAtom, "abbr", xhtmlNS);
Now when I looked at the constructor for QualifiedName it takes
as args
QualifiedName::QualifiedName(const AtomicString& p, const
AtomicString& l, const AtomicString& n)
I've experienced this. I think it's g++-4.0 inlining bug.. It
happened
for me also, exactly at "abbr" tag..
Yep thats one of them :)
In dom_qname.cpp (I don't know if this has been renamed) there's
a hash
function
inline unsigned hashComponents(const QualifiedNameComponents& buf)
which I believe will get optimized somehow wrong, and it always
hashes
to zero. I got it working by adding printf("%x", hash); before
the zero
comparison :)
Doesn't make sense unless the printf disables some optimization.
In my
old code there seems also to be 0x80000000u instead of 0x80000000,
which I believe was some sort of hazard at trying to make sure that
signedness+bigendian/little endian differences don't matter..
I know this sounds rediculous, but try it if you don't have any
other
clues. My compiler was (GCC) 4.0.2 20050728 (prerelease)
[FreeBSD]..
Kimmo
So out of that whats the fix for this did you figure out a
workaround.
I'm even more puzzled.
Mike
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
