Visibility, I’m not yet satisfied

So, I think I talked some time ago of my efforts to make FFmpeg build with hidden visibility when available (GCC 4.1). I have in my overlay a patch that works for that svn snapshot, but unfortunately I think I opened a can of worms with that 🙂

Not like I didn’t expect something like this. One of the good things of visibility if that you know exactly what you’re going to show to your users, and especially when you first patch the visibility support you end up looking at what you want to export or not. Our story starts with some symbols declared but no more defined, and a lot of functions that should not be exported at all in the public header files.

Now, as I’m a known masochist (;)) I decided to start looking a bit more deeply into these functions so that they can be moved around and so on. I originally took a simple subversion checkout but handling the patches on that would be quite… difficult, considering that I will be working on the visibility patch and the series of side patches to get move around the declarations that has to be hidden.

Anyway, on Luca’s suggestion, I’m now trying to use git-svnimport to manage the sources locally, maybe this way I’ll be able to get around preparing some patches.. if I feel masochist enough I might end up trying to slim down the diff between xine-lib’s copy of ffmpeg and original ffmpeg.

I have to say that starting this way, my poor computer is really doing as much job as it can :/ having to compile parallel copies of ffmpeg, xine-lib, xine-ui and so on does not really take little time. I could use some new memory, but that’s anything but cheap now. If you want to help the cause by donating a few euros is of course welcome 😉 but I think now I really need to plan on taking some new job with enough money to put something a part to upgrade this box…

Oh, ffmpeg compiled without some of the not-to-be-exported symbols is now down to 179 symbols against the previous 229. Not bad at all!