Multiply defined symbols with Cinder audio and ciWMFVideoPlayer in uuid.lib

Using Cinder
1

I’m trying to use the ciWMFVideoPLayer (our fork of it, at https://github.com/Potion/Cinder-WMFVideo), and cinder audio, and I’m getting duplicate symbol errors. There are many many of these errors, but the first one, and the simplest, is this:

cinder.lib(DeviceManagerWasapi.obj) : error LNK2005: PKEY_NAME already defined in uuid.lib(functiondiscovery.obj)

The rest of them are almost identical, except for the actual name of the symbol.

I’m also using our sound manager (https://github.com/Potion/Cinder-poSoundManager), but I get the same errors if I just use a simple ci::audio::VoiceRef. I’ve tried forward-declaring the ciWMFVideoPlayer class so I include it in my cpp file, but that isn’t working, either.

If anyone has run across this or can offer any advice in finding the issue, I’d greatly appreciate it. I know these classes CAN be used in the same application. Thanks!

2

Looks like Cinder-WMFVideo is doing some inline linking (for lack of a better name) here. Do you get the same problem if you comment this linker command out?

If that doesn’t fix it, it’s likely the #include <Functiondiscoverykeys_devpkey.h> that’s causing the issue. Since ciWMFVideoPlayerUtils.cpp is only using a single property key from that file, you can define it locally and delete the Functiondiscoverykeys_devpkey include altogether. Something like:

// At the top of ciWMFVideoPlayerUtils.cpp

extern "C" const PROPERTYKEY kLocalFriendlyNamePropertyKey = 
{ 
	{ 0xa45c254e, 0xdf1c, 0x4efd, { 0x80, 0x20, 0x67, 0xd1, 0x46, 0xa8, 0x50, 0xe0 } }, 14 
};

Then here use the local key instead of the one from the include.

// hr = pProps->GetValue( PKEY_Device_FriendlyName, &varName ); // before
hr = pProps->GetValue( kLocalFriendlyNamePropertyKey, &varName ); // after

Haven’t tested any of this so please take with a cup of salt, but should give you a few avenues for exploration at least.

A

3

@lithium: Thanks so much for your suggestion! Your second suggestion – defining kLocalFriendlyNamePropertyKey locally – worked!

It turns out that my VS solution incorporated several projects, two of which were evidently duplicating this, because removing one of them (which wasn’t really necessary anyhow) also solved the problem. But this is a much more direct solution, and I appreciate it!

Thanks!
Jennifer