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

[Jean-Baptiste Kempf]

On Sun, Oct 12, 2008 at 06:04:44PM +0200, Edouard Gomez wrote :
> Edouard Gomez (edouard.gomez at gmail.com) wrote:
> > 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.
> 
> Ok i found the reason.

We read ffmpeg-devel mailing list too :D
> 
> A simple test like this prove my sayings:
> $ touch blah.c
> $ i386-mingw32-gcc -dM -E blah.c | grep WIN32
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> #define WIN32 1
> $ i386-mingw32-gcc -std=c99 -dM -E blah.c | grep WIN32
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1

 i386-mingw32-gcc -std=gnu99 -dM -E blah.c | grep WIN32

 Works as normal :D


> As you see gcc is following C99 standard by forcing all
> system defines being prefixed by at least one underscore.
> 
> Couple that with the fact that faac has this kind of code:
> #ifdef WIN32
> # ifndef FAACAPI
> #  define FAACAPI __stdcall
> # endif
> #else
> # ifndef FAACAPI
> #  define FAACAPI
> # endif
> #endif
> 
> 
> And you get my erros with _XXXX symbols missing.
> 
> I don't know how to address that, i suppose sending a patch to ffmpeg
> will be the preferred solution, isn't it ?
Yes.

Best Regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/