libfdt: Add symbols to their corresponding versions #108
Conversation
|
Gah, I put them under the wrong version. |
787b599 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. Signed-off-by: Ernestas Kulik <ernestas@baltic.engineering>
ernestask
changed the title
|
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 |
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.
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 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. |
| fdt_stringlist_count; | ||
| fdt_stringlist_search; | ||
| fdt_stringlist_get; | ||
| fdt_resize; | ||
| fdt_get_max_phandle; |
There was a problem hiding this comment.
This symbol was changed into a header file inline in 1.6.0
787b599 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.