29 April 2005
I have been in Sydney for the past week for UDU, which wraps up tomorrow. It has been great meeting up with everyone again, but has also been exhausting.
Some of the stuff on the horizon will be quite ground breaking. For instance, I don't think anyone has attempted something like Grumpy Groundhog (which will hopefully be very useful to both the distro team, and upstream projects like Gnome).
Experimented with using the new ELF visibility attribute support in GCC
4 in Python, and came up with this
restricts the list of exported symbols to just the ones marked with the
PyAPI_DATA markers, which omits all the private
In addition, it uses "protected" visibility for all the exported symbols, which means that internal calls to the public Python API don't have to go through the PLT (which they do if Python is compiled as a shared library).
In the shared
libpython case, this speeds things up by about 5%
which isn't too bad for a small patch. In the static
it seems to slow things down slightly -- by < 1% in my tests so far.
Of course, the shared
libpython case is still slower than the static
version (which is why
/usr/bin/python doesn't use a shared
libpython on Ubuntu), but it does make it
less slow than it was before
Glynn: If Solaris feels like a second class citizen, it is probably because hardly any hackers have access to Solaris machines (the same seems to be true of architectures other than i386). A fair number of developers would probably be interested in fixing Solaris build failures if they knew that they existed.
I realise that Sun doesn't want to provide external access to a build machine (at least, that's what I was told last time I asked some Sun/Gnome hackers), but maybe running a tinderbox style system and publishing the build logs would help. As well as telling me if my package is broken, it'd give me a way to tell whether the fixes I check in actually solve the problem.