ffdshow / Bugs / #429 libmpeg2_ff.dll compiling fails with gcc

Anonymous - 2005-11-21

Logged In: YES
user_id=547197

Should be fixed. However, I couldn't reproduce the problem
with my Mingw instalation. I guess it was caused by using
__int64 type which is Microsoft-specific in csimd.h where it
wasn't used previously.

BTW how did you manage to compile working ffdshow using gcc
3.4.4? After reading your message I tried to compile it
myself but I failed. First I had to used "SSE2=no",
otherwise gcc crashed when compiling ffdshow/src/convert.
After removing SSE2 usage, to my big surprise, the whole
ffdshow compiled but it took much longer compared to gcc 4.
0.2 compilation. Unfortunatelly, any attempt to use ffdshow.
ax either for decoding or displaying configuration dialog
caused immediate crash.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-21

Logged In: YES
user_id=547197

Should be fixed. However, I couldn't reproduce the problem
with my Mingw instalation. I guess it was caused by using
__int64 type which is Microsoft-specific in csimd.h where it
wasn't used previously.

BTW how did you manage to compile working ffdshow using gcc
3.4.4? After reading your message I tried to compile it
myself but I failed. First I had to used "SSE2=no",
otherwise gcc crashed when compiling ffdshow/src/convert.
After removing SSE2 usage, to my big surprise, the whole
ffdshow compiled but it took much longer compared to gcc 4.
0.2 compilation. Unfortunatelly, any attempt to use ffdshow.
ax either for decoding or displaying configuration dialog
caused immediate crash.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-21

Logged In: YES
user_id=1293290

Hmm sorry my bad. Many people told me gcc 3.4.4 would be
faster on ffdshow. I have not compiled it myself.

Since an gcc 3.4.4 built x264.exe encodes quite a lot
faster than 4.0.2, other people and me assumed it will
benefit ffdshow the same way.

Guess we will have to test it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-22

Logged In: YES
user_id=1293290

I guess something went wrong with submitting a new comment.

Anyway gcc 3.4.4 compiling is still not possible, here are
the last few lines:

