[FFmpeg-devel] Fix mingw name of .lib files
Måns Rullgård
mans
Wed Mar 5 10:12:37 CET 2008
Gonzalo Garramu?o <ggarra at advancedsl.com.ar> writes:
> Diego Biurrun wrote:
>> On Tue, Mar 04, 2008 at 07:53:04PM -0300, Gonzalo Garramu?o wrote:
>>> I find it funny you hate autotools, as the ffmpeg build smells very much
>>> like a simpler (but functionally worse) copy of autotools.
>>
>> Missing what functionality exactly?
>>
>
> Right now, four big issues come to mind:
>
> * Lack of out of source builds (extremely annoying when you need to
> build ffmpeg for multiple platforms from SVN). At least that was not
> working last time I tried it a month or so ago.
Building outside the source tree works perfectly, with one exception.
It doesn't work if the source path contains spaces. This is caused by
makefile syntax, and is nothing we can do anything about.
> * Proper mingw versioning. (this discussion).
Matter of definition.
> * Many problems doing make clean with a dir that is already prebuilt for
> a different platform -- mingw paths seem to screw it ( .depend failing,
> etc ). I am using bash wrappers to work around these now, doing my own
> make clean first of the conflicting files.
make clean has no platform-specific bits to it. It deletes everything
that might be built.
> * In the past, under mingw also, I also had runtime problems due to
> ffmpeg linking against the version in /usr/local/lib instead of the one
> that is being built locally (forcing me to actually have to remove the
> one in /usr/local/lib first before building -- yuck). This one was
> really nasty (I spent a week tracking the issue), as the problem showed
> as a crash at runtime, and not as a linking problem. This also
> prevented easily trying multiple versions of ffmpeg.
I distinctly recall this being fixed well over a year ago.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list