locked
MF_MT_MAJOR_TYPE unresolved token RRS feed

  • Question

  • Maybe because its late or I've just been looking at this too long, but I just can't figure it out. I have this line of code directly from msdn:

    hr = pPartialType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Audio);

    and it keeps giving me error LNK2020 unresolved token, and LNK2001 unresolved external symbol for both MF_MT_MAJOR_TYPE and MFMediaType_Audio.  The first thing I checked was my libraries and I have Mfuuid.lib (as well as all the other Mf... libs at this point) and the proper paths for 32 and 64 bit (C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib and ...lib\x64).  I'm compiling C++ in VS2008 on Windows7.  I've used many other parts of Media Foundation with no trouble linking.  Any suggestions would be appreciated.  Thanks.

    Monday, February 1, 2010 2:58 AM

Answers

  • They are defined in mfuuid.lib.  You should only have the SDK lib path to architecture that you're compiling for in the Linker -> General -> Additional Library Directories field (example: C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib for x86).


    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    • Marked as answer by The March Hare Thursday, February 4, 2010 7:48 AM
    Monday, February 1, 2010 3:45 AM

All replies

  • They are defined in mfuuid.lib.  You should only have the SDK lib path to architecture that you're compiling for in the Linker -> General -> Additional Library Directories field (example: C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib for x86).


    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    • Marked as answer by The March Hare Thursday, February 4, 2010 7:48 AM
    Monday, February 1, 2010 3:45 AM
  • Five hours sleep, two mugs of coffee, back at it...

    Thanks for your reply The March Hare.  I tried placing the path in Linker->General->Additional Library Directories as you suggested, but this made no difference.  I moved some classes around just to simplify my file organization and this message appeared.

    error LNK2028: unresolved token (0A000071) MF_MT_MAJOR_TYPE referenced in function "public: class System::String ^ __clrcall Capture::S_InfoWrapper::Name::get(void)"

    Capture::S_InfoWrapper is a managed structure that marshalls unmanaged strings wchar_t* to managed like so:

    property String^ Name {
      String^ get() {return gcnew String(Info->Name);}
    }

    where Info is a structure of unmanaged strings (wchar_t*).

    The implication is that MF_MT_MAJOR_TYPE is referenced in code that has no media foundation at all.  Since this makes no sense whatever, I can only conclude that the linker is choking on something elsewhere but failing to report it, then in its confused state, dying when it reaches this code.

    But the LNK2028 message got me thinking that the internal problem is probably related to the mixed code and an incompatibility between MF and CLR.  So my next attempt at resolving this is to move all of the MF code to its own private dll to further isolate it.  Probably should have done this to start with anyway.

    Monday, February 1, 2010 2:23 PM
  • Ah, the missing information:  CLR :)

    Usually with an undefined symbol you would have an underscore in front of it (example: _MF_MT_MAJOR_TYPE), the CLR may be doing something different.

    The MF team have said that they will have a .NET sample on their blog (see top post in this forum) but I don't think it's there yet.

    You may want to look at this project, if you haven't already:




    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    Monday, February 1, 2010 3:48 PM
  • Well, I decided to have another go at this before making any major modification to the code structure.  I looked at the GUIDs causing the problem and found them defined in mfapi.h using DEFINE_GUID which is #defined in Guiddef.h as EXTERN_C const GUID FAR.  I think extern "C" is not really what I want inside my CLR mixed code.  Since I already have quite a bit of MF pointers and methods successfuly working, and very little marshalling as my managed code is only for the UI, I'd rather not start from scratch.  So as a work around, since the only errors (so far...) are GUIDs, I've recreated the ones I use as const GUID globals.  Seems safe enough as the mfapi.h ones are not likely to change.

    I did look at the link you provided and it's very interesting, but more than I need right now.
    • Marked as answer by The March Hare Thursday, February 4, 2010 7:48 AM
    • Unmarked as answer by _dn_ Thursday, February 25, 2010 3:39 PM
    Monday, February 1, 2010 9:11 PM
  • I had to come back and update this because the whole problem was just a simple mistake.  It started when I added mfuuid.lib as a linker dependancy but the compiler kept giving me unresolved token errors.  Well, what happened was, in the property editor I intended to set configuration to All Configurations, but accidentally clicked Release.  So, I "knew" the lib was correct which led me to spend hours looking for some other cause of the problem, when really the lib was just not added in my debug environment.  Therefore, March Hare, your original answer was correct!  Thanks.
    Thursday, February 25, 2010 3:52 PM
  • Thank you for your update.  It was a little mysterious to me why it wouldn't work but I'm not that well versed in the intricacies of the CLR.
    Please use Vote As Helpful (green up arrow at top-left of posts) and Mark As Answer where appropriate.
    My dshow site is http://tmhare.mvps.org.
    Thursday, February 25, 2010 6:04 PM