./../../simd.h:301: error: `__int64' does not name a type
./../../simd.h:302: error: `__int64' does not name a type
./../../simd.h:303: error: `const1' undeclared (first use
this function)
./../../simd.h:304: error: `const2' undeclared (first use
this function)
./../../simd.h: In static member function `static int
__vector__ Tmmx::_mm_shuff
le_pi16_x50(const int __vector__&)':
./../../simd.h:309: error: `__int64' does not name a type
./../../simd.h:310: error: `__int64' does not name a type
./../../simd.h:311: error: `const1' undeclared (first use
this function)
./../../simd.h:312: error: `const2' undeclared (first use
this function)
./../../simd.h: In static member function `static void
Tmmx::psadbw(int __vector __&,
const int __vector__&)':
./../../simd.h:329: error: `__int64' does not name a type
./../../simd.h:330: error: `mmx_one' undeclared (first use
this function)
./../../simd.h:334: error: `__int64' does not name a type
./../../simd.h:335: error: `mmx_ffff' undeclared (first
use this function)
./../../simd.h: At global scope:
./../../simd.h:401: error: `__int64' has not been declared
./../../simd.h:402: error: ISO C++ forbids declaration of
`parameter' with no ty pe
./../../simd.h:405: error: `__int64' has not been declared
./../../simd.h:406: error: ISO C++ forbids declaration of
`parameter' with no ty pe
./../../simd.h:421: error: expected `,' or `...'
before '&' token
./../../simd.h:422: error: ISO C++ forbids declaration of
`__int64' with no type
./../../simd.h: In static member function `static void
Tmmxext::v_pminub(int __v
ector__&, int)':
./../../simd.h:423: error: `mmr2' undeclared (first use
this function)
./../../simd.h:423: error: `mmrw' undeclared (first use
this function)
make[1]: *** [libmpeg2/motion_comp.o] Error 1
make[1]: Leaving directory
`/home/user/ffdshow_gcc/src/codecs/libmpeg2'
make: *** [../bin/libmpeg2_ff.dll] Error 2

I guess its file simd.h this time :)

[Off Topic]
Since you will be reading this anyway, its useless
to "submit this":
The page http://cia.navi.cx/stats/project/ffdshow Errors
in Internet Explorer, under Link you only see "#" not the
actual number.

The same for FireFox (no number) but its not saying
something is wrong.
[/Off Topic]

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-23

Logged In: YES
user_id=547197

Try to replace '__int64' with 'long long'. This should help.

However, I think your mingw/gcc 3.4.4 instalation might be
somehow damaged. Certainly __int64 isn't GCC native type but
it's defined in mingw/include/_mingw.h. This file isn't
included explicitly to simd.h or csimd.h but gets included
in this way: simd_common.h <- xmmintrin.h <- mm_alloc.h <-
stdlib.h <- _mingw.h.

About cia.navi.cx: I checked few other projects and they
also display only '#' for links. Important is that these
links work. And I checked it with IE both on Windows 2000
and Windows XP and IE didn't reported any errors - even if
they would I guess I wouldn't have any way to fix it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-23

Logged In: YES
user_id=1293290

Uhm _mingw.h gets updated with the latest mingwruntime
3.9, are you sure you are running the latest?

Because i compile gcc 3.4.4 on mingw (for example x264
compiles just fine with gcc 3.4.4) I think this is not a
broken mingw/msys/gcc on my side.

In _mingw.h:
__int64 define to be long long. Using a
typedef doesn't
work for "unsigned __int64"

And at the bottom:
# ifndef __int64
# define __int64 long long
# endif

"Try to replace '__int64' with 'long long'."
Where should i do that? Tried in _mingw.h, but thats not
helping.

---

And about cia.navi.cx, it worked lets say 2-3 days ago, so
something has changed (the showing "today", "yesterday"
etc script). This is quite useless anyway, because its UTC
and CVS of sourceforge updates quite a lot slower.
This script is faulty, only wanted to let you know that,
what you do with it all completely up to you :)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-23

Logged In: YES
user_id=547197

I'm using latest mingw runtime (3.9) and ff_libmpeg2 can be
compiled using GCC 3.4.4. Please check all files I described
if they include each file which follows in the list.

x264 doesn't using simd.h and related files. I'd be more
interested to know if you had successfully compiled
ff_theora or ff_liba52 with GCC 3.4.4.

Sorry, I forgot to specify which file you should modify:
it's simd.h. There are couple of uses of __int64 type. I
could replace it with "long long" myself as I did it for
csimd.h, but somehow I like __int64 more and I think it
should work even with GCC 3.4.4.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-23

Logged In: YES
user_id=1293290

I changed simd.h __int64 to long long, but i get a new
error:

gcc -c -I. -Iinclude -I../.. -mno-cygwin -mdll -mthreads -
pipe -mmmx -msse -mfpmath=sse -DNDEBUG -UDEBUG -DWIN32 -
D_WIN32 -x c++ -O3 -march=i586 -mtune=i686 -fomit-frame-
pointer -finline-functions -finline -o
libmpeg2/idct_sse2.o libmpeg2/idct_sse2.c
In file included from libmpeg2/idct_sse2.c:2:
./../../simd.h:179: error: `size_t' does not name a type
./../../simd.h:369: error: `size_t' does not name a type
make[1]: *** [libmpeg2/idct_sse2.o] Error 1
make[1]: Leaving directory
`/home/user/ffdshow_gcc/src/codecs/libmpeg2'
make: *** [../bin/libmpeg2_ff.dll] Error 2

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-23

Logged In: YES
user_id=547197

And again: check files I listed in comment from 10:44 AM,
especially xmmintrin.h (should be in
mingw\LIB\GCC\MINGW32\3.4.4\INCLUDE). It should include
mm_malloc.h which includes stdlib.h which includes stddef.h
which defines size_t.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-23

Logged In: YES
user_id=1293290

Very interesting:
G:\MinGW\lib\gcc\mingw32\3.4.4\include\mm_malloc.h
(present):
#include <stdlib.h> (not present)
#include <errno.h> (not present)

