Even if we separate into a new library we would have the same problem if you are using this profiling library with another 3rdparty middleware that also initializes socket library.

I see two solutions:

1. Requesting to Nintendo a change in the API. In the other platforms, double initialization of sockets is fine.
2. Export a callback (in integration API) to initialize sockets. That way, client code is in charge of that.

Does the temporal workaround of using NS_DISABLE_SOCKET_INIT work for you?

I un-link other 3rd party middleware's network function for now.
However, if we start to implement the network function for our project, I will do NS_DISABLE_SOCKET_INIT.

I am checking the latest documentation available on Nintendo website and it read this regarding nn::nifm::Initialize

The network connection management library must be initialized by this function ahead of time before the library's functions can be used,

unless noted otherwise for individual functions. The function also returns an indication of success if the library has been initialized already.

Hi Ryan,

I have checked with the latest Nintendo SDK (13.3.0 and 14.0.0) and it seems they are still aborting when socket is initialized twice. Nintendo is not going to change this behavior. So I think the best solution is just keep using our define NS_DISABLE_SOCKET_INIT (by the way in r10934 I fixed a minor issue about this).

It is also very important that you don't release your game with NS_PROFILE enabled and this macro is intended only for profiling and connecting the Inspector.

I am going to close this, but if you need anything more, please reopen.

Thank you