|
List Info Thread: Re: Fix mingw name of .lib files
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: Fix mingw name of .lib files |
|
List Info Thread: Re: Fix mingw name of .lib files
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
advancedsl.com.ar>
writes:
>
>
> And then there's the FFmpeg build systems. It has
everything FFmpeg
> needs.
>
More likely, it has everything you need 
.
With the building bugs addressed, it would probably bring me
closer to
agreeing with you. BTW... is the git repository in sync?
I'm not sure
I'm seeing the fix you put in.
I'll admit I would still like to be able to compile under
MSVC. Not for
love of the platform but due to practical and potential
technical issues.
Using mingw ffmpeg with msvc (say 7.1 or 8.0) forces to have
two msvc
runtimes and I have seen msvc conflicts due to that (not
with ffmpeg or
my current code but other projects). I know that issue is
still
potentially lurking there (or perhaps ffmpeg does not get
effected due
to being only C code??).
The msvc compiler and stdlib is usually much worse than gcc,
but the
optimizer is often better (just as the intel compiler is
often usually
better than both).
Finall the old msvc5 (?) runtime (ie. the one mingw uses) is
old. The c
functions in that DLL are not threaded (or even thread safe,
I believe),
which is slowly going to become another issue in the coming
years.
>
> If the API has changed incompatibly, your code won't
even compile.
> This has nothing to do with library versions. If your
code compiles
> and links with a particular library version, it will
not break at
> runtime (bugs aside).
>
I was thinking that you were suggesting to ship with say,
v49, of my DLL
unversioned as avutil.dll. Under LGPL, problems arise.
User decides to enforce the LGPL and change his avutil.dll
to a compiled
one by himself (say v50). His avutil.dll certainly compiles
and his
ffplay works. Now, he tries it with my software. *BOOM*
missing
function ff_XXX or some alignment issue (ie. crash).
Ergo, I ship all versioned. I guarantee all works with v49.
User can
take advantage of LGPL but I only guarantee that to work
with the branch
shipped. If he tries to use a newer (or older) ffmpeg lib,
he is on his
own. It may still work, but can't do miracles.
Versioning is still important all the way to the user and
back.
>
> When linking against the unversioned .lib file, the
executable still
> gets a dependency on the versioned dll, just like in
Unix linking
> against libfoo.so makes the executable depend on the
DT_SONAME of that
> file, usually something like libfoo.so.17.
>
Right. As far as the *compiler/linker* is concerned. But
what about
the packaging and distribution? How do I easily tell that
code what DLL
version to ship from the several installed? Right now, the
only way is
to use cygcheck (a non-ms tool of cygwin) or dependency
walker (a ms
tool, more or less discontinued) on my exe, parse their
non-standard
output and ship the libs. That also forces me to have the
DLL in my
path also, so the tools can find it in the first place.
They are not good alternatives compared to the simple
alternative of
just having my Makefile take the .lib filename that it
linked to and
doing a simple regex of s/.lib$/dll and copy the dll file
somewhere for
distribution.
On Linux land the issue is a little simpler due to the lack
of .lib
files and the fact that LGPL .so files can be gotten by
users with their
distro packet managers or from source (so I may not even
need to really
ship them).
To be more clear, I'm not against a .lib version (symlinked
or not)
pointing to the latest version for easily finding and
compiling. I'm
against not having a versioned .lib file *also* installed.
> Why would you care? New builds should be linked with
the latest
> version, and the .lib files are not needed at runtime.
>
Besides packaging, I still foresee the need to know the
lib->dll
relationship. Say, I ship v1.0 with avutil49, and v2.0
with avutil50.
User then wants a critical bug fixed for v1.0. I need to
be able to
revert all the build to that and reship again with avutil49
(the code
may be too diverged to just upgrade to the new version --
plus I really
don't want to potentially get yet a new bug in there).
Ideally, I would
hope that means not having to keep going back in svn history
and
rebuilding ffmpeg each time or keep installing it in
different
directories. Overwriting and having a single .lib file
forces me to do
just that. I would prefer to just leave my /usr/local/lib
and
/usr/local/bin with all versions of ffmpeg I shipped. Sure,
avutil.lib
changes to point to v50, but old avutil-49.lib/dll is still
v49 and a
stable one.
>
> I care, because if symlinks don't work, users will come
complaining
> that "make install" is broken.
>
Well, by that concept, make install is already broken under
mingw32.
None of the installed .DLL files end up being symlinks (and,
assuming
msys should work akin to unix, at the very least one of them
should be).
I think this is something imaginary. I seriously doubt
anyone can
expect you to actually fix problems with the OS or file
system.
--
Gonzalo Garramuņo
ggarra