Re: [FFmpeg-devel] configure doesn't seem to use pkg-config flags?

[epirat07@gmail.com]

On 31 Jan 2024, at 13:03, Timo Rothenpieler wrote:

> On 31/01/2024 05:31, Roger Pack wrote:
>> On Thu, Jan 18, 2024 at 6:31 AM Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>>
>>>
>>>
>>> On 18/01/2024 04:38, Roger Pack wrote:
>>>> Hello.
>>>> After compiling libx265 as a "static library" (mingw cross compiling
>>>> targeting win64)
>>>>
>>>> $ pkg-config --libs --static x265
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>>>>
>>>> I get this failure at configure time:
>>>>
>>>> ./configure --enable-libx265 --arch=x86_64 --target-os=mingw32
>>>> --cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config
>>>> --pkg-config-flags=--static
>>>>
>>>> ERROR: x265 not found using pkg-config
>>>>
>>>> config.log (sorry it's verbose, first compile passes, second one fails linking)
>>>>
>>>> ...
>>>> require_pkg_config libx265 x265 x265.h x265_api_get
>>>> check_pkg_config libx265 x265 x265.h x265_api_get
>>>> test_pkg_config libx265 x265 x265.h x265_api_get
>>>> pkg-config --exists --print-errors x265
>>>> check_func_headers x265.h x265_api_get
>>>> -I/home/rdp/new/sandbox/win64_static/build_files/include
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>>>> test_ld cc -I/home/rdp/new/sandbox/win64_static/build_files/include
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>>>> test_cc -I/home/rdp/new/sandbox/win64_static/build_files/include
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a
>>>> BEGIN /tmp/ffconf.L9GhKESq/test.c
>>>>       1   #include <x265.h>
>>>>       2   #include <stdint.h>
>>>>       3   long check_x265_api_get(void) { return (long) x265_api_get; }
>>>>       4   int main(void) { int ret = 0;
>>>>       5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
>>>>       6   return ret; }
>>>> END /tmp/ffconf.L9GhKESq/test.c
>>>> x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
>>>> -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>>>> -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600
>>>> -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11
>>>> -fomit-frame-pointer
>>>> -I/home/rdp/new/sandbox/win64_static/build_files/include
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -c -o
>>>> /tmp/ffconf.L9GhKESq/test.o /tmp/ffconf.L9GhKESq/test.c
>>>> /tmp/ffconf.L9GhKESq/test.c: In function 'check_x265_api_get':
>>>> /tmp/ffconf.L9GhKESq/test.c:3:40: warning: cast from pointer to
>>>> integer of different size [-Wpointer-to-int-cast]
>>>>       3 | long check_x265_api_get(void) { return (long) x265_api_get; }
>>>>         |                                        ^
>>>> x86_64-w64-mingw32-gcc: warning:
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
>>>> file unused because linking not done
>>>> x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
>>>> -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000
>>>> -I/home/rdp/new/sandbox/win64_static/build_files/include
>>>> -L/home/rdp/new/sandbox/win64_static/build_files/lib
>>>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
>>>> /tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
>>>> /usr/bin/x86_64-w64-mingw32-ld:
>>>> /home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
>>>> undefined reference to `operator new(unsigned long long)'
>>>> /usr/bin/x86_64-w64-mingw32-ld:
>>>> /home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0x1303):
>>>> undefined reference to `operator delete(void*)'
>>>> ...
>>>>
>>>> So it seems to be linking it not using the output of pkg-config --libs
>>>> --static for linking or something?
>>>
>>> It's passing the pkg-config flags just fine.
>>> The x265 .pc file is just broken and does not state its dependency on
>>> libstdc++
>>
>> x265.pc does list libstdc++
>>
>> $ pkg-config --libs --static x265
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>
> I don't think that's a valid way to specify libs by absolute path.

There is nothing invalid about that, to my knowledge.

> At least configure doesn't think so, it specifically looks for stuff starting with "-l" and discards the rest. Try adding -l: to the beginning.

Just adding -l to the beginning does sound invalid though.

You could do -L/usr/lib/gcc/x86_64-w64-mingw32/10-win32/ -lstdc++

But it should work just fine the way it is, I do not think discarding everything not starting with -l is correct.

>
>
>> When I configure ffmpeg I specify ./configure --pkg-config-flags=--static
>>
>> But it appears to be rearranging the order when configure tries to use it?
>>
>> x86_64-w64-mingw32-gcc: warning:
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
>> file unused because linking not done
>> x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
>> -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000
>> -I/home/rdp/new/sandbox/win64_static/build_files/include
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
>> /tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
>> # THIS LINE has only x265 and lgcc
>>
>> /usr/bin/x86_64-w64-mingw32-ld:
>> /home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
>> undefined reference to `operator new(unsigned long long)'
>>
>>
>> Possibly useful info:
>>
>> $ pkg-config --libs x265
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>> $ pkg-config --libs x265 --static
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>>
>> It doesn't seem to be using either of those somehow...though I suppose
>> if I cared enough I could try and figure it out :)
>>
>> Cheers, thank you!
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".