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

[Maciej Stachowiak]

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.
>
>
>
> [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))); }

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)); }
> [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
>>>>
>>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev