About some link warnings

Gaming and Visualization Technologies APIs Physics Modeling (closed)
1

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.

2

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