build from source

[David Hoyt]

> However I just want a reasonably up to date version of the gstreamer 
> library so I can use it in a multi-media application I am trying to 
> develop myself. However since there is no binary distribution 
> available beyond the 0.10 edition, I have little choice but to try 
> and build it from source.

0.10 is fairly up-to-date since 1.0 came directly out of the 0.10 source
(you're not missing versions 0.2 - 0.9) -- instead the ABI has changed
slightly and there's other changes, but in general, they're not incredibly
divergent.

> ... It's the *.la file that it puts there which specifies incorrect 
> dependencies that do not exist

See if there are mingw dev packages for the requested dependencies and if
so, download them. If you're using a reasonably up-to-date msys/mingw
environment, mingw-get should be able to find, download, and install the
packages you need.

> Now I did manage to find some files named *.lai where the 'erlkoenig'
> name appears and edited those to point to my more standard 
> installation directory /usr/lib but they turn out to just be some kind 
> of intermediate file that gets overwritten when I run the make command 
> again.

IIRC, those are effectively templates for libtool that are filled in
(typically with an absolute path) when the libraries are installed.

> I wouldn't know what prefix to use since it installs them exactly 
> where I want them: In the default location. It's the *.la file that it 
> puts there which specifies incorrect dependencies that do not exists 
> and I don't know where they are getting it from.

The dependencies are likely filled in as a result of files generated in the
configure phase. One of the automake or autoconf files (I forget which)
specifies dependencies. You could locate the file in a pristine copy of the
source (as in a git clone or by looking at the source online), modify that
file in your local copy of the source, and then re-run autoconf to
re-generate the source. Or just hand-edit the .la (libtool archive IIRC)
file and remove its list of dependencies.

> Yes I did look there but then I think I have to go back to using 
> Microsoft visual studio...

As the guy that originally wrote that script, I can certainly tell you that
your assumption is incorrect. At least when you're talking about building
the dependencies (which is what that script is for). What I meant in my
previous message is that all those libraries in that script were built
natively on Windows using msys/mingw. So you could extrapolate how to apply
the same ideas/things to your own build of gstreamer. That and you'll find
that a lot of those dependencies are needed for gstreamer plugins to
actually do something -- e.g. libsoup for getting video over http. Or x264
or ffmpeg. If you don't have those libraries built and installed, when you
build gstreamer, it will automatically skip over plugins it could have used
but can't since their dependencies are not available.

> I don't think it's a MinGW issue. The mysterious dependency paths 
> suggest that said 'erlkoenig' uses MinGW too...

MSys is an emulated POSIX environment (a fork of cygwin, actually) and that
emulation is imperfect at best. So the tools (such as autoconf, automake,
perl, etc.), when run in this emulated environment, may not and often do not
run with the same fidelity or quality that you would see on a
POSIX-compliant OS (such as Linux). And often the versions of the autotools
available in msys lag behind their Linux counterparts. That's fine --
there's only so much time in the day for the msys guys to update their
system and make new releases. It has also often been the case that
developers assume such a fully POSIX-compliant environment and overlook
systems that require special hand-holding to get working correctly and so
the support for those environments suffers (such as Windows).

What it sounds like has happened is that a released source tarball (which is
typically different from what's in git) has been tarnished with an
engineer's local environment (likely the one who made the tarball) and was
released. You could run autoconf and friends and re-generate the autoconf
artifacts, then re-run configure, make, and make install. That could do it.

HTH,
- David Hoyt