route: add missing rtnl_nh_get_oif symbol

[KanjiMonster]

When nh support was added in 780d06a ("route: add nh type"), rtnl_nh_get_oif() was missed adding to libnl-route-3.sym.

Add the missing symbol so it can be actually used.

Fixes: 780d06a ("route: add nh type")

[KanjiMonster]

I added them alongside the other rtnl_nh_* as that is when they were added, though I'm not sure if this is the right place to add them, or if they should be in libnl_3_12.

 /usr/bin/ld: rtnl_nh_dump: undefined version: libnl_3_8
/usr/bin/ld: rtnl_nh_clone: undefined version: libnl_3_8

That took me a while to reproduce. So these functions actually don't exist.

[KanjiMonster]

Ah, a commit post 3.11 dropped the definitions, that explains it (started working on this based on 3.11). Dropped and updated.

[thom311]

The linker symbols help with versioning. For example, RPM package dependencies automatically tracks when a certain package requires libnl@libnl3_12 symbol. This means, you can never add a symbol to e.g. libnl3_7 after 3.7 is released.

The correct solution is to add the symbols now to libnl3_12 (the bottom of the file). There is no going back in time to fix 3.7. This is fine, and the right solution.

3.12 because that is the next upcoming release.

Add a new libnl3_12 section, if it doesn't exist yet.

[KanjiMonster]

Well, one could do a 3_8_1 that fixes it ;P

But unless that happens, I guess 3_12 is the next best thing.

[thom311]

Well, one could do a 3_8_1 that fixes it ;P

Yes, but I don't maintain a 3.8 stable branch, so we would never do a release that only brings libnl3_8_1 without libnl3_12.

If we would maintain old-stable branches then yes. Because then the set of libnl3_8_1 could be backported individually (when backporting symbols, we must backport all symbols of a certain libnl3_X version).

[KanjiMonster]

Righto. Anyway, moved it to libnl3_12, and made it based on libnl3_11, not libnl3_10 *coughs*.

[thom311]

merged as 470c0a6

thank you!!!