About some link warnings

hello there,

I have questions about some trivial link warnings.

  1. We have static lib A which has an implicit link to physX

(using “project settings->Configuration Properties->Librarian->General->Additional Dependencies”)

and an executable B is linking lib A, then following warnings occur for all configurations.


1>PhysX3CommonCHECKED_x64.lib(PhysX3CommonCHECKED_x64.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in PhysX3CHECKED_x64.lib(PhysX3CHECKED_x64.dll); second definition ignored
1>PhysX3CommonCHECKED_x64.lib(PhysX3CommonCHECKED_x64.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
1>PhysX3CookingCHECKED_x64.lib(PhysX3CookingCHECKED_x64.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in PhysX3CHECKED_x64.lib(PhysX3CHECKED_x64.dll); second definition ignored
1>PhysX3CookingCHECKED_x64.lib(PhysX3CookingCHECKED_x64.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library

but strangely, if executable B explicitly links physX libs, then no error occurs.

  1. We’ve found a bunch of LNK4099 warnings from physxvisualdebuggersdkchecked.pdb & physx3extensionschecked.pdb when building our project.

For physx3extensionschecked.pdb, we could remove most of them using provided project & sources ,but can’t for debug configuration because there is no debug version for other libs.

and For physx3extensionschecked.pdb, there was nothing i could do.

These may seem like minor problems, and I have no intention to urge u to fix these.

I just want to know whether you,developers know about these or not, and have any plans or polocies for the futere versions.

Or, did i configure something wrong?

please give me some hints, thanks and have a nice day.

Hi,

Yes, we’ve recognized that the static library configuration causes some problems for customers who don’t have source access, and therefore can’t tailor the debug build appropriately. We’re considering going to an all-DLL approach on Windows for this reason. What is your opinion on that approach?

Thanks,
Mike