For some reason, IOHIDDeviceRegisterRemovalCallback() no longer works on
10.15+, so an app will crash once trying to poll a device that doesn't
exist anymore. Thankfully, there is the alternative solution of using
IOHIDManagerRegisterDeviceRemovalCallback(). This just required a little
rearranging of the callback code, as well as keeping track of the
connection between IOHIDDeviceRefs and IOKitInputDevices so we actually
know which device to remove.
Closes#847
This results in size savings for thirdparty libraries that are only used once, and a size increase for libraries used more than once (eg. OpenSSL). More importantly, it prevents conflicts with other versions of the libraries loaded by other Python modules, such as the version of OpenSSL that the hmac module uses.
We need to be careful to only apply this for packages that are either used once, used in a plug-in module, or if we don't need to pass thirdparty library structures across Panda library boundaries. For example, I haven't done this for Bullet, since the Bullet symbols need to be available through libpandabullet.so due to the fact that pandabullet contains calls to the Bullet libraries in the inline methods.
Fixes#851
These were probably added before makepanda gained the ability to automatically add dependencies of static libraries when linking statically.
They don't really do any harm--the linker will probably optimize these out automatically--but it's cleaner not to add unused dependencies.
We haven't needed this for a while since the direct tree is both Python 2 and 3 capable, and furthermore, Python 2.7 is EOL and will be dropped soon in Panda3D.
We no longer support Windows XP and so there is no point in defaulting to the old 7.1 SDK, which is hard to install. To target Vista, we can use the 8.1 SDK (+UCRT).
Our support was stuck on an ancient version that has not been available for a while. If we were to continue support it should be done around the new PhysX 5.0 API, not 2.8.4.
If we don't do this, we get an assertion somewhere in the bowels of the scene graph, which will be much less helpful for tracking down the origin of the NaN.
This could cause a crash when constructing a GraphicsPipe() under some conditions (observed in Python 3.8). Credit goes to @CFSworks for tracking this down.
