#52 KSPROPSETID_MemoryTransport missing from ks.h

closed-fixed
Jonathan Yong
None
5
2011-09-19
2011-09-12
Andres Colubri
No

I'm in the process of including the winks plugin from gst-plugins-bad into the build chain of mingw. Winks uses directshow to provide video capture in gstreamer under windows.

It turns out that the GUID KSPROPSETID_MemoryTransport is missing from ks.h. In order to get it compile, I added:

#define STATIC_KSPROPSETID_MemoryTransport \ 0xa3d1c5d, 0x5243, 0x4819, 0x9e, 0xd0, 0xae, 0xe8, 0x4, 0x4c, 0xee, 0x2b
DEFINE_GUIDSTRUCT("0A3D1C5D-5243-4819-9ED0-AEE8044CEE2B", KSPROPSETID_MemoryTransport);
#define KSPROPSETID_MemoryTransport DEFINE_GUIDNAMED(KSPROPSETID_MemoryTransport)

enum {
// a value of zero is ignored
KSPROPERTY_MEMORY_TRANSPORT = 1 //Sets pin's memory transport mechanism e.g. VRAM or SYSMEM
};

These defines were also missing:

#define KSSTREAM_HEADER_OPTIONSF_BUFFEREDTRANSFER 0x00000400
#define KSSTREAM_HEADER_OPTIONSF_VRAM_DATA_TRANSFER 0x00000800

And in ksmedia.h:

#define STATIC_KSPROPSETID_Wave_Queued\ 0x16a15b10L, 0x16f0, 0x11d0, 0xa1, 0x95, 0x00, 0x20, 0xaf, 0xd1, 0x56, 0xe4
DEFINE_GUIDSTRUCT("16a15b10-16f0-11d0-a195-0020afd156e4", KSPROPSETID_Wave_Queued);
#define KSPROPSETID_Wave_Queued DEFINE_GUIDNAMED(KSPROPSETID_Wave_Queued)

#define STATIC_KSPROPSETID_VramCapture\ 0xe73face3, 0x2880, 0x4902, 0xb7, 0x99, 0x88, 0xd0, 0xcd, 0x63, 0x4e, 0xf
DEFINE_GUIDSTRUCT("E73FACE3-2880-4902-B799-88D0CD634E0F", KSPROPSETID_VramCapture);
#define KSPROPSETID_VramCapture DEFINE_GUIDNAMED(KSPROPSETID_VramCapture)

After all these additions, compilation is successful, but ld fails to resolve the KSPROPSETID_MemoryTransport symbol:

...
CCLD libgstwinks.la
Creating library file: .libs/libgstwinks.dll.a
.libs/libgstwinks_la-gstksvideodevice.o: In function `gst_ks_video_device_create_pin':
/home/andres/ossbuild/checkout/gst-plugins-bad-0.10.22/sys/winks/gstksvideodevice.c:550: undefined reference to `_KSPROPSETID_MemoryTransport'
/home/andres/ossbuild/checkout/gst-plugins-bad-0.10.22/sys/winks/gstksvideodevice.c:613: undefined reference to `_KSPROPSETID_MemoryTransport'
/home/andres/ossbuild/checkout/gst-plugins-bad-0.10.22/sys/winks/gstksvideodevice.c:613: undefined reference to `_KSPROPSETID_MemoryTransport'
/home/andres/ossbuild/checkout/gst-plugins-bad-0.10.22/sys/winks/gstksvideodevice.c:613: undefined reference to `_KSPROPSETID_MemoryTransport'
/home/andres/ossbuild/checkout/gst-plugins-bad-0.10.22/sys/winks/gstksvideodevice.c:613: undefined reference to `_KSPROPSETID_MemoryTransport'
collect2: ld returned 1 exit status
make: *** [libgstwinks.la] Error 1

I'm passing the following libs to ld: -ldxguid -lole32 -luuid -lstrmiids -lks -lksuser -lsetupapi

Strangely enough, I don't see any undefined reference error for KSPROPSETID_VramCapture and KSPROPSETID_Wave_Queued

Thanks!

Discussion

  • Jonathan Yong
    Jonathan Yong
    2011-09-12

    OK, I'll try to do this over the weekends.

     
  • Jonathan Yong
    Jonathan Yong
    2011-09-12

    • assigned_to: nobody --> jon_y
     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-16

    • status: open --> pending-fixed
     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-16

    Several changes went into the svn trunk between revs. 4477-4479. Please check to see that they help with your case. Setting status to fixed+pending.

     
  • Andres Colubri
    Andres Colubri
    2011-09-16

    Great, thanks for taking care of this!

    I will check if the linking errors disappear and will update in the next few days.

    Question, is this fix going into the 2.0 branch?

     
  • Andres Colubri
    Andres Colubri
    2011-09-16

    • status: pending-fixed --> open-fixed
     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-16

    • status: open-fixed --> pending-fixed
     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-16

    > Question, is this fix going into the 2.0 branch?

    If the changes fix your issues, then yes I will apply them to the 1.0 branch too.

     
  • Andres Colubri
    Andres Colubri
    2011-09-19

    The linking errors went away using the updated CRT!

    However, I get an error when I try to use the resulting dlls in windows: "This application has failed to start because ks,sys was not found. Re-installing the application may fix this problem"

    Maybe I forgot some detail when generating the new binaries... Actually, in order to do a quick test I just replaced the libks and libksuser files in my 1.0 mingw tool chain with the new ones I generated from the trunk :-P

    I probably need to replace the entire 1.0 tool chain with the new one built from the trunk, including the gcc and binutil executables, right?

     
  • Andres Colubri
    Andres Colubri
    2011-09-19

    • status: pending-fixed --> open-fixed
     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-19

    > However, I get an error when I try to use the resulting dlls in
    > windows: "This application has failed to start because ks,sys was not
    > found.

    Well, why isn't that normal? You are linking with -lks and that links
    you to ks.sys. If your target machine doesn't have it then an error
    will be displayed. If you dont want ks.sys and all you do is contained
    in ksuser.dll, then link only to ksuser.

    > I probably need to replace the entire 1.0 tool chain with the new
    > one built from the trunk, including the gcc and binutil executables,
    > right?

    Mixing things generally isn't a good idea. If you are using v1.0 branch
    crt and headers, the patch went into the trunk should apply to the v1.0
    branch too, and if you are compiling your own toolchain you should be
    fine. Otherwise a new toolchain is a better choice.

     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-19

    • status: open-fixed --> pending-fixed
     
  • Andres Colubri
    Andres Colubri
    2011-09-19

    > > However, I get an error when I try to use the resulting dlls in
    > > windows: "This application has failed to start because ks,sys was not
    > > found.
    >
    > Well, why isn't that normal? You are linking with -lks and that links
    > you to ks.sys. If your target machine doesn't have it then an error
    > will be displayed. If you dont want ks.sys and all you do is contained
    > in ksuser.dll, then link only to ksuser.

    Sorry for not testing things thoroughly enough. Yes, you are right, after removing the ks dependency, the binaries work.

    > Mixing things generally isn't a good idea. If you are using v1.0 branch
    > crt and headers, the patch went into the trunk should apply to the v1.0
    > branch too, and if you are compiling your own toolchain you should be
    > fine. Otherwise a new toolchain is a better choice.

    I entirely agree. I forced things a little bit only because the build system I'm using is still dependent on mingw-w64 1.0, and I'd need a few more days to make it work with the updated builds from the trunk, but I wanted to have some results, at least preliminary. So far, things look good, since the winks plugin now compiles and runs without any apparent problems (I tested only on windows 32 bits).

    I don't know if this information is enough to consider this issue closed. In any case, during the next days I will update the build system to the new tool chain, and hopefully will add the x64_64 target as well.

    Another question: once this issue is closed, how long would it take for the automated builds to reflect the changes?

    Thanks for all your help!

     
  • Andres Colubri
    Andres Colubri
    2011-09-19

    • status: pending-fixed --> open-fixed
     
  • Jonathan Yong
    Jonathan Yong
    2011-09-19

    Normally, a day or 2 should push things to the buildbot. It seems only the Linux buildbot is up for the moment, but cross gcc is crashing, so probably no builds for awhile.

    For the record:
    ../../../build/mingw/mingw-w64-crt/misc/wcrtomb.c: In function '__wcrtomb_cp':
    ../../../build/mingw/mingw-w64-crt/misc/wcrtomb.c:18:2: error: definition in block 4 follows the use
    for SSA_NAME: D.23970_14 in statement:
    D.23977_26 = (wchar_t) D.23970_14;
    ../../../build/mingw/mingw-w64-crt/misc/wcrtomb.c:18:2: internal compiler error: verify_ssa failed
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <http://gcc.gnu.org/bugs.html> for instructions.

     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-19

    Good to know that the issue is fixed. The information you provided is enough for closing.

    Automated builds using the trunk should have picked up the change the day after they had gone in.

    I just applied the changes to the v2.0 branch (rev. 4484). I don't think I will apply them to the old v1.0 branch, but you should be able to do that without a hassle if you need.

    Closing as fixed.

     
  • Ozkan Sezer
    Ozkan Sezer
    2011-09-19

    • status: open-fixed --> closed-fixed