can't use gcc32 compiler option on system with gcc4 by default

[stranche@…]

On newly installed Fedora Core 4 x86_64.
Actually compile fails with GCC4, I guess this is in "work in progress" state.

However we can't use the gcc32 binary to compile, we get the following errors :

with #CC=gcc32 ./configure or #./configure --cc=gcc32

Detected host architecture: x86_64
Checking for gcc32 version ... 3.2.3, ok
Checking for host cc ... gcc32
Checking for GCC & CPU optimization abilities ... Your gcc32 does not even
support "athlon-xp" for '-march' and '-mcpu'.
error

and then if we try to compile anyway, the compile starts and fails at a certain
point with this :

make[1]: Leaving directory `/home/stranche/test/main'
gcc32 -c -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=error
-mcpu=error -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=gnu99 -I.
-I/usr/include/freetype2 -I/usr/include/cdda -I/usr/include/SDL -D_REENTRANT
-I/usr/X11R6/include -o mplayer.o mplayer.c
cc1: bad value (error) for -march= switch
cc1: bad value (error) for -mcpu= switch
In file included from libmpdemux/dvbin.h:11,

from mplayer.c:113:

libmpdemux/dvb_defaults.h:73:10: warning: #warning No DVB-T country defined in
dvb_defaults.h, defaulting to UK. Ignore this if using Satellite or Cable.
mplayer.c: In function `main':
mplayer.c:1836: warning: implicit declaration of function `cache_uninit'
mplayer.c:2787: warning: implicit declaration of function `mpcodecs_config_vo'
make: * [mplayer.o] Erreur 1

My guess is that options made for GCC4 compiler are passed to GCC32 and it
doesn't like it very much

[reimar]

I think you need to use either a 32 bit changeroot or use the --target option to
compile a 32 bit version on 64 bit.
This special problem should be fixed though (see also bug #324)

[stranche@…]

I'm not trying to compile a 32 bit version here, the gcc32 command stands for
gcc version 3.2

in FC4 you have this :

/usr/bin/gcc -v
Utilisation des specs internes.
Target: x86_64-redhat-linux
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=x86_64-redhat-linux
Modèle de thread: posix
version gcc 4.0.0 20050519 (Red Hat 4.0.0-8)

and this :

/usr/bin/gcc32 -v
Lecture des spécification à partir de
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-cxa_atexit
--enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Modèle de thread: posix
version gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)

[stranche@…]

Okay, just seen that you modified the configure file to version 1.1022, so I
tryed to download CVS again and compile.

This time the compile with GCC32 (v3.2.3 as said above) works.

The compile with GCC4, however, is still unhappy, but is unrelated to the topic
of this bug report, so I guess it can be considered as resolved.
Anyway here is the last lines before crash, tell me if you need more infos.

used ./configure with no options given.

cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o wnv1.o wnv1.c
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o ws-snd1.o ws-snd1.c
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o xan.o xan.c
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o xl.o xl.c
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o pthread.o pthread.c
cc -I../libvo -I../../libvo -I/usr/X11R6/include -O4 -march=k8 -mtune=k8 -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -std=gnu99 -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o
libpostproc/postprocess.o libpostproc/postprocess.c
In file included from libpostproc/postprocess.c:655:
libpostproc/postprocess_template.c: In function 'postProcess_MMX2':
libpostproc/postprocess_template.c:3512: warning: pointer targets in passing
argument 6 of 'blockCopy_MMX2' differ in signedness
libpostproc/postprocess_template.c:3658: warning: pointer targets in passing
argument 6 of 'blockCopy_MMX2' differ in signedness
libpostproc/postprocess_template.c:3759: warning: pointer targets in passing
argument 4 of 'tempNoiseReducer_MMX2' differ in signedness
libpostproc/postprocess_template.c:3783: warning: pointer targets in passing
argument 4 of 'tempNoiseReducer_MMX2' differ in signedness
libpostproc/postprocess_template.c:3483: error: memory input 4 is not directly
addressable
libpostproc/postprocess_template.c:3483: error: memory input 5 is not directly
addressable
libpostproc/postprocess_template.c:3629: error: memory input 4 is not directly
addressable
libpostproc/postprocess_template.c:3629: error: memory input 5 is not directly
addressable
make[1]: * [libpostproc/postprocess.o] Error 1
make[1]: Leaving directory `/home/stranche/test/main/libavcodec'
make: * [libavcodec/libavcodec.a] Erreur 2

[reimar]

(In reply to comment #2)

I'm not trying to compile a 32 bit version here, the gcc32 command stands for
gcc version 3.2

oh, okay. I was used to the old version being called gcc-3.2. But I think 3.4
would be preferable...
Concerning the compile problem with gcc 4 - I was able to compile a 32bit
version with gcc 4 just fine.
I don't have gcc-4 on my 64 bit system yet.

[stranche@…]

Okay, got the CVS today and the compile gone till the end fine with GCC4 on my
SMP x86_64 system.

I guess the changes in xmms.h version 1.3 done their job, so this bug report can
be closed if everyone is OK with it.

On a second hand (completely unrelated) has a solution been found to get the
Win32 codec DLLs supported on x86_64 CPUs ?
We tryed in the past to compile a 32bit version with --arch and such options but
this had always failed for me, and the whole MPlayer with such option would
becomes then a 32bit binary.
I proposed the possibility to have the main mplayer parts to be compiled as
64bit and the Win32 codec DLLs support code specificaly compiled in 32bit
format, but I don't know if it's even feasable to mix .o files compiled as such
(maybe this idea is completely dumb).

[reimar]

Yes, I did quite a bit of testing, so I also think it should work now. So
setting this bug as fixed.

(In reply to comment #5)

On a second hand (completely unrelated) has a solution been found to get the
Win32 codec DLLs supported on x86_64 CPUs ?

No, and I know of nobody really looking into it, maybe also because that code is
mostly ported from wine and nobody knows it really well. Probably wmv3 will be
reverse engineered before that *g*.

We tryed in the past to compile a 32bit version with --arch and such options but
this had always failed for me, and the whole MPlayer with such option would
becomes then a 32bit binary.

Yes, I always use the MPlayer from my 32bit chroot to play such things (if I
plan to watch them more than once I just convert them with mencoder).

I proposed the possibility to have the main mplayer parts to be compiled as
64bit and the Win32 codec DLLs support code specificaly compiled in 32bit
format, but I don't know if it's even feasable to mix .o files compiled as such
(maybe this idea is completely dumb).

Not dumb, but not (easily) possible. I also think mixing 32 and 64 bit code
would need a new kernel syscall, but I'm not sure.