[webkit-dev] Strang problem with the linux port.

[Mike Emmel]

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.

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.



[memmel at debian 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))); }

         std::pair<iterator, bool> set(const KeyType &key, const
MappedType &mapped)
         { return m_impl.set((void *)(key), (void *)(mapped)); }
[memmel at debian kxmlcore]$


On 3/11/06, Mike Emmel <mike.emmel at gmail.com> 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 <mike.emmel at gmail.com> wrote:
> > On 3/9/06, Kimmo Kinnunen <kimmok at iki.fi> 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
> > > webkit-dev at opendarwin.org
> > > http://www.opendarwin.org/mailman/listinfo/webkit-dev
> > >
> >
>