Closed GoogleCodeExporter closed 9 years ago
-lgstreamer-0.10 should work b/c the name of the .lib and dll.a (archives)
haven't
changed. The reason is that some projects (e.g. zlib) require non-official
builds to
have a different name.
If you'd prefer to have no prefix, at the top of Build-All-Windows-x86.sh,
set "Prefix=${DefaultPrefix}" to "Prefix=".
But I'm a bit unsure what we should do for those libraries that require a
separate
naming scheme. I figured it'd be best to at least be consistent across the
board so
we don't run into problems with other libraries.
Original comment by david.g.hoyt
on 21 Jan 2010 at 5:16
This is also similar to what msys does with their libs and cygwin as well.
Original comment by david.g.hoyt
on 21 Jan 2010 at 5:21
We could contact the authors of these libraries and get their approval of our
builds
and if they sanction the dll and we have it documented, then I'm fine w/
removing
the prefix.
Original comment by david.g.hoyt
on 21 Jan 2010 at 5:24
Probably I missread something... I agree for example in having
lib-ossbuild-avcodec,
because this way we won't have problems with linking dll's provided by another
installation.
What would wrong is to have lib-something-gstreamer. I need to check the all the
changes again :)
Original comment by ylatuya
on 21 Jan 2010 at 5:28
Tor Lillqvist from GTK+ (among various other open source projects) said this to
me:
http://old.nabble.com/Re%3A-Build-a-zlib-1.2.3-dll-with-MinGW-p26818083.html
Which was the driver for the re-branding efforts.
Original comment by david.g.hoyt
on 21 Jan 2010 at 5:28
Ah okay - so there doesn't seem to be issue w/ most of the depedencies having
the
prefix, just the gstreamer libs?
I'm certainly open to that, but our gstreamer build is custom -- and the .libs
being
output shouldn't have changed their name (the .dll's, yes - at this point). If
they're different, then that's a bug on my end I'll fix. But since they're
custom,
they should be branded too. It's for consistency's sake too.
We'll want to distribute the .libs for any gst-lib dll (e.g. gstreamer, gst-
photography, etc. and any non-plugin-specific dll) so that devs can code
against the
gstreamer api.
But I'd imagine we'd distribute the gstreamer .libs alongside all the other
dependent .libs (avcodec.lib, neon.lib, soup.lib, etc.) in case people are
using it
not just for the gstreamer builds.
But since the .libs have maintained their file name, anyone linking against
them
wouldn't notice a difference. But their dll's would now reference lib-ossbuild-
gstreamer-0.10.dll instead of libgstreamer-0.10.dll. So a rebuild of their app
should fix any dependency issues. It shouldn't require any more effort than
that. If
it does, I need to fix it.
Original comment by david.g.hoyt
on 21 Jan 2010 at 5:38
I'd love to rebrand everything to *ossbuild*, but I was worried about developers
having to rebuild their apps, although it's not a big deal in the end.
+1 for the branding name scheme.
Are you on usually on #gstreamer?
Original comment by ylatuya
on 21 Jan 2010 at 6:20
I'm occassionally on #gstreamer.
I'm in the middle of a lot of the rebranding work so things might not be 100%
working right now. I prefer that each commit work fully, but haven't been able
to
maintain that due to various issues.
I finally found a gcc 4.4.2 build for both x86 and x86_64 on Windows and am
testing
it to see if it's actually going to work. The x86 one I might use anyway even
if the
x86_64 doesn't work b/c supposedly it'll compile everything correctly and all
the
depedency lib's tests will pass. We shall see...
Original comment by david.g.hoyt
on 21 Jan 2010 at 7:08
Good news :)
I did a complete rebuild and everything was ok except for the tools
(gst-inspect,
gst-launch, etc...) complaining about not being able to spawn rc.exe. I need to
check
that better because I don't know if it's because VSExpress does not provide it
or
because it's missing in my installation.
Original comment by ylatuya
on 21 Jan 2010 at 7:33
rc.exe is the resource compiler - that should be installed w/ visual studio as
part
of the SDK.
Original comment by david.g.hoyt
on 21 Jan 2010 at 10:11
I was testing on a virtual machine at work with a clean installation an the
VSExpress
edition. As I said, nothing important, I just need to check again if it's
installed
with the express edition.
Original comment by ylatuya
on 21 Jan 2010 at 11:08
I'm still a little bit worried about all the rebranding process.
Let's take a practical case, for example http://liris.cnrs.fr/advene/, which
contacted me a couple of days ago letting me know that they finally finished the
GStreamer backend for windows using our binaries. Their project is written in
Python
and based on GTK and GStreamer. Actually they just have to copy our binaries to
their
deployment folder and that's all. But with all the branding they will end-up
with
duplicated libraries, mostly all the ones we share with GTK. Rebuilding GTK is
not a
solution and in the end they will have the GTK stuff running with a glib
version and
the GStreamer one running with another glib version, which might be
incompatibles.
From my point of view it's a good idea to rebrand some shared libs, like zlib or
av{codec|format|util) that might cause troubles when mixed with another
installation.
But I won't like having in the same application two different versions of glib
sharing data and signals.
Original comment by ylatuya
on 27 Jan 2010 at 11:54
Well ultimately I would like to get GTK built as well and included so that
OSSBuild
can be a source for more than just the gstreamer community. We have most of the
GTK
foundation already built (fontconfig, cairo, pango, glib, etc.). Taking it one
step
further wouldn't be difficult (I hope - but I've never built GTK before...). If
we
provided a rebuilt GTK, they shouldn't have a problem. It would probably work
out
better for them as well b/c they'd have a set of libs that have been tested
together
and are all on a stable rev. Pulling some libs from here and some from there
may not
necessarily be stable. We're also more on top of lib changes than other
projects.
Ironically I was ready to commit the rebranded dlls built w/ GCC 4.4.3 today
(finally all the FFMpeg tests are passing) along w/ some updated packages. We
need
to get together on IRC and discuss it. If it gets voted down, I'll understand
completely.
Original comment by david.g.hoyt
on 28 Jan 2010 at 1:50
I think your suggestion is best, so I went ahead and revamped the script to
brand
only zlib. I left FFmpeg alone for now since as far as I know they don't
require
renaming libs that aren't official.
Original comment by david.g.hoyt
on 30 Jan 2010 at 6:40
Hi David,
I think this is probably the best decision for the moment although I'd also
rebrand
the ffmpeg libraries. FFmpeg is used by many projects and we risk loading a dll
that
wasn't compiled with the features we want (that was one of the pros of using
static
linking for gstffmpeg). Appending the revision number gives some protection to
that
but we really want to use our binaries and not another that is API/ABI
compatible but
that was compiled with GPL support for example (in the case of the LGPL
package).
What do you think?
I also saw that you added GTK+ to the deps script :D
Original comment by ylatuya
on 31 Jan 2010 at 11:45
What should we call the ffmpeg libraries? I'd prefer to keep them as shared
libraries b/c there are some projects that use them for language bindings.
I compiled GTK+ and all the tests pass, but I had difficulty getting the python
bindings compiled. I'm not sure exactly why. So for now only the C libs are
provided.
Original comment by david.g.hoyt
on 1 Feb 2010 at 5:57
I'm talking about libavcodec-XX.dll and so on.
What I mean is that now that gstffmpeg link against the ffmpeg's shared
libraries we
should also rename them, to avoid loading a libavcodec-XX.dll, with the same
revision
number, but compiled with less features. Maybe adding lgpl to the LGPL one, as
we do
with the GPL one, should be enough.
Original comment by ylatuya
on 1 Feb 2010 at 6:22
That sounds fine. I'll get it updated ASAP.
Original comment by david.g.hoyt
on 1 Feb 2010 at 6:47
This has been fixed in the trunk.
Original comment by david.g.hoyt
on 6 Feb 2010 at 9:00
Original issue reported on code.google.com by
ylatuya
on 21 Jan 2010 at 10:42