[vlc-devel] [RFC] Slimming LibVLC down

[Rémi Denis-Courmont]

Le mardi 2 février 2010 18:30:02 Pierre d'Herbemont, vous avez écrit :
> 2010/2/1 Rémi Denis-Courmont <remi at remlab.net>:
> > There are exactly *two* ways to link:
> >  - dynamically (then you are wrong),
> 
> See above. (Actually you can weak link, do a dynamic lookup. Darwin
> specific, true. See below. and that's probably the reason why I am not
> on the same line.)

If a piece of software is built and uses a symbol (say *before* it gets 
deprecated), and then that you remove the symbol, you are screwed. Either you 
crash when loading the application, or when the application actually invokes 
the removed function.

Ultimately, you cannot actually remove the function. Weak linking is 
irrelevant (and yes, you *can* link weakly on Linux). You still need some to 
proovide the symbol, and that symbol to abide by the semantics that the old 
applications expect.

> >  - statically (then it is irrelevant).
> 
> It is.

Static linking is not relevant because it is inherently proof against binary 
breaks.

> > You can't do that. For the umpteenth time, removing an exported function
> > breaks compatibility. That's just how dynamic link resolution works.
> 
> It won't break dynamic link resolution! (Ok, I am darwin specific
> here, and that explain my reasoning about deprecation. I am surprised
> that linux toolchain is not supporting this by default.)

It does.

> So works out of the box on darwin. And this is how deprecated symbols
> should be handled there. But it's true that on darwin, you generally
> embed your framework, and a system symbols deprecation let you fix it
> for 2 years before removing it.

You can do that on Linux. But the library version numbers are linear (so are 
they on Darwin). So you will need to violate the common rules on library 
version numbers (see libtool documentation). And that will break any 
application that failed to adapt. Then you will piss off lots of people. And 
then maybe some people will start forking your software with "fixed" version 
numbers, which is the worse possible outcome.

Normally, when you ship a new version of the library, you increase the version 
number *precisely* so that you can run old software (with the old version) and 
new software (with the new version) on the same system. (As a side note, this 
wouldn't work for libvlccore because the plugin directory path has no version 
number.)

And then of course, more advanced packaging systems may track symbols.
The whole point is to prevent people from doing what you suggest (for a 
reason).

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis