Closed GoogleCodeExporter closed 8 years ago
After removing the ossbuild gtk libs, delete the gdkpixbuf plugin from
lib/gstreamer-0.10/, delete your gstreamer registry
(<Home>/.gstreamer-0.10/registry.i686.bin), and try again.
What are the clashes you're seeing?
I don't think we have time to create a separate package atm, but your app can
always just ship the plugins you need.
Ideally you'd be using the ossbuild gtk build since it's supposed to work w/
the other libs we provide. (c: But we're aware of a few problems w/ it right
now. I have a newer build here locally that should resolve most of the problems
-- I just haven't completed everything and tested it yet.
It's not possible to remove gstreamer's dependency on glib -- it's absolutely
essential to the whole project. The gdkpixbuf plugin, however, is the only
thing that has a dependency on GTK+. As such, removing the plugin removes the
GTK+ dependency. Our glib build and gtk.org's should be interchangeable. Of
course, if we're using newer API calls, you'll need to use ours or press
gtk.org to make a new build. We recommend you stay w/ us, of course, for the
sake of a unified and coherent platform.
Original comment by david.g.hoyt
on 17 Sep 2010 at 10:09
When I start the program on the PC that has the new 0.10.7 beta 1 installed,
somehow my program ends up using mix of the GTK from gtk.org and your build of
GTK.
This causes it to crash in non-predictable ways.
If I remove GTK related dlls (including the glib, to force using gtk.org's
version),
I get this error:
"The procedure entry point g_error_get_type could nto be located in the dynamic
link library libgobject.2,0-0.dll" and gstreamer fails to load.
If I add back your version of glib and gobject, it requires also getting back
libiconv-2.dll, libfreetype-6.dll. Unfortunately this version causes the crash
too.
Finally, I've used your version to overwrite the gtk.org's one, but hte crash
is still here.
Crash log seems to be related to "z.dll" (I suspect this is zlib1.dll from
gtk.org) and libgdk_pixbuf-2.0-0.dll:
> z.dll!6788bba3()
[Frames below may be incorrect and/or missing, no symbols loaded for z.dll]
z.dll!6788a45f()
libgdk_pixbuf-2.0-0.dll!65357fcd()
libgdk_pixbuf-2.0-0.dll!65347266()
libgdk_pixbuf-2.0-0.dll!6534731a()
msvcrt.dll!__unlock() + 0x15 bytes
libgdk_pixbuf-2.0-0.dll!6534736c()
libgdk_pixbuf-2.0-0.dll!653452fb()
Original comment by helix.sp...@gmail.com
on 20 Sep 2010 at 7:55
BTW, why not improve installer to add "install audio codecs only"?
I see no need for new package too.
Original comment by helix.sp...@gmail.com
on 20 Sep 2010 at 7:56
The installer is not meant to be used by packagers with very specific purposes.
Adding an option for "audio codecs only" is too vague and might only be useful
for some people whilst not enough for others.
If you have special needs you should be the one selecting which codecs do you
need and which want you want to redistribute.
Regarding the issue with GTK, we can't do any build that doesn't depend on the
newest glib. You can remove the gtk libs if you want, and replace them with the
one provided by GTK.org (that's what I do with LongoMatch). GStreamer depends
on latest glib, gobject, gthread stuff and can't be built with older versions.
Those libraries provide backward compatibility, that's why you can use them
with older gtk versions.
Original comment by ylatuya
on 20 Sep 2010 at 8:22
> You can remove the gtk libs if you want, and replace them with the one
provided by GTK.org (that's what I do with LongoMatch).
Care to explain this in more detail ? If you see description above, this causes
the crash for me.
Original comment by helix.sp...@gmail.com
on 20 Sep 2010 at 10:34
Try this again with the libs in the repo. If it's still causing conflicts, try
removing the GTK.org ones and linking against ours instead.
Original comment by david.g.hoyt
on 24 Sep 2010 at 11:46
You can take a look at the scripts I made for LongoMatch and PiTiVi to create a
deployment environment with all the external dependencies needed:
pitivi:
http://git.pitivi.org/?p=pitivi.git;a=blob;f=win32/setup.py;h=f51f94688a467a08ce
fd3c81ff914ece26d68b71;hb=HEAD
longomatch: http://git.gnome.org/browse/longomatch/tree/win32/deploy_win32.py
Original comment by ylatuya
on 4 Oct 2010 at 8:47
Thanks.
Original comment by helix.sp...@gmail.com
on 5 Oct 2010 at 9:09
Is this still a problem? If not, we'll close it out.
Original comment by david.g.hoyt
on 5 Oct 2010 at 4:19
Closing...
Original comment by david.g.hoyt
on 6 Oct 2010 at 7:09
Original issue reported on code.google.com by
helix.sp...@gmail.com
on 17 Sep 2010 at 11:17