3 ms·

I’m not sure I understand how this would help? When linking the main application there will be two component .a files linked into it, that both contain referenc

I’m not sure I understand how this would help? When linking the main application there will be two component .a files linked into it, that both contain references to symbols that should be resolved to something in a liblua.a, so that needs to be linked along as well, but one component needs to resolve them to liblua.a from Lua 5.2, the other to liblua.a from 5.0. Most (but not all) of the Lua symbols from both versions have the same names. How can objcopy resolve this? Multi-pass linking or something like that?

Joker_vD 6y ago
You rename things in liblua.a from version 5.0. to something different (append __5.0 to names or something), then in the .a file that should link to version 5.0, you rename all missing Lua symbols too. Then you link all this together: main.o component_for_lua5.0.a (modified: referenced Lua symbols renamed) component_for_lua5.2.a (with symbols left intact) liblua.a (from version 5.0, modified: symbols renamed) liblua.a (from version 5.2, its symbols left intact) There should be no more name collisions.
- w0utert 6y ago
  Aha got it, thanks! Like you said it’s not pretty but it works, and somewhat better than the abomination they came up with instead, which involved building only the minimal part that depended on the new Lua 5.2 as shared library, then making fake shared libraries for all remaining unsatisfied symbols referenced from it to trick the linker, and compiling them in statically instead like they used to do before. Hard to explain, don’t ask me why they did it... :-/ Edit: there is one pretty glaring downside to this approach though, which is that both the component we need to patch up with renamed symbols and the liblua.a are also used in other places, so they would either have to be built differently depending on the application, or we would have to maintain multiple versions of the same 5.0 liblua.a and change the build config/detect logic, for even more confusion and ugliness >_<
  - Joker_vD 6y ago
    Introduce the project- nay, the organization-wide mangling scheme! Every symbol is now required to have the library's version name in its name, may as well throw in some namespaces there too. Then maintain some sort of metainfo of what part is requiring what versions, and what project is providing what versions, and... and well, at this stage you're kinda reinventing the package management, but at least you don't need a custom linker, which is a good thing, right?
    - w0utert 6y ago
      The not-so-funny part is that it would probably be about the same effort to do that compared to convincing everybody to use shared linking for these kinds of things >_<

Joker_vD 6y ago

You rename things in liblua.a from version 5.0. to something different (append __5.0 to names or something), then in the .a file that should link to version 5.0, you rename all missing Lua symbols too. Then you link all this together: main.o component_for_lua5.0.a (modified: referenced Lua symbols renamed) component_for_lua5.2.a (with symbols left intact) liblua.a (from version 5.0, modified: symbols renamed) liblua.a (from version 5.2, its symbols left intact) There should be no more name collisions.

w0utert 6y ago
Aha got it, thanks! Like you said it’s not pretty but it works, and somewhat better than the abomination they came up with instead, which involved building only the minimal part that depended on the new Lua 5.2 as shared library, then making fake shared libraries for all remaining unsatisfied symbols referenced from it to trick the linker, and compiling them in statically instead like they used to do before. Hard to explain, don’t ask me why they did it... :-/ Edit: there is one pretty glaring downside to this approach though, which is that both the component we need to patch up with renamed symbols and the liblua.a are also used in other places, so they would either have to be built differently depending on the application, or we would have to maintain multiple versions of the same 5.0 liblua.a and change the build config/detect logic, for even more confusion and ugliness >_<
- Joker_vD 6y ago
  Introduce the project- nay, the organization-wide mangling scheme! Every symbol is now required to have the library's version name in its name, may as well throw in some namespaces there too. Then maintain some sort of metainfo of what part is requiring what versions, and what project is providing what versions, and... and well, at this stage you're kinda reinventing the package management, but at least you don't need a custom linker, which is a good thing, right?
  - w0utert 6y ago
    The not-so-funny part is that it would probably be about the same effort to do that compared to convincing everybody to use shared linking for these kinds of things >_<