[vlc-devel] Fwd: Set of configure patches

[Martell Malone]

Apologies I hit reply not realizing it missed the mailing list


> Fair enough. The code still makes no sense to me.

What about it don't you understand ?

It try's to compile a test program. If that fails then it knows that the
platform doesn't have this function.
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.

I attached updated patch without the unused macro.

That makes more sense.
>
Attached updated patch for this, this one was my mistake.
Thanks for pointing this out to me.

POSIX localtime_r() and gmtime_r "shall be declared as functions and may
> also
> be defined as macros". In POSIX parliance, that means they must resolve at
> linker stage - even if the function call can be inlined. (Two reasons why:
> making dlsym() work, and allowing function pointers.)
>

I'm going to make this very simple to understand.
Autotools has no support for inline when detecting functions so localtime_r
and gmtime_r are not detected
The vlc versions are compiled as a c source.
Thus at link time for a c++ module we now have a c implementation and a c++
implementation of the same function.
This results in an error and rightfully so.

I do not care who is in charge of what. This is a mingw64 bug. This needs a
> mingw64 fix. There is nothing to discuss by mings64 people and even less
> so by
> VLC developers
>

There is no issue with mingw-w64,
The fix is perfectly valid and there is nothing wrong with the patch.
The section i even inserted it into already had this comment above it
because it is for this purpose.

> dnl mingw64 implements those as static inline, not functions with C linkage
>

Here is a link to the mingw-w64 mailing list patch where they changed it to
inline.
https://sourceforge.net/p/mingw-w64/mailman/message/33208152/

Also I would like to note that mingw-w64 does not claim to be fully POSIX
compatible.
In reality it cant be because WIN32 is not POSIX
So much as I agree with you and you are correct about the implementation.
We still have to deal with the reality of that

Kind Regards
Martell


On Tue, Jan 13, 2015 at 11:01 PM, Rémi Denis-Courmont <remi at remlab.net>
wrote:

> Le mardi 13 janvier 2015, 21:57:21 Martell Malone a écrit :
> > I agree with you that it would be a concern but
> > I highly doubt that it will as that program should build successfully for
> > OS/2 still resulting in AC_LIBOBJ([freeaddrinfo])
>
> Fair enough. The code still makes no sense to me.
>
> > 2.
> >
> > > There is already code for this, so this patch is either redundant or
> > > wrong.
> >
> > You are correct it is there already, I somehow missed this before.
> >
> > You do have AC_CHECK_TYPES([struct pollfd]
> > but that comes with a
> > # define _WIN32_WINNT 0x502
> > which forces windows xp
> > I could submit a patch that removes this line if that is better suited
> then
> > actually detecting it via compiling.
> > Would that be acceptable ??
>
> That makes more sense.
>
> > 3.
> >
> > > So fix mingw64?
> >
> >  I actually submitteed a patch that was merged to create actual functions
> > for the time functions over previous defines
> > It was merged but there has been a lenghty discussion since where they
> have
> > opted for inline
> > I am not in charge of mingw-w64 so I can't change this.
>
> POSIX localtime_r() and gmtime_r "shall be declared as functions and may
> also
> be defined as macros". In POSIX parliance, that means they must resolve at
> linker stage - even if the function call can be inlined. (Two reasons why:
> making dlsym() work, and allowing function pointers.)
>
> I do not care who is in charge of what. This is a mingw64 bug. This needs a
> mingw64 fix. There is nothing to discuss by mings64 people and even less
> so by
> VLC developers.
>
> --
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150114/fa06c248/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Search-for-freeaddrinfo-in-SOCKET_LIBS.patch
Type: application/octet-stream
Size: 1420 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150114/fa06c248/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-struct-pollfd-is-available-from-vista-stop-forcing-d.patch
Type: application/octet-stream
Size: 623 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150114/fa06c248/attachment-0001.obj>