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
I'm unable to link OpenCL for i686, but x86_64 works.
I'm creating the library files (.a) from a def file using dlltool. The def
file and headers come from the ICD archive found here:
https://www.khronos.org/registry/cl/
I'm attempting to run the following bash compile script:
for arch in
I'm trying to cross compile GStreamer 1.0.6 with the latest version of
MinGW-w64.
I keep getting an instant crash when trying to run GStreamer under Wine.
Here is the output from Wine:
wine ./gst-inspect-1.0.exe
ALSA lib ../../../src/seq/seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq
I'm trying to compile an example program that uses openjpeg 2.0.0 and am
getting an undefined reference to `opj_version'.
I'm using the latest MinGW-w64 svn along with gcc 4.7.2.
The example program is:
extern int opj_version();
int main(void){ opj_version(); }
I'm compiling it with:
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
T
. I think the cause of the
first error is by the undefined references. Also, I remember that imp
normally deals with .dll files, but I'm not sure how to fix it.
If any further info is needed let me know.
Thanks in advance.
Best regards,
Kyle Schwarz
-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 great.
Best regards,
Kyle Schwarz
On 8/8/2012 8:49 PM, Kyle wrote:
On 8/7/2012 3:06 AM, Kai Tietz wrote:
2012/8/7 Kyle Schwarz kshawk...@gmail.com:
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
motivated to fix this so just walk me though anything
you would like tested and I'll see that it's done.
Have you used gprof before? It can be daunting with the output that it gives.
Any progress on this bug is a huge help to me.
Best regards,
Kyle Schwarz
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,
Kyle Schwarz
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
--
Live Security Virtual Conference
Exclusive live
,
Kyle Schwarz
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security
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:
13 matches
Mail list logo
