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

[Edouard Gomez]

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.

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

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 ?

I'll try to have some conversation with their build system maintainer.

-- 
Edouard Gomez