Menu
▾
▴
libquicktime-devel
|
From: Derek C. <der...@mi...> - 2013-08-20 14:14:10
|
Hi Tim et al, I'm looking at giving this a go with the long term view of replacing the use of the Windows QuickTime API to unify Linux + Windows platform code for reading and writing. It's been a while since the last post on this thread, though - any updates on this issue? I'll take Burkhard's advice on MinGW as a starting point. Cheers, Derek |
|
From: Derek C. <der...@mi...> - 2013-09-12 11:09:33
Attachments:
mingw-patches.zip
|
Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support! I've attached some patches I've used - mind I have yet to verify whether they break the linux build. See below for some remarks.
########################
### prerequisites ###
########################
I used the following MinGW-w64 toolchain (to cross compile 32-bit binaries to link with my 32-bit application with a view to later move to 64-bit) + msys builds:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z/download
http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z/download
Using the MinGW-w64 cross-compiler, I've had to add some extra configure parameters to generate appropriate make files.
The following commands with a "$" prompt are ran inside the installed msys shell, with the mingw-w64 toolchain mounted as /mingw...
########################
### building dependencies ###
########################
=== ffmpeg ===
# FFMpeg already has quite a bit of documentation out there how to build Windows libraries so I won't go into any detail. Some links worth looking at:
# https://trac.ffmpeg.org/wiki/MingwCompilationGuide
# http://ffmpeg.zeranoe.com/
# https://github.com/rdp/ffmpeg-windows-build-helpers
=== dlfcn-win32 to wrap dlfcn ===
# https://code.google.com/p/dlfcn-win32/
# (Compiling from source as I couldn't tell what architecture/exception handling the pre-built files were using - besides it's really small and quick to build)
$ tar xvf dlfcn-win32-r19.tar.bz2
$ cd dlfcn-win32-r19
$ ./configure --cross-prefix=i686-w64-mingw32- --prefix=/mingw/i686-w64-mingw32 --libdir=/mingw/i686-w64-mingw32/lib --incdir=/mingw/i686-w64-mingw32/include --enable-shared
$ make
$ make install
$ cd ..
=== GNU libiconv ===
# http://ftpmirror.gnu.org/libiconv
$ tar xvf libiconv-1.14.tar.gz
$ cd libiconv-1.14
$ ./configure --host=i686-w64-mingw32 --prefix=/mingw/i686-w64-mingw32
$ make
$ make install-strip
$ cd ..
NOTE: could've installed elsewhere and used --with-libiconv-prefix option with libquicktime's configure.
=== GNU libintl (can be found as part of gettext) ===
# http://ftpmirror.gnu.org/gettext
$ tar xvf gettext-0.18.3.1.tar.gz
$ cd gettext-0.18.3.1
$ ./configure --host=i686-w64-mingw32 --prefix=/mingw/i686-w64-mingw32
# (If /mingw/bin/i686-w64-mingw32-ar.exe doesn't exist already in your toolchain...)
$ cp /mingw/bin/ar.exe to /mingw/bin/i686-w64-mingw32-ar.exe
$ make
# (If /mingw/bin/i686-w64-mingw32-ranlib.exe doesn't exist already in your toolchain...)
$ cp /mingw/bin/ranlib.exe to /mingw/bin/i686-w64-mingw32-ranlib.exe
$ make install-strip
$ cd ..
########################
### Building libquicktime ###
########################
# NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
$ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
$ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime
# (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
$ cd libquicktime
# replace usage of bzero and bcopy with memset and memcpy:
$ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch
# replace usage of sysconf with getpagesize:
$ patch -p0 003_getpagesize.patch
# localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
# FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
$ patch -p0 004_localtime_s.patch
# add -no-undefined to the libtool calls for making shared libraries:
$ patch -p0 005_libtool_dll_fix.patch
# tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
$ patch -p0 006_pragma_gcc_fix.patch
# fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
# this isn't necessary if you only intend to run programs in the msys environment
$ patch -p0 007_LQT_CODEC_FILE_win_default.patch
# generate the configure script:
$ ./autogen.sh
# fix ffmpeg plugin to link libavutil (Linux doesn't need this so should we bother properly adding the dependency into configure.ac?):
vim plugins/ffmpeg/Makefile
# (add ' -lavutil' to lqt_ffmpeg_la_LIBADD definition)
# configure and build! (You may need to add "PKG_CONFIG_PATH=<path to ffmpeg install prefix>/lib/pkgconfig" to the configure call if you installed ffmpeg somewhere particular.
$ ./configure --host=i686-w64-mingw32 --without-doxygen
$ make
$ make install
# NOTE: Running libquicktime applications outside of msys environment:
As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need to setup an environment variable to correctly point to it's location as the msys path e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...
Comments are welcome!
________________________________________
From: Derek Chow [der...@mi...]
Sent: 20 August 2013 15:14
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows
Hi Tim et al,
I'm looking at giving this a go with the long term view of replacing the
use of the Windows QuickTime API to unify Linux + Windows platform code
for reading and writing.
It's been a while since the last post on this thread, though - any
updates on this issue? I'll take Burkhard's advice on MinGW as a
starting point.
Cheers,
Derek
|
|
From: Burkhard P. <bur...@ig...> - 2013-09-12 13:07:50
|
Hi,
Am 12.09.2013 13:09, schrieb Derek Chow:
> Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support!
Very good.
> I've attached some
> patches I've used - mind I have yet to verify whether they break the linux build. See below for
> some remarks.
[...]
> ########################
> ### Building libquicktime ###
> ########################
>
> # NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
> $ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
> $ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime
>
> # (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
> $ cd libquicktime
You should always patch against cvs.
> # replace usage of bzero and bcopy with memset and memcpy:
> $ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch
Patch looks ok.
> # replace usage of sysconf with getpagesize:
> $ patch -p0 003_getpagesize.patch
This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
by the configure script, but these checks are missing in
configure.ac.
> # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> $ patch -p0 004_localtime_s.patch
+ #else
+ perror("Using thread-unsafe localtime");
+ memcpy(&tm, localtime(&ti), sizeof(tm));
+ #endif
Not sure which systems are affected, but printing repeated error
messages for missing OS festures is no good idea.
> # add -no-undefined to the libtool calls for making shared libraries:
> $ patch -p0 005_libtool_dll_fix.patch
Looks ok if it doesn't break on Linux or OSX (please verify).
> # tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
> $ patch -p0 006_pragma_gcc_fix.patch
+ #ifdef __GNUC__
#pragma GCC visibility push(default)
+ #endif
Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
as a DLL?
In another library, which was ported to Windows, we have something like:
#ifdef DLLEXPORT
#define GAVL_PUBLIC __declspec(dllexport) // Windows
#else
#define GAVL_PUBLIC __attribute__ ((visibility("default"))) // gcc
#endif
And prefix every public functions by GAVL_PUBLIC (for lqt it would be LQT_PUBLIC).
IIRC this was the only clean way to build a shared library on both systems, but I
might be wrong since I didn't do the porting myself.
The code is compliled with -fvisibility=hidden (if supported by the compiler)
In this case, the pragmas are no longer necessary.
> # fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
> # this isn't necessary if you only intend to run programs in the msys environment
> $ patch -p0 007_LQT_CODEC_FILE_win_default.patch
Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
$USERPROFILE could be set and used for something completely unrelated.
[...]
> # NOTE: Running libquicktime applications outside of msys environment:
> As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define
> setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need
> to setup an environment variable to correctly point to it's location as the msys path
> e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...
Currently we use $LIBQUICKTIME_PLUGIN_DIR if that exists, and fall back to the hardcoded
default if it doesn't. If you want, you can propose and alternative method on Windows.
> Comments are welcome!
See above. I didn't apply anything yet though. As already said, patch against CVS and
consider my comments.
Burkhard
|
|
From: Derek C. <der...@mi...> - 2013-09-12 17:19:47
|
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)?
> > # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> > # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> > $ patch -p0 004_localtime_s.patch
> Not sure which systems are affected, but printing repeated error
> messages for missing OS festures is no good idea.
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.
> Looks ok if it doesn't break on Linux or OSX (please verify).
I'll hopefully get back with some tests on Linux soon (but don't have an mac machine handy at the moment to test OSX).
> Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
> as a DLL?
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.
> Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
> happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
> $USERPROFILE could be set and used for something completely unrelated.
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.
________________________________________
From: Burkhard Plaum [bur...@ig...]
Sent: 12 September 2013 14:07
To: lib...@li...
Subject: Re: [Libquicktime-devel] libquicktime on windows
Hi,
Am 12.09.2013 13:09, schrieb Derek Chow:
> Ok, I've got a base win32 build of libquicktime including ffmpeg plugin support!
Very good.
> I've attached some
> patches I've used - mind I have yet to verify whether they break the linux build. See below for
> some remarks.
[...]
> ########################
> ### Building libquicktime ###
> ########################
>
> # NOTE: It's important to do the CVS checkout in the msys shell rather than in a Windows environment to avoid Windows line-endings getting in the way of building.
> $ cvs -d:pserver:ano...@li...:/cvsroot/libquicktime login
> $ cvs -z3 -d:pserver:ano...@li...:/cvsroot/libquicktime co -D2013-05-13 -P libquicktime
>
> # (Sorry, I'm currently not so up-to-date checkout of libquicktime due to the project I'm working with - so I hope the patches still work when I update)
> $ cd libquicktime
You should always patch against cvs.
> # replace usage of bzero and bcopy with memset and memcpy:
> $ patch -p0 002_bzero_bcopy_to_memset_memcpy.patch
Patch looks ok.
> # replace usage of sysconf with getpagesize:
> $ patch -p0 003_getpagesize.patch
This uses HAVE_GETPAGESIZE and HAVE_SYS_PARAM_H, which should be
by the configure script, but these checks are missing in
configure.ac.
> # localtime_r isn't supported in MinGW so I've tried to check for Window's equivalent, localtime_s and fall back to the thread-unsafe localtime...
> # FIXME: Any ideas on how to do this properly as my attempt to hook localtime_s into the autoconf script here doesn't seem to work - it just falls back to localtime.
> $ patch -p0 004_localtime_s.patch
+ #else
+ perror("Using thread-unsafe localtime");
+ memcpy(&tm, localtime(&ti), sizeof(tm));
+ #endif
Not sure which systems are affected, but printing repeated error
messages for missing OS festures is no good idea.
> # add -no-undefined to the libtool calls for making shared libraries:
> $ patch -p0 005_libtool_dll_fix.patch
Looks ok if it doesn't break on Linux or OSX (please verify).
> # tweak the ABI headers to avoid warnings in case I want to use the libquicktime library with other compilers (which I have successfully tried with MSVC 9.0):
> $ patch -p0 006_pragma_gcc_fix.patch
+ #ifdef __GNUC__
#pragma GCC visibility push(default)
+ #endif
Ok but how is the symbol visibility handled on Windows? Did you compile libquicktime
as a DLL?
In another library, which was ported to Windows, we have something like:
#ifdef DLLEXPORT
#define GAVL_PUBLIC __declspec(dllexport) // Windows
#else
#define GAVL_PUBLIC __attribute__ ((visibility("default"))) // gcc
#endif
And prefix every public functions by GAVL_PUBLIC (for lqt it would be LQT_PUBLIC).
IIRC this was the only clean way to build a shared library on both systems, but I
might be wrong since I didn't do the porting myself.
The code is compliled with -fvisibility=hidden (if supported by the compiler)
In this case, the pragmas are no longer necessary.
> # fix LQT_CODEC_FILE default to work for windows environments that don't define HOME - using USERPROFILE instead (e.g. "C:\Users\<username>").
> # this isn't necessary if you only intend to run programs in the msys environment
> $ patch -p0 007_LQT_CODEC_FILE_win_default.patch
Please make a unified diff so I can look at it. Trying to check for $USERPROFILE should
happen on Windows only. On Posix systems, this always fails and just wastes time. Or (even worse)
$USERPROFILE could be set and used for something completely unrelated.
[...]
> # NOTE: Running libquicktime applications outside of msys environment:
> As the path that libquicktime searches for it's plugins is currently hardcoded based on a #define
> setup by the configure script (http://libquicktime.sourceforge.net/doc/codecs.html), you need
> to setup an environment variable to correctly point to it's location as the msys path
> e.g. '/c/dev/libquicktime/lib/libquicktime' won't make much sense to Windows natively...
Currently we use $LIBQUICKTIME_PLUGIN_DIR if that exists, and fall back to the hardcoded
default if it doesn't. If you want, you can propose and alternative method on Windows.
> Comments are welcome!
See above. I didn't apply anything yet though. As already said, patch against CVS and
consider my comments.
Burkhard
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Libquicktime-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libquicktime-devel
|
|
From: Burkhard P. <bur...@ig...> - 2013-09-27 13:48:33
|
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
|
|
From: Derek C. <der...@mi...> - 2013-10-03 15:07:43
Attachments:
win_localtime.diff
|
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
|
|
From: Burkhard P. <bur...@ig...> - 2013-10-07 14:39:23
|
Hi, Am 03.10.2013 17:07, schrieb Derek Chow: > 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)? Agree, applied. >> 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. Applied Burkhard |
|
From: Christian E. <bla...@gm...> - 2013-10-07 15:00:58
|
* Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200
> Am 03.10.2013 17:07, schrieb Derek Chow:
>> 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)?
>
> Agree, applied.
>
>>> 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.
>
> Applied
The above, or one of the above causes build to fail on Mac OS
10.8.5:
libtool: link: gcc -o .libs/lqt_vorbis.so -bundle .libs/vorbis.o .libs/lqt_vorbis.o -L/usr/local/lib -L/sw/lib ../../src/.libs/libquicktime.dylib /sw/lib/libiconv.dylib /sw/lib/libintl.dylib /sw/lib/libvorbisenc.dylib /sw/lib/libvorbis.dylib /sw/lib/libvorbisfile.dylib -lm -lz -ldl -O3
Undefined symbols for architecture x86_64:
"_ogg_page_eos", referenced from:
_flush_data in vorbis.o
"_ogg_page_serialno", referenced from:
_next_page in vorbis.o
"_ogg_stream_clear", referenced from:
_delete_codec in vorbis.o
_decode in vorbis.o
"_ogg_stream_flush", referenced from:
_encode in vorbis.o
_flush_data in vorbis.o
"_ogg_stream_init", referenced from:
_encode in vorbis.o
_next_page in vorbis.o
"_ogg_stream_packetin", referenced from:
_encode in vorbis.o
_flush_data in vorbis.o
"_ogg_stream_packetout", referenced from:
_decode in vorbis.o
_decode_frame in vorbis.o
"_ogg_stream_pagein", referenced from:
_next_page in vorbis.o
"_ogg_sync_buffer", referenced from:
_next_page in vorbis.o
"_ogg_sync_init", referenced from:
_decode in vorbis.o
"_ogg_sync_pageout", referenced from:
_next_page in vorbis.o
"_ogg_sync_reset", referenced from:
_decode in vorbis.o
"_ogg_sync_wrote", referenced from:
_next_page in vorbis.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [lqt_vorbis.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
--
Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies --->>> http://www.blacktrash.org/underdogma
http://itunes.apple.com/podcast/underdogma-movies/id363423596
|
|
From: Burkhard P. <bur...@ig...> - 2013-10-08 09:11:58
|
Hi, Am 07.10.2013 17:00, schrieb Christian Ebert: > * Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200 >> Am 03.10.2013 17:07, schrieb Derek Chow: >>> 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)? >> >> Agree, applied. >> >>>> 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. >> >> Applied > > The above, or one of the above causes build to fail on Mac OS > 10.8.5: [...] Oops. Ok, I introduced a variable MODULE_LDFLAGS, which is set by configure and used in plugins/*/Makefile.am Currently it's set to "-no-undefined" just for Linux. It can easily be tweaked for other systems depending on the variable $host_os, but I don't know what values $host_os has on Win32 and Win64. Maybe Derek can find this out and make a patch for configure.ac. Burkhard |
|
From: Derek C. <der...@mi...> - 2013-11-15 15:37:27
Attachments:
mingw-no-undefined-ldflag.diff
|
Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS. ________________________________________ From: Burkhard Plaum [bur...@ig...] Sent: 08 October 2013 10:11 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Hi, Am 07.10.2013 17:00, schrieb Christian Ebert: > * Burkhard Plaum on Monday, October 07, 2013 at 16:39:12 +0200 >> Am 03.10.2013 17:07, schrieb Derek Chow: >>> 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)? >> >> Agree, applied. >> >>>> 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. >> >> Applied > > The above, or one of the above causes build to fail on Mac OS > 10.8.5: [...] Oops. Ok, I introduced a variable MODULE_LDFLAGS, which is set by configure and used in plugins/*/Makefile.am Currently it's set to "-no-undefined" just for Linux. It can easily be tweaked for other systems depending on the variable $host_os, but I don't know what values $host_os has on Win32 and Win64. Maybe Derek can find this out and make a patch for configure.ac. 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=60134071&iu=/4140/ostg.clktrk _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel |
|
From: Burkhard P. <bur...@ig...> - 2013-11-19 16:48:32
|
Hi, Am 15.11.2013 16:20, schrieb Derek Chow: > Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS. > ________________________________________ Applied. Do I understand it right that libquicktime CVS now compiles in mingw in 32- and 64 bit, provided all dependencies are installed? Burkhard |
|
From: Derek C. <der...@mi...> - 2013-11-19 17:37:33
|
I have verified that it compiles for target 32-bit hosts on a Windows (8) 64-bit machine - having compiled dependencies including: - https://code.google.com/p/dlfcn-win32/ - http://ftpmirror.gnu.org/gettext/gettext-0.18.3.1.tar.gz (for libintl in gettext-runtime) - http://prdownloads.sourceforge.net/libpng/zlib-1.2.8.tar.xz?download - ffmpeg Plugins output from my build include: - lqt_audiocodec - lqt_ffmpeg - lqt_rtjpeg - lqt_videocodec So have yet to see if the other 3rd party plugins work. Will get back to you if there are any other required changes for the 64-bit toolchain :) ________________________________________ From: Burkhard Plaum [bur...@ig...] Sent: 19 November 2013 16:48 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Hi, Am 15.11.2013 16:20, schrieb Derek Chow: > Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS. > ________________________________________ Applied. Do I understand it right that libquicktime CVS now compiles in mingw in 32- and 64 bit, provided all dependencies are installed? Burkhard ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel |
|
From: Derek C. <der...@mi...> - 2013-11-20 16:32:55
Attachments:
getpagesize.diff
|
Ahh but I am also using that getpagesize() fix that I need to send you an updated patch for (see attached). ________________________________________ From: Derek Chow Sent: 19 November 2013 17:37 To: lib...@li... Subject: RE: [Libquicktime-devel] libquicktime on windows I have verified that it compiles for target 32-bit hosts on a Windows (8) 64-bit machine - having compiled dependencies including: - https://code.google.com/p/dlfcn-win32/ - http://ftpmirror.gnu.org/gettext/gettext-0.18.3.1.tar.gz (for libintl in gettext-runtime) - http://prdownloads.sourceforge.net/libpng/zlib-1.2.8.tar.xz?download - ffmpeg Plugins output from my build include: - lqt_audiocodec - lqt_ffmpeg - lqt_rtjpeg - lqt_videocodec So have yet to see if the other 3rd party plugins work. Will get back to you if there are any other required changes for the 64-bit toolchain :) ________________________________________ From: Burkhard Plaum [bur...@ig...] Sent: 19 November 2013 16:48 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Hi, Am 15.11.2013 16:20, schrieb Derek Chow: > Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS. > ________________________________________ Applied. Do I understand it right that libquicktime CVS now compiles in mingw in 32- and 64 bit, provided all dependencies are installed? Burkhard ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel |
|
From: Derek C. <der...@mi...> - 2013-11-21 13:53:20
Attachments:
fix_lqt_dump_time_warning.diff
|
Attaching a type mismatch fix in the MinGW code for lqt_dump_time... ________________________________________ From: Derek Chow [der...@mi...] Sent: 20 November 2013 16:32 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Ahh but I am also using that getpagesize() fix that I need to send you an updated patch for (see attached). ________________________________________ From: Derek Chow Sent: 19 November 2013 17:37 To: lib...@li... Subject: RE: [Libquicktime-devel] libquicktime on windows I have verified that it compiles for target 32-bit hosts on a Windows (8) 64-bit machine - having compiled dependencies including: - https://code.google.com/p/dlfcn-win32/ - http://ftpmirror.gnu.org/gettext/gettext-0.18.3.1.tar.gz (for libintl in gettext-runtime) - http://prdownloads.sourceforge.net/libpng/zlib-1.2.8.tar.xz?download - ffmpeg Plugins output from my build include: - lqt_audiocodec - lqt_ffmpeg - lqt_rtjpeg - lqt_videocodec So have yet to see if the other 3rd party plugins work. Will get back to you if there are any other required changes for the 64-bit toolchain :) ________________________________________ From: Burkhard Plaum [bur...@ig...] Sent: 19 November 2013 16:48 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Hi, Am 15.11.2013 16:20, schrieb Derek Chow: > Sorry for the radio silence - I've attached mingw case for $host_os to add "-no-undefined" to the MODULE_LDFLAGS. > ________________________________________ Applied. Do I understand it right that libquicktime CVS now compiles in mingw in 32- and 64 bit, provided all dependencies are installed? Burkhard ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel |
|
From: Burkhard P. <bur...@ig...> - 2013-11-21 16:49:44
|
Hi, Am 21.11.2013 14:53, schrieb Derek Chow: > Attaching a type mismatch fix in the MinGW code for lqt_dump_time... Applied > ________________________________________ > From: Derek Chow [der...@mi...] > Sent: 20 November 2013 16:32 > To: lib...@li... > Subject: Re: [Libquicktime-devel] libquicktime on windows > > Ahh but I am also using that getpagesize() fix that I need to send you an updated patch for (see attached). > Applied Burkhard |
|
From: Derek C. <der...@mi...> - 2013-11-21 18:10:02
Attachments:
mingw_unicode_stat64_fix.patch
|
Here's patch to work around lack of unicode UTF-8 with Microsoft C runtime (and also fix an issue I'm seeing with my MinGW failing to #define stat() with large file support). ________________________________________ From: Burkhard Plaum [bur...@ig...] Sent: 21 November 2013 16:49 To: lib...@li... Subject: Re: [Libquicktime-devel] libquicktime on windows Hi, Am 21.11.2013 14:53, schrieb Derek Chow: > Attaching a type mismatch fix in the MinGW code for lqt_dump_time... Applied > ________________________________________ > From: Derek Chow [der...@mi...] > Sent: 20 November 2013 16:32 > To: lib...@li... > Subject: Re: [Libquicktime-devel] libquicktime on windows > > Ahh but I am also using that getpagesize() fix that I need to send you an updated patch for (see attached). > Applied Burkhard ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Libquicktime-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libquicktime-devel |
|
From: Burkhard P. <bur...@ig...> - 2013-11-27 17:12:13
|
Hi, Am 21.11.2013 19:09, schrieb Derek Chow: > Here's patch to work around lack of unicode UTF-8 with Microsoft C runtime (and also > fix an issue I'm seeing with my MinGW failing to #define stat() with large file support). Applied. Burkhard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X