<div dir="ltr">Apologies I hit reply not realizing it missed the mailing list<br><div><div class="gmail_quote"><div dir="ltr"><span class=""><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Fair enough. The code still makes no sense to me.</blockquote></span><div>What about it don't you understand ?<br><br></div><div>It try's to compile a test program. If that fails then it knows that the platform doesn't have this function.<br></div><div>So it adds the vlc version of the function to be built. 2 known platforms where this is applicable are OS/2 and windows pre vista.<br><br></div><div>I attached updated patch without the unused macro.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">That makes more sense.<br></blockquote><div>Attached updated patch for this, this one was my mistake.<br></div><div>Thanks for pointing this out to me.<br></div><div><span class=""><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">POSIX localtime_r() and gmtime_r "shall be declared as functions and may also<br>
be defined as macros". In POSIX parliance, that means they must resolve at<br>
linker stage - even if the function call can be inlined. (Two reasons why:<br>
making dlsym() work, and allowing function pointers.)<br></blockquote></span><div> <br>I'm going to make this very simple to understand. <br>Autotools has no support for inline when detecting functions so localtime_r and gmtime_r are not detected<br>The vlc versions are compiled as a c source. <br>Thus at link time for a c++ module we now have a c implementation and a c++ implementation of the same function.<br>This results in an error and rightfully so.<br><br></div><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
I do not care who is in charge of what. This is a mingw64 bug. This needs a<br>
mingw64 fix. There is nothing to discuss by mings64 people and even less so by<br>
VLC developers<br></blockquote><br></span></div><div>There is no issue with mingw-w64,<br>The fix is perfectly valid and there is nothing wrong with the patch.<br>The section i even inserted it into already had this comment above it because it is for this purpose.<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">dnl mingw64 implements those as static inline, not functions with C linkage<br></blockquote><div><br></div><div>Here is a link to the mingw-w64 mailing list patch where they changed it to inline.<br><a href="https://sourceforge.net/p/mingw-w64/mailman/message/33208152/">https://sourceforge.net/p/mingw-w64/mailman/message/33208152/</a><br><br></div><div>Also I would like to note that mingw-w64 does not claim to be fully POSIX compatible.<br></div><div>In reality it cant be because WIN32 is not POSIX<br>So much as I agree with you and you are correct about the implementation.<br>We still have to deal with the reality of that <br></div><div><br></div><div>Kind Regards<span class=""><font color="#888888"><br></font></span></div><span class=""><font color="#888888"><div>Martell<br></div></font></span></div><div><br></div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 11:01 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le mardi 13 janvier 2015, 21:57:21 Martell Malone a écrit :<br>
<span>> I agree with you that it would be a concern but<br>
> I highly doubt that it will as that program should build successfully for<br>
> OS/2 still resulting in AC_LIBOBJ([freeaddrinfo])<br>
<br>
</span>Fair enough. The code still makes no sense to me.<br>
<span><br>
> 2.<br>
><br>
> > There is already code for this, so this patch is either redundant or<br>
> > wrong.<br>
><br>
> You are correct it is there already, I somehow missed this before.<br>
><br>
> You do have AC_CHECK_TYPES([struct pollfd]<br>
> but that comes with a<br>
> # define _WIN32_WINNT 0x502<br>
> which forces windows xp<br>
> I could submit a patch that removes this line if that is better suited then<br>
> actually detecting it via compiling.<br>
> Would that be acceptable ??<br>
<br>
</span>That makes more sense.<br>
<span><br>
> 3.<br>
><br>
> > So fix mingw64?<br>
><br>
>  I actually submitteed a patch that was merged to create actual functions<br>
> for the time functions over previous defines<br>
> It was merged but there has been a lenghty discussion since where they have<br>
> opted for inline<br>
> I am not in charge of mingw-w64 so I can't change this.<br>
<br>
</span>POSIX localtime_r() and gmtime_r "shall be declared as functions and may also<br>
be defined as macros". In POSIX parliance, that means they must resolve at<br>
linker stage - even if the function call can be inlined. (Two reasons why:<br>
making dlsym() work, and allowing function pointers.)<br>
<br>
I do not care who is in charge of what. This is a mingw64 bug. This needs a<br>
mingw64 fix. There is nothing to discuss by mings64 people and even less so by<br>
VLC developers.<br>
<span><font color="#888888"><br>
--<br>
Rémi<br>
</font></span></blockquote></div><br></div>
</div></div></div><br></div></div>