The best option is to have two libraries.
One would be your library, which is IoC-agnostic. All classes use constructors for their dependencies. If there are any specific ways objects need to be created, the library provides abstractions that can be implemented by IoC code. As for your comment for "cannot use same composition root" I find that hard to understand. If your code is used by the library user, then it must have came from same place.
Second would be library for providing default setups for specific IoC containers. There won't be single library, but library for each of popular IoC container. Those can be created either by you or have 3rd party developers create them for their convenience. This code will contain just IoC setup code with possible options for various use cases. The user of the library just then needs to call a single method to setup it's IoC for your library.
This approach is used by ASP.NET Core. It is made even easier that most libraries assume .NET Core's Microsoft-provided IoC containers for their default setup code.