[vlc-devel] [PATCH 4 of 6] contrib: fix a few quirks detected during win32 cross compilation

[Edouard Gomez]

Jean-Baptiste Kempf (jb at videolan.org) wrote:
> > Review carefully as chunks impact the avcode plugin:
> >    - I had to disable libfaac support because whatever I tried
> >      the vlc ffmpeg plugin was always failing final link
> >      because of faac symbols missing. Though i tried to
> >      look at the compiled libfaac.a with mingw nm, I could not
> >      find any reason why the symbols were seen in the plugin link.
> This isn't good... We really need faac...

That's what i supposed, then i must have some difference in my 
cross compilation toolchain from the nightly builds one.

Some facts:
 - libfaac is correctly compiled. My amd64 nm complains
   it's not elf64, and mingw32 nm recognizes its format.
 - As an example, among the missing symbols is the library open function.
 - the linker searches for _XXXX symbols (c calling convention), the
   lib has only _XXXX at number (stdcall calling convention). Usually, 
   mingw32 gets around the problem fixing calling convention symbol names
   at link time, here it wasn't.
 - -lfaac was actually in the linking command line
 - -lz and -lmp3lame were too, but no problems with those ones.
 - even if i changed the linking order manually, the symbols
   were still missing.

I can still live w/o this patch if the rest of the patches find their
way in the official vlc distrib, because i won't need to compile the
stuff again :-)

> >    - I had to remove the --cc=$(CC) assignment, because during
> >      cross compilation ffmpeg build system would concatenate
> >      the CC value with the cross-prefix value ending with calls
> >      to i386-mingw32-i386-mingw32-gcc.
> Not compiled on cygwin the contribs since a long time, but IIRC, this
> was needed on linux, I'll check.

I realize i never told i was cross compiling:
 - build platform : debian sid amd64
 - hand made mingw 4.2.3 toolchain (works ok for lot of other programs)
 - the prefix is not the sid one i586-mingw32-msvc, i prefered having  
   i386-mingw32 to differentiate from the sid toolchain.

If this can help you spot the bug.

-- 
Edouard Gomez