Libraries prefix

[GoogleCodeExporter]

Hi,
I saw libraries have now a prefix lib-ossbuild-* :/
Any reason for that? It's not unix compilant and '-lgstreamer-0.10' wont work 
anymore for example. Many FOSS are using our libraries and the naming scheme 
should be respected.

Original issue reported on code.google.com by ylatuya on 21 Jan 2010 at 10:42

[GoogleCodeExporter]

-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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

That sounds fine. I'll get it updated ASAP.

Original comment by david.g.hoyt on 1 Feb 2010 at 6:47

[GoogleCodeExporter]

This has been fixed in the trunk.

Original comment by david.g.hoyt on 6 Feb 2010 at 9:00

• Changed state: Fixed