Nakai,
Does that imply that there is something wrong with the .def file?
I added -A and -k and still get the same error.
Thanks,
Kyle
-Original Message-
From: Nakai Yuta [mailto:nak5...@live.jp]
Sent: Saturday, September 5, 2015 1:50 AM
To: mingw-w64-public@lists.sourceforge.net
1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000
clEnqueueNDRangeKernel
[ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
__imp_clEnqueueNDRangeKernel
Thanks,
Kyle
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Hello all,
I am working on a project which I am compiling with Mingw64 and I need use
some of the ADS COM functions which depend upon adsiid.lib.
It doesn't appear that [out of the box] Mingw64 has this .a lib. Therefore,
I am getting undefined reference issues, etc.
Is there any possible way to
I'm getting the following error while trying to compile a i686 (32-bit)
toolchain using the latest MinGW-w64 sources:
> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
> -I/home/kyle/software/mingw-w64/static/source/mingw-w64-svn/trunk/mingw-w64-crt
> -m32
> -I/home/kyle/software
> ELFf767c000-f7695000Deferredlibpthread.so.0
> ELFf7695000-f77cb000Deferredlibwine.so.1
> ELFf77cb000-f77dDeferredlibxxf86vm.so.1
> ELFf77d-f77d8000Deferredlibsm.so.6
> ELFf77dd000-f77fb000Deferred
On 12/10/2012 1:52 PM, Ruben Van Boxem wrote:
> Are you using the binary package on their website?
>
> I just compiled openjpeg with both my x64 and x86 compilers and I get no
> undefined references. Running "nm" on the produced libopenjp2.dll.a
> gives me:
> I __imp__opj_version@0
> 0
ng it with: i686-w64-mingw32-gcc ./test-openjpeg.c -lopenjp2
I get the error:
/tmp/cci01N0F.o:test-openjpeg.c:(.text+0xc): undefined reference to
`opj_version'
collect2: error: ld returned 1 exit status
When running: i686-w64-mingw32-nm
'/home/kyle/software/ffmpeg/pkgs/openjpeg/openjpe
see several undefined references,
which is what I believe the root of the problem is:
configure:3891:
/home/kyle/software/mingw-w64/packages/gcc/build/./gcc/xgcc
-B/home/kyle/software/mingw-w64/packages/gcc/build/./gcc/
-L/home/kyle/software/mingw-w64/mingw-w64-i686/i686-w64-mingw32/lib
-L/home/ky
rmance-issue-question-maybe-my-misunderstanding-td4652757.html
> which makes me wonder if it's stuck in a spinlock or something (his
> still progress fine, though, I'd imagine...)
Ping?
Any help/info/updates on this issue would be
if I compiled a debug version of
x264 to test with? The threading issue might just be in x264, so
having only x264 and not FFmepg might help.
Any ideas are welcome.
Best regards,
Kyle Schwarz
--
Live Security Vi
On 8/13/2012 8:31 PM, NightStrike wrote:
> On Wed, Aug 8, 2012 at 2:49 PM, Kyle wrote:
>> It's *very* slow. If you compare the speed to that of a older FFmpeg,
>> the debug build is practically unusable.
>
> I'm coming into this very late, and I probably can&
On 8/8/2012 8:49 PM, Kyle wrote:
> On 8/7/2012 3:06 AM, Kai Tietz wrote:
>> 2012/8/7 Kyle Schwarz :
>>> On 8/6/2012 4:58 PM, Kai Tietz wrote:
>>>> I have attached a modified version of winpthread (uncomress it and
>>>> rename it back to .dll). It would be
On 8/7/2012 3:06 AM, Kai Tietz wrote:
> 2012/8/7 Kyle Schwarz :
>> On 8/6/2012 4:58 PM, Kai Tietz wrote:
>>> I have attached a modified version of winpthread (uncomress it and
>>> rename it back to .dll). It would be great if you could test this
>>> variant
I copied the libwinpthread-1.dll you sent into the debug build and
replaced the old one. I had the same issue. Do I need to recompile
x264+FFmpeg with the new libwinpthread-1.dll?
Any idea as to what it might be?
Best regards,
Kyl
On 8/6/2012 3:56 PM, Kai Tietz wrote:
> 2012/8/6 Kyle :
>> On 8/6/2012 1:59 PM, Kai Tietz wrote:
>>> 2012/8/6 Kyle :
>>>> On 8/4/2012 3:38 AM, Kai Tietz wrote:
>>>>> 2012/8/4 Kyle Schwarz :
>>>>>> On 7/27/2012 5:37 PM,
On 8/6/2012 1:59 PM, Kai Tietz wrote:
> 2012/8/6 Kyle :
>> On 8/4/2012 3:38 AM, Kai Tietz wrote:
>>> 2012/8/4 Kyle Schwarz :
>>>> On 7/27/2012 5:37 PM, Kai Tietz wrote:
>>>>>> I have tried it, thanks for the patch!
>>>>>>
>&g
dead-lock?
Using ffmpeg.exe try to encode this file:
<http://rogerdpack.t28.net/incoming/sintel.mpg> with this command:
ffmpeg -y -i sintel.mpg -pass 1 -t 75 -c:v libx264 -an nul.mp4
This produces the dead-lock for me.
Thanks again for th
On 8/4/2012 3:38 AM, Kai Tietz wrote:
> 2012/8/4 Kyle Schwarz :
>> On 7/27/2012 5:37 PM, Kai Tietz wrote:
>>>> I have tried it, thanks for the patch!
>>>>
>>>> Unfortunately it appears that (ffmpeg + libx264 using it at least)
>>>> appears
take? If
winpthreads are no longer the best option I'm just curious as to if it's
worth it to try other options.
I'm available to test any sort of patch that is believed to help. I
strongly support MinGW-w64 and winpthreads.
Best regards,
Kyle Schwarz
--
On 7/27/2012 4:03 PM, Kai Tietz wrote:
> 2012/7/27 niXman :
>> 2012/7/27 Kyle Schwarz:
>>> Hi,
>>>
>>> I'm getting a syntax error when trying to compile the latest winpthread.
>>
>> Hmm... This is strange. I've built winpthreads a hour ago
Hi,
I'm getting a syntax error when trying to compile the latest winpthread.
My configure was:
../../source/mingw-w64-svn/experimental/winpthreads/configure
--build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
--disable-shared --enable-static
--prefix=/home/kyle/software/mingw-w64/
int OutputGranularityX;
int OutputGranularityY;
int StretchTapsX;
int StretchTapsY;
int ShrinkTapsX;
int ShrinkTapsY;
LONGLONG MinFrameInterval;
LONGLONG MaxFrameInterval;
LONG MinBitsPerSecond;
LONG MaxBitsPerSecond;
} VIDEO_STREAM_CONFIG_CAPS;
Best regards
Hi,
I just updated my MinGW-w64 tool chain and am having issues compiling
FFmpeg now.
I'm getting:
/home/kyle/software/ffmpeg/source/ffmpeg-git/libavdevice/dshow.h:35:1:
error: unknown type name 'VIDEO_STREAM_CONFIG_CAPS'
/home/kyle/software/ffmpeg/source/ffmpeg-git/libavdevi
scale -Llibswresample
-L/home/kyle/software/ffmpeg/packages/utvideo/utvideo-10.2.4-win32/lib
-Wl,--as-needed -Wl,--warn-common
-Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil
-o ffmpeg_g.exe ffmpeg.o cmdutils.o -lavdevice -lavfil
On 3/1/2012 4:37 AM, JonY wrote:
> On 3/1/2012 11:06, Kyle wrote:
>> I'm getting a imp error when trying to compile FFmpeg with MinGW-w64.
>> I'm trying to get libass enabled, which requires on fribidi.
>>
>> Both of these packages compiled fine, but when t
I'm getting a imp error when trying to compile FFmpeg with MinGW-w64.
I'm trying to get libass enabled, which requires on fribidi.
Both of these packages compiled fine, but when trying to compile FFmpeg
I get this error:
/home/kyle/software/ffmpeg/packages/libass/libass-0.10.0
On 2/9/2012 1:58 AM, Ozkan Sezer wrote:
> It is already among the headers, but not under a "ddk" subdirectory.
> Just include it like
Thank you, I realized this for myself just before you replied.
Apologies for not digging deeper first.
Best regards,
Hello,
I'm trying to compile libcdio with the latest MinGW-w64.
I get:
fatal error: ddk/ntddcdrm.h: No such file or directory
I see that ntddcdrm.h is part of MinGW, but not MinGW-w64.
Is there any plans to implement it, or am I out of luck for libcdio?
Best regards,
Kyle Sc
I'm getting:
trunk/mingw-w64-crt/stdio/mingw_pformat.c:476: undefined reference to
`wcslen'
When trying to compile GCC 4.6.2 on 64-bit Debian.
Here is some more information:
ln -s -f libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir
./shlib; else true; fi &
W has been
around for more than ten years now."
Best regards
Kyle Schwarz
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will
On 9/19/2011 9:25 AM, NightStrike wrote:
> On Sun, Sep 18, 2011 at 2:33 PM, Kyle wrote:
>> On 9/18/2011 7:17 AM, JonY wrote:
>>> Objective C seems to be affecting your issue.
>> Any chance of a quick fix?
> Add it to your configure line and recompile :)
Added --enable-
On 9/18/2011 6:43 PM, JonY wrote:
> On 9/19/2011 02:33, Kyle wrote:
>> I used to use that option but I believe it was removed. grep -ir
>> "enable-fully-dynamic-strings" * on the source dir turns up nothing.
> Check libstdc++v3/configure.
It can be found in lib
On 9/18/2011 7:17 AM, JonY wrote:
> Objective C seems to be affecting your issue.
Any chance of a quick fix?
> BTW, please use "--enable-fully-dynamic-strings" for gcc. I can't
> emphasize this point enough to anybody rolling their own mingw-w64 gcc
> binaries.
I used to use that option but I be
MinGW-w64's source.
Here is what I configured GCC with:
../source/gcc-4.6.1/configure --build=x86_64-unknown-linux-gnu
--target=i686-w64-mingw32 --disable-nls --disable-multilib
--prefix="/home/kyle/software/mingw-w64/builds/testing/mingw-w64-i686"
--with-sysroot="/home/kyle/s
On 9/17/2011 5:23 PM, NightStrike wrote:
> On Thu, Sep 15, 2011 at 11:33 AM, Kyle wrote:
>> I'm trying to compile the latest MinGW-w64 with GCC 4.6.1.
> Are you using our build script?
No I'm not
I'm trying to compile the latest MinGW-w64 with GCC 4.6.1.
Here is the error that I'm hitting:
make[2]: Entering directory
`/home/kyle/software/mingw-w64/builds/testing/packages/gcc/build/i686-w64-mingw32/libobjc'
/bin/bash ./libtool --mode=compile
/home/kyle/software/mingw-w64
On 9/10/2011 11:29 PM, Kyle Schwarz wrote:
> Thanks a lot for all the help, I'm glad I could get to the bottom of this.
>
> Any idea why it would only have this issue when SDL is found? I can
> build a shared build without needing to edit the source at all, how
> could f
On Sat, Sep 10, 2011 at 3:55 PM, Kai Tietz wrote:
> 2011/9/10 Kyle :
>> On 9/10/2011 6:52 AM, PcX wrote:
>>
>> δΊ 2011/9/10 18:51, PcX ει:
>>
>> i686-w64-mingw32-gcc -Wl,--as-needed -Wl,--warn-common
>>
-Wl,-rpath-link=libpostproc:libswscale:libavfilter:libav
-Llibavfilter
-Llibavformat -Llibavutil -Llibpostproc -Llibswscale
-L/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14-win32/lib
-lavfilter -lavformat -lavcodec
-lpostproc -lswscale -lavutil -lavicap32 -lpsapi -lole32 -lstrmiids
-luuid -lws2_32
-L/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14
__
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Unfortunately I get the same error with -lavdevice located at the end:
i686-w64-mingw32-gcc -Llibavcodec -Llibavdevice -Llibavfilter
-Llibavformat -Llibavutil -Llibpostpr
ide me the link command-line?
>
> Regards,
> Kai
gcc's frontend, here is the command:
i686-w64-mingw32-gcc -Llibavcodec -Llibavdevice -Llibavfilter
-Llibavformat -Llibavutil -Llibpostproc -Llibswscale
-L/home/kyle/software/ffmpeg/packages/sdl/sdl-1.2.14-win32/lib
-Wl,--as-need
On 9/10/2011 3:45 AM, Kai Tietz wrote:
> Sorry for that. I missed the option -x. So complete line is
> 'i686-w64-mingw32-objdump -x "./libavdevice/avdevice.dll" | grep
> "avdevice_register_all"'
That command returns:
[ 187] avdevice_register_all
[ 49](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x0
On 9/8/2011 5:10 PM, Kai Tietz wrote:
> i686-w64-mingw32-objdump "./libavdevice/avdevice.dll" | grep
> "avdevice_register_all"
That doesn't actually return anything other then objdump's usage info. I see
that there are many options and am unsure of which I should use.
> So my bet would go for
I'm having issues compiling FFmpeg for Windows with MinGW-w64. I'm
using the latest MinGW-w64 and the latest FFmpeg.
A bug report can be found here: https://ffmpeg.org/trac/ffmpeg/ticket/282
A mailing list post can be found here:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-September/00224
W-w64 SVN checkout, but they do exist in the
MinGW headers. Am I missing something? Is it safe to simply copy the DDK
folder from the MinGW bundle over to MinGW-w64 folder? Any help would be
appreciated.
Regards,
45 matches
Mail list logo
