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 <daver...@telus.net> > 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 <daver...@telus.net> > --- > 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 <libcx/net.h> > +#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".