search

dgibson / dtc

Device Tree Compiler
215 stars 127 forks source link

libfdt: Add symbols to their corresponding versions #108

Closed ernestask closed 11 months ago

ernestask commented 1 year ago

787b599c8108f514645d9ee6256ee53dccc9db84 added the linker script with symbol versions, but, over time, new versions were not added, making versioning somewhat pointless. This commit aims to put symbols under versions they were introduced in. As a result, some previously-local symbols also become global.

ernestask commented 1 year ago

Gah, I put them under the wrong version.

ernestask commented 1 year ago

I’ve changed the topic of this PR and shuffled symbols around to match the versions they were introduced in, as now all of them will appear under LIBFDT_1.2. Wasn’t sure what to do with unreleased ones, so I put them under a fictitious 1.8 version.

dgibson commented 12 months ago

787b599 added the linker script with symbol versions, but, over time, new versions were not added, making versioning somewhat pointless.

Uh... yes and no. So, my understanding is that adding new symbols to an existing version is more or less safe. It's perhaps not the ideal way of doing things, but it will work: old clients expecting the old version obviously won't be using the new symbols, but newer programs expecting the newer versions will find them. We only break the symbol versioning if we change the signature for a symbol without adding a new symbol version.

This commit aims to put symbols under versions they were introduced in. As a result, some previously-local symbols also become global.

While it probably would have been neater if we'd done it this way all along, I think changing this now could break existing binaries using the shared library: a binary could have been built with a recentish libfdt (but before this change) so it is expecting to see a new symbol (say fdt_overlay_target_offset()) within the LIBFDT_1.2 version. That would then break when it tries to run against a shared library with this change, where that symbol has been moved to a newer version.

So while it would be reasonable to always add new symbols to new versions in future, I don't think we can move already versioned symbols around.