Re: [Libav-user] Windows compile can't find LAME
2018-07-12 2:49 GMT+02:00, Jeremy Gregorio : > 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 These should be unneeded: --extra-cflags=-I/usr/include/lame --extra-cflags=-I/usr/local/include/lame Do not top-post here! Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Windows compile can't find LAME
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
wrote:
2018-07-11 5:53 GMT+02:00, Jeremy Gregorio
:
> 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
> 2 #include
> 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) & 0x;
> 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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Windows compile can't find LAME
2018-07-11 5:53 GMT+02:00, Jeremy Gregorio
:
> 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
> 2#include
> 3long check_lame_set_VBR_quality(void) { return (long)
> lame_set_VBR_quality; }
> 4int main(void) { int ret = 0;
> 5 ret |= ((intptr_t)check_lame_set_VBR_quality) & 0x;
> 6return 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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Windows compile can't find LAME
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.
There is a config log.
I tried moving the LAME header file to /usr/local/include/lame/lame.h and
running this:
$ ./configure --toolchain=msvc --enable-libx264 --enable-libmp3lame
--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
--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
2 #include
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) & 0x;
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
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4044: unrecognized option
'/LC:/workspace/windows/msys64/usr/lib'; ignored
LINK : warning LNK4044: unrecognized option
'/LC:/workspace/windows/msys64/usr/local/lib'; ignored
LINK : fatal error LNK1181: cannot open input file 'mp3lame.lib'
ERROR: libmp3lame >= 3.98.3 not found
On Tuesday, July 10, 2018, 5:25:03 AM PDT, Carl Eugen Hoyos
wrote:
2018-07-08 18:46 GMT+02:00, Jeremy Gregorio
:
> ./configure --toolchain=msvc --arch=i386 --enable-yasm --enable-asm
> --enable-static --disable-shared --enable-libx264 --enable-libmp3lame
> --enable-gpl --extra-ldflags=-L/usr/lib --extra-cflags=-I/usr/include/lame
> --host-ldflags=-L/user/lib --extra-libs=-lm --extra-libs=-lpthreads
Unrelated:
The following options are useless because they are the default and
make debugging the configure line more difficult:
--enable-yasm --enable-asm --enable-static --disable-shared
If the following is unneeded (as I expect), it is dangerous to use it
(most people do not understand what the option does):
--arch=i386
I know that there is a (horrible) regression that makes -lm and -lpthreads
sometimes necessary, it would still be great if you could report why it is
needed in your case.
> But it complains it can't find lame:
> ERROR: libmp3lame >= 3.98.3 not found
(Not unrelated:)
Was this the only line printed by configure when it failed
or was there anything else?
Carl Eugen
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
Re: [Libav-user] Windows compile can't find LAME
2018-07-08 18:46 GMT+02:00, Jeremy Gregorio : > ./configure --toolchain=msvc --arch=i386 --enable-yasm --enable-asm > --enable-static --disable-shared --enable-libx264 --enable-libmp3lame > --enable-gpl --extra-ldflags=-L/usr/lib --extra-cflags=-I/usr/include/lame > --host-ldflags=-L/user/lib --extra-libs=-lm --extra-libs=-lpthreads Unrelated: The following options are useless because they are the default and make debugging the configure line more difficult: --enable-yasm --enable-asm --enable-static --disable-shared If the following is unneeded (as I expect), it is dangerous to use it (most people do not understand what the option does): --arch=i386 I know that there is a (horrible) regression that makes -lm and -lpthreads sometimes necessary, it would still be great if you could report why it is needed in your case. > But it complains it can't find lame: > ERROR: libmp3lame >= 3.98.3 not found (Not unrelated:) Was this the only line printed by configure when it failed or was there anything else? Carl Eugen ___ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
