It doesn't strictly require it to be dynamically linked but does place additional requirements on applications which are statically linked to LGPLed libraries.

> If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

this is not an additional requirement, this is another way to apply the core requirement of the LGPL to the static linking case in C, which is: the end-user must be able to patch / replace the LGPL parts of the app.

This is the relevant part:

  >If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

And is this easy? I don't know much about how this works, but would it be trivial for unity to distribute a version of unity with statically linked LGPL libraries where you can also easily relink?

It's as easy as building the project in the first place. Anytime you build your application you also build the object files for it as well.

As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.

Of course, those build files won't be stripped, meaning that it would be easier to reverse-engineer them - which might not be something the distributor wants.

? there's nothing that prevents to call strip on .o files

My understanding is that stripping .o files means you can't link to them, but maybe I'm wrong on that.

I wouldn't call it completely trivial at the scale and complexity of something like unity, but its certainly possible.

In practice it's probably easier to dynamically link the library.

I think you would find it very difficult to find even a single game which has done this.