[Libav-user] Windows compile can't find LAME

Jeremy Gregorio gunvalkyrie at yahoo.com
Thu Jul 12 03:49:00 EEST 2018


 Thanks, figured it out after you pointed me towards the config file. 
Visual Studio uses different syntax for linker files, so I needed to do this:
 ./configure --toolchain=msvc   --enable-gpl --extra-ldflags=-LIBPATH:/usr/lib --extra-cflags=-I/usr/include/lame --extra-cflags=-I/usr/local/include/ --extra-cflags=-I/usr/local/include/lame --host-ldflags=-LIBPATH:/user/lib   --extra-ldflags=-LIBPATH:/usr/local/lib --enable-libmp3lame

This is because visual studio uses -LIBPATH: instead of just -L

Oh, and note that I had to point the cflags to /user/local/include and not /user/local/include/lame/. 

lastly I did have to change the filename to mp3lame.lib (e.g. remove the lib* prefix) which I really didn't expect. 

I still have to compile lib x264. For some boneheaded reason I thought it was part of ffmpeg. But I'm moving right along. 
    On Wednesday, July 11, 2018, 4:52:31 AM PDT, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:  
 
 2018-07-11 5:53 GMT+02:00, Jeremy Gregorio
<gunvalkyrie-at-yahoo.com at ffmpeg.org>:
>  Thanks. The --arch=i386 was me trying to get 32-bit libraries so I
> could build a 32-bit app on my 64-bit Windows. I didn't want to
> leave users stuck on 32-bit Win7 in a lurch.

Instead you have to call the compiler in a way that makes it produce
32bit binaries (on Posix, that typically means --cc='cc -m32'), if
configure fails to detect that the binaries are 32bit (as is the case for
cross-compilation) you need the --arch option.

> There is a config log.

Good!

> I tried moving the LAME header file to /usr/local/include/lame/lame.h

Once you did that, you can remove at least some of your extra-cflags

> and running this:
>  $ ./configure --toolchain=msvc

> --enable-libx264 --enable-libmp3lame

Does x264 (without lame) work?

> --enable-gpl --extra-ldflags=-L/usr/lib

>  --extra-cflags=-I/usr/include/lame
> --extra-cflags=-I/usr/local/include/
> --extra-cflags=-I/usr/local/include/lame

Some of them are most likely unneeded.

> --host-ldflags=-L/user/lib
> --extra-ldflags=-L/usr/local/lib
>
> That seems to have gotten me a little further, but I can't seem to get the
> linker to find my libmp3lame.lib file. I think I'm using the --extra-ldflags
> wrong but I don't know how to fix it...
>
>
> require libmp3lame >= 3.98.3 lame/lame.h lame_set_VBR_quality -lmp3lame
> check_lib libmp3lame lame/lame.h lame_set_VBR_quality -lmp3lame
> check_func_headers lame/lame.h lame_set_VBR_quality -lmp3lame
> test_ld cc -lmp3lame
> test_cc
> BEGIN ./ffconf.xTrLDuO7/test.c
>    1    #include <lame/lame.h>
>    2    #include <stdint.h>
>    3    long check_lame_set_VBR_quality(void) { return (long)
> lame_set_VBR_quality; }
>    4    int main(void) { int ret = 0;
>    5    ret |= ((intptr_t)check_lame_set_VBR_quality) & 0xFFFF;
>    6    return ret; }
> END ./ffconf.xTrLDuO7/test.c
> cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS
> -D_WIN32_WINNT=0x0600 -nologo -I/usr/include/lame -I/usr/local/include/
> -I/usr/local/include/lame -c -Fo./ffconf.xTrLDuO7/test.o
> ./ffconf.xTrLDuO7/test.c
> test.c

> ./compat/windows/mslink -L/usr/lib -L/usr/local/lib -nologo
> -LARGEADDRESSAWARE -out:./ffconf.xTrLDuO7/test.exe ./ffconf.xTrLDuO7/test.o
> mp3lame.lib

It seems the linker is searching for "mp3lame.lib" and you provide
"libmp3lame.lib", no?

Please do not top-post here, Carl Eugen
_______________________________________________
Libav-user mailing list
Libav-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20180712/501b08a2/attachment.html>


More information about the Libav-user mailing list