Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
Hi/2. Dave Yeo wrote: > On 06/13/20 07:03 AM, KO Myung-Hun wrote: >> Hi/2. >> >> Dave Yeo wrote: >>> On 06/11/20 10:26 AM, Michael Niedermayer wrote: On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote: > On 06/10/20 02:09 PM, Michael Niedermayer wrote: >> On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: >>> Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a >>> build break >>> in libavformat/ip.c (implicit declaration of function >>> 'getaddrinfo') and >>> also need the prototype. >>> Thanks, >>> Dave >> it seems this breaks build on linux > > Sorry about that, I'll test on Linux in the future. > Here's a better patch as it doesn't touch configure. > Thanks, > Dave I can confirm this does not break build anymore, but iam not OS/2 maintainer nor do i have such box so ill leave review / application to someone better suited for this thx [...] >>> >>> Fair enough, I'll CC KOMH >> >> I have no problems at all with gcc 9.1.0 because FFmpeg already has >> replacements for missing functions such as getaddrinfo(). >> >> What is your build environment ? Maybe is libcx linked by default ? >> > > The problem only occurs if I link in libcx, LIBS=-lcx. > Note that with libcx, the build system finds its getaddrinfo() and later > fails due to no prototype and will also fail as part of the addrinfo > struct uses a different type (char vs int IIRC). Without LIBS=-lcx, the > build falls back to FFmpeg's builtin getaddrinfo(). > One of the main reasons to link to libcx is for the exceptq support. > Also as it is recommended, others are likely to do the same thing. Ok, then it would be be better to elaborate commit message. > From f9fbdaaf6cdb6f886cbdf31c1983e452567cd857 Mon Sep 17 00:00:00 2001 > From: Dave Yeo > Date: Tue, 9 Jun 2020 22:51:53 -0700 > Subject: [PATCH] OS/2:Support linking against libcx > > Libcx contains extensions to libc such as getaddrinfo(), mmap() and poll(). > While recommended to link against, it is optional > > Signed-off-by: Dave Yeo > --- > configure| 1 + > libavformat/os_support.h | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/configure b/configure > index 8569a60bf8..24ad990b52 100755 > --- a/configure > +++ b/configure > @@ -5997,6 +5997,7 @@ if ! disabled network; then > check_func inet_aton $network_extralibs > > check_type netdb.h "struct addrinfo" > +check_type libcx/net.h "struct addrinfo" Check libcx/net.h first like: if check_headers libcx/net.h ; then check_type libcx/net.h "struct addrinfo" fi Otherwise, platforms without libcx/net.h are treated as not having `struct addrinfo' even if they have actually. I think, this is the cause of build failure on linux. > check_type netinet/in.h "struct group_source_req" -D_BSD_SOURCE > check_type netinet/in.h "struct ip_mreq_source" -D_BSD_SOURCE > check_type netinet/in.h "struct ipv6_mreq" -D_DARWIN_C_SOURCE > diff --git a/libavformat/os_support.h b/libavformat/os_support.h > index 5e6b32d2dc..1904fc8d5d 100644 > --- a/libavformat/os_support.h > +++ b/libavformat/os_support.h > @@ -56,6 +56,9 @@ > # define fstat(f,s) _fstati64((f), (s)) > #endif /* defined(_WIN32) */ > > +#if defined (__OS2__) && defined (HAVE_GETADDRINFO) > +#include > +#endif > HAVE_GETADDRINFO does not guarantee libcx/net.h. Use #if HAVE_LIBCX_NET_H guard. If you prefer, it's ok to check __OS2__ definition additionally. FYI, HAVE_GETADDRINFO is always defined to either 0 or 1. So checking it with `defined' is always true. For HAVE_LIBCX_NET_H, you should add `libcx_net_h' to HEADERS_LIST. Thanks. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.10 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.os2.kr/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
On 06/13/20 07:03 AM, KO Myung-Hun wrote: Hi/2. Dave Yeo wrote: On 06/11/20 10:26 AM, Michael Niedermayer wrote: On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote: On 06/10/20 02:09 PM, Michael Niedermayer wrote: On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and also need the prototype. Thanks, Dave it seems this breaks build on linux Sorry about that, I'll test on Linux in the future. Here's a better patch as it doesn't touch configure. Thanks, Dave I can confirm this does not break build anymore, but iam not OS/2 maintainer nor do i have such box so ill leave review / application to someone better suited for this thx [...] Fair enough, I'll CC KOMH I have no problems at all with gcc 9.1.0 because FFmpeg already has replacements for missing functions such as getaddrinfo(). What is your build environment ? Maybe is libcx linked by default ? The problem only occurs if I link in libcx, LIBS=-lcx. Note that with libcx, the build system finds its getaddrinfo() and later fails due to no prototype and will also fail as part of the addrinfo struct uses a different type (char vs int IIRC). Without LIBS=-lcx, the build falls back to FFmpeg's builtin getaddrinfo(). One of the main reasons to link to libcx is for the exceptq support. Also as it is recommended, others are likely to do the same thing. Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
Hi/2. Dave Yeo wrote: > On 06/11/20 10:26 AM, Michael Niedermayer wrote: >> On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote: >>> On 06/10/20 02:09 PM, Michael Niedermayer wrote: On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: > Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a > build break > in libavformat/ip.c (implicit declaration of function > 'getaddrinfo') and > also need the prototype. > Thanks, > Dave it seems this breaks build on linux >>> >>> Sorry about that, I'll test on Linux in the future. >>> Here's a better patch as it doesn't touch configure. >>> Thanks, >>> Dave >> >> I can confirm this does not break build anymore, but iam not OS/2 >> maintainer nor do i have such box so ill leave review / application >> to someone better suited for this >> >> thx >> [...] > > Fair enough, I'll CC KOMH I have no problems at all with gcc 9.1.0 because FFmpeg already has replacements for missing functions such as getaddrinfo(). What is your build environment ? Maybe is libcx linked by default ? -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.10 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.os2.kr/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
On 06/11/20 10:26 AM, Michael Niedermayer wrote: On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote: On 06/10/20 02:09 PM, Michael Niedermayer wrote: On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and also need the prototype. Thanks, Dave it seems this breaks build on linux Sorry about that, I'll test on Linux in the future. Here's a better patch as it doesn't touch configure. Thanks, Dave I can confirm this does not break build anymore, but iam not OS/2 maintainer nor do i have such box so ill leave review / application to someone better suited for this thx [...] Fair enough, I'll CC KOMH Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
On Wed, Jun 10, 2020 at 09:24:51PM -0700, Dave Yeo wrote: > On 06/10/20 02:09 PM, Michael Niedermayer wrote: > > On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: > > > Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build > > > break > > > in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and > > > also need the prototype. > > > Thanks, > > > Dave > > it seems this breaks build on linux > > Sorry about that, I'll test on Linux in the future. > Here's a better patch as it doesn't touch configure. > Thanks, > Dave I can confirm this does not break build anymore, but iam not OS/2 maintainer nor do i have such box so ill leave review / application to someone better suited for this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
On 06/10/20 02:09 PM, Michael Niedermayer wrote: On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and also need the prototype. Thanks, Dave it seems this breaks build on linux Sorry about that, I'll test on Linux in the future. Here's a better patch as it doesn't touch configure. Thanks, Dave From 033add727ca8c512a3f4a7d24fde88bb8c0455c8 Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Wed, 10 Jun 2020 18:55:44 -0700 Subject: [PATCH] libavformat/os_support.h:OS/2, support linking against libcx Libcx contains extensions to libc such as getaddrinfo(), mmap() and poll(). While recommended to link against, it is optional Signed-off-by: Dave Yeo --- libavformat/os_support.h | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..6c60844b7d 100644 --- a/libavformat/os_support.h +++ b/libavformat/os_support.h @@ -56,6 +56,10 @@ # define fstat(f,s) _fstati64((f), (s)) #endif /* defined(_WIN32) */ +#if defined (__OS2__) && defined (HAVE_GETADDRINFO) +#include +#define HAVE_STRUCT_ADDRINFO 1 +#endif #ifdef __ANDROID__ # if HAVE_UNISTD_H -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OS/2:Support linking against libcx
On Tue, Jun 09, 2020 at 11:11:48PM -0700, Dave Yeo wrote: > Hi, could I get this pushed to trunk and the 4.3 branch? Fixes a build break > in libavformat/ip.c (implicit declaration of function 'getaddrinfo') and > also need the prototype. > Thanks, > Dave it seems this breaks build on linux CC libavformat/avio.o In file included from libavformat/avio.c:31:0: libavformat/network.h:137:8: error: redefinition of ‘struct addrinfo’ struct addrinfo { ^~~~ In file included from libavformat/network.h:66:0, from libavformat/avio.c:31: /usr/include/netdb.h:565:8: note: originally defined here struct addrinfo ^~~~ ffbuild/common.mak:59: recipe for target 'libavformat/avio.o' failed make: *** [libavformat/avio.o] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".