Patches for OpenSolaris

[Ian Monroe]

On Wed, Jan 21, 2009 at 3:21 PM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> On Wed, Jan 21, 2009 at 2:33 PM, Adriaan de Groot <groot at kde.org> wrote:
>> Here at CampKDE I showed the Amarok dudes how it would run on OpenSolaris; it
>> does take a fistful of patches (mostly simple ones). Casey suggested I
>> actually send them in instead of blogging only :)
>>
>> The three const-match patches make declaration and definition of various
>> methods match in terms of constness; gcc thinks this is fine, but for
>> compliers that consider constness in resolution or linking, this is a problem.
>>
>> Free is in <stdlib.h> and doesn't necessarily live in the :: namespace.
>>
>> The findmysql one is possibly not suitable for inclusion -- it adds some more
>> search paths and things to find MySQL in the default install locations on
>> Solaris.
>
> Our findmysql.cmake is pretty nutty.  I think we need to list standard
> locations and expect places that don't install it to the standard
> location to simply do cmake -DMYSQL_LIBRARIES=blahblahblah.  This
> seems to be the standard route to handle this, I'm not sure why
> findmysql.cmake is being treated differently (not by you, by us...)

I guess the fork is a bit historical since I wanted it to make it easy
to build Amarok from an uninstalled MySQL. That didn't actually work.
We could just delete FindMySQLAmarok, but meh.

>>
>> The md5 code uses the linux kernel types u_int32_t instead of standard integer
>> types like uint32_t.
>
> This is external code... though I'm not sure if it's actually being
> maintained, if it is you might want to see about getting it included
> there (though the last time we updated this code was a forever ago...
>>
>> namespace foo { extern bar; } gives me a foo::bar symbol instead of a ::bar
>> symbol, so the namespace patch moves one extern around.
>>
>> The scriptengine has some constness issues and a ; too many. I think Casey has
>> already committed that last one.
>
> These should be submitted to the qtscriptgenerator project upstream as
> well, or they will go away the next time we update the
> scriptgenerator.

http://code.google.com/p/qtscriptgenerator/issues/detail?id=27

Ian