(original gcc 3.4.2 that came with mingw when i first
installed it):
G:\MinGW\lib\gcc\mingw32\3.4.2\include\mm_malloc.h (not
present) for i guess on gcc 3.4.2 it would not work at all
also.

(gcc 4.0.2):
G:\msys\1.0\local\lib\gcc\i686-pc-mingw32\4.0.2
\include\mm_malloc.h (present)
Not in mingw but msys dir.
G:\msys\1.0\local\lib\gcc\i686-pc-mingw32\3.4.4
\include\mm_malloc.h (not present)
Very weird, how files are not in the same dirs.

G:\MinGW\include\stdlib.h (present here)
This means, compiling gcc manually is not enough, and you
have to use the mingw installer stuff? (Which was not
easy, so i did it manually)

mm_malloc.h Is not even created when i compile gcc 3.4.4
(gcc 4.0.2 does have it) (nor is it in the source tar.gz)

I am now clueless what to do, i need the correct files.
All i can tell you is, mingw/msys gcc 3.4.4 looks in:
G:\msys\1.0\local\lib\gcc\i686-pc-mingw32\3.4.4\include

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-24

Logged In: YES
user_id=1293290

Hmm its working now.

I don't know exactly what i have done, but using gcc-3.4.4-
build.sh (from gcc-3.4.4-build.sh) might have created
those files. The process did not work when i tried it
months ago, but i guess it created the needed files.

What i now did is:
Copy G:\MinGW\lib\gcc\mingw32\3.4.4 to G:\msys\1.0
\local\lib\gcc\i686-pc-mingw32\3.4.4

Thanks for all the support, and i will backup my
mingw/msys dirs now, so i can always fall back on this
setup.

Here is the build:
http://files.x264.nl/ffdshow/ffdshow-20051124-gcc3.4.4-sse-
x264.nl.exe

P.S.
I Tested compiling with ffdshow (fresh checkout 2005-11-
19) csimd.h with __int64, and that also works now. So i
guess you can make this update undone, the way you want
it :)

Thanks!

Hmm before i press submit, ffdshow.ax crashes with gcc
3.4.4

AppName: mplayerc.exe AppVer: 6.4.8.6 ModName:
ffdshow.ax
ModVer: 1.0.2.1998 Offset: 0020e3d5

and:

AppName: wmplayer.exe AppVer: 10.0.0.3646
ModName: ffdshow.ax
ModVer: 1.0.2.1998 Offset: 0020e3d5

On x264.375.mp4 and some random divx 3.11 movie it crashes
(make SSE2=no was used).
What more info would/could you need?

Now the topic of this bug report is not correct anymore,
we can start a new bug report if needed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-24

Logged In: YES
user_id=547197

I'm happy you managed to compile ffdshow using GCC 3.4.4,
but I don't think I'll check reports about bugs in this
build. GCC 3.4.4 simply isn't supposed to be used for
building ffdshow.

Just today I tested a mpeg 1 file created by tmpgenc
(finally ffdshow is able to deliver video to tmpgenc, audio
will hopefully follow), but the image was distorted. The
problem was in ff_libmpeg2 compiled by GCC 3.4.4. When
compiled using GCC 4.0.2 or MSVC, the results were fine.
Maybe it'd be possible to make ffdshow work when compiled
using GCC 3.4.4 (compiler switches,...) but it'd take too
much time and I think there are other areas of ffdshow where
it should be spent.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-24

Logged In: YES
user_id=1293290

All very clear. Thanks you!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-24

Logged In: YES
user_id=547197

Should I close this bugreport?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bob0r - 2005-11-24

Logged In: YES
user_id=1293290

Yes, the __int64 issue was "fixed" (you can change that
back in csimd.h)

And GCC 3.4.4 won't be supported, so lets move on with gcc
4.0.2

Thanks you = Thank you :)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2005-11-24

status: open --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

libmpeg2_ff.dll compiling fails with gcc

Group

Searches

Help

#429 libmpeg2_ff.dll compiling fails with gcc

Discussion