Re: [Libquicktime-devel] libquicktime on windows

[Derek C. <der...@mi...>]

cool,

> Applied 004_localtime_s.patch with a tiny fix
> _localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S

Looking back at that patch, I reckon the check for defined(_WIN64) is also probably unnecessary.  How about a further change to just see if these msvcrt methods are available when we resort to them (see attached win_localtime.diff)?

> So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
> and testing 005_libtool_dll_fix.patch on some other systems.

FYI I've used 005_libtool_dll_fix.patch for builds on linux with no apparent issues.

________________________________________
From: Burkhard Plaum [bur...@ig...]
Sent: 27 September 2013 14:48
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows

Hi,

sorry for the delay....

I applied:
002_bzero_bcopy_to_memset_memcpy.patch


Am 12.09.2013 19:19, schrieb Derek Chow:
> Hi Burkhard,
>
>> This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
>> by the configure script, but these checks are missing in
>> configure.ac.
>
> I've been relying on the implicit check that AC_FUNC_MMAP does - I've tried using
 > AC_CHECK_FUNCS_ONCE on getpagesize to explicitly ensure it's checked but it still bloats
 > the configure script with duplicate checks because the implicit check uses AC_CHECK_FUNCS.
 > Shall we just stick it on the AC_CHECK_FUNCS call in configure.ac anyway (if it's cached I
 > suppose it's not that slow)?

I'd not rely on implicit checks, because AC_FUNC_MMAP might be changed in the future.
The autotools cause enough headaches with version compatibilities already....

> I've attached a new 004_localtime_s.patch that works around the missing localtime_s export from
 > msvcrt in MinGW - instead use the _localtime{32,64}_s functions (which localtime_s basically
 > inlines depending on the target arch).  Also replaced the perror with a comment when falling back
 > to the non-reentrant localtime.

Applied 004_localtime_s.patch with a tiny fix
_localtime64_s was ifdefed with HAVE__LOCALTIME32_S instead of HAVE__LOCALTIME64_S

> I compiled libquicktime as a dll and linked to it in an MSVC built application with the
 > generated libquicktime.dll.a import library - it would appear that the use of -fvisibility=hidden
 > is externing the functions correctly.

Ahh now I got it. The problem was a non-gcc compiler stumbling on the *header* file when compiling
an application (not libquicktime istelf).

Applied 006_pragma_gcc_fix.patch


> I've attached a new unified diff for 007_LQT_CODEC_FILE_win_default.patch that #ifdef's the usage of USERPROFILE only for Windows.

Ok, applied 007_LQT_CODEC_FILE_win_default.patch

So from what I see, the only missing issues are the HAVE_SYS_PARAM_H check from 003_getpagesize.patch
and testing 005_libtool_dll_fix.patch on some other systems.

Burkhard

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Libquicktime-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libquicktime-devel