Windows libraries DO NOT compile with x86_64-unknown-mingw32

[JimGunn]

I built a GCC-4.3.0 x86_64-unknown-mingw32 cross-compiler on an AMD x86_64 box.

When trying to build the Windows libraries:

cd w32api-3.11
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-mingw32 --prefix=/usr/local/x86_64-unknown-mingw32
make

compiled OK. But;

cd mingw-runtime-3.14
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-mingw32 --prefix=/usr/local/x86_64-unknown-mingw32
make

failed to compile, with error message:

x86_64-unknown-mingw32-gcc -c -g -O2 -I./include -I./../include -nostdinc -iwithprefixbefore include -I ./../w32api/include cpu_features.c -o cpu_features.o
/tmp/ccDamrzJ.s: Assembler messages:
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `pushf'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `pushf'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `pop'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `push'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `popf'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `pushf'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `pop'
/tmp/ccDamrzJ.s:22: Error: suffix or operands invalid for `popf'
make: *** [cpu_features.o] Error 1

Looking inside cpu_features.c we have:

Code: Select all

asm volatile ("pushfl; pushfl; popl %0;"
                "movl %0,%1; xorl %2,%0;"
                "pushl %0; popfl; pushfl; popl %0; popfl"
                : "=&r" (eax), "=&r" (ebx)
                : "i" (0x00200000));

Clearly the problem is that 64-bit assembler does not have pushfl,popfl, popl, pushl etc (uses pushfq,popfq, popq, pushq etc).

Someone must have run into this problem before today.

Any answers?

[oiaohm]

No one had that problem because no one is trying to build x64 bit version of reactos.

i386-unknown-mingw32 host target will help with matching binutils.

[JimGunn]

If I build the Win32 API & runtime libraries on my i686 box and transfer these libraries to my x86_64 box, would these libraries (built on the i686 box) be OK to build the cross-compilers for C,ADA,C++,Java,Fortran,ObjC,ObjC++ (on my x86_64 box)?

(Using the command:

./configure
--target=x86_64-unknown-mingw32
--with-headers=/usr/local/x86_64-unknown-mingw32/include
--enable-libada
--enable-libgcj
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++

to configure the C,ADA,C++,Java,Fortran,ObjC,ObjC++ cross-compilers)

That should work,... right?

(I am mostly interested in the C,C++ cross-compiler, but want as much bang for my buck as possible.)

[GreatLord]

we have experemnt version of gcc 4.3.0 for rosbe but it will not switch to it to many thing are broken in gcc 4.3.0 like buildin_setjmp
that we need for pseh, other wise we need remove everthing call crash protections and SEH

next issue is they do not clear right flags after string opreations, it is need for 32bits code longer, this is also big issue for us and LINUX.

it is many LINUX disto that have not swtich to gcc 4.3.0 for it contain to many regress and can not compile linux kernel out of box.

we love to swtich to gcc 4.3.x we will consider to switch to gcc 4.3.x when this issue have been solv.

I and one other dev have a exprement 64 bit rosbe that we testing time to time, for moment it can not compile whole reactos, for varus diffent it is
gcc 4.1.3 we manger get into 64bits.

[JimGunn]

I and one other dev have a exprement 64 bit rosbe that we testing time to time, for moment it can not compile whole reactos, for varus diffent it is
gcc 4.1.3 we manger get into 64bits.

Hi GreatLord, thanks for the reply.

Is there anywhere one can download the expremental 64-bit rosbe?

If not. Would you post the 64-bit version of cpu_features.c (mingw-runtime) that you use?

Thanks a lot.

[oiaohm]

http://mingw-w64.sourceforge.net/ Its a different runtime to the 32 bit completely.

Also 64 bit version of mingw is not stable for building applications for windows let alone building a full OS.

[JimGunn]

oiaohm: Thanks. Yes mingw-w64.sourceforge.net is a different runtime to the 32 bit.

However, I don't want 64-bit Windows.

I want 32-bit Windows (the target).

I want to compile the 32-bit Windows runtime on a 64-bit Linux box (the build).

64-bit Windows is of no interest to me at this time.

What GreatLord is working on is what I require.

[oiaohm]

The problem is you have build a 64 bit complier. x86_64 bit has done that. Special version of the runtime is need to deal with that mess. The one in the web site I pointed to. http://mingw-w64.sourceforge.net/. It allows 64 bit complier to build 32 or 64 bit.

Building i386-unknown-mingw32 cross complier will allow you to use mingw-runtime-3.14 that you are trying to use.

Its the x86_64 complier flag taking your feet off because you are giving it a 32 bit code that is trying to build in 64 bit mode. mingw-runtime-3.14 is not using the -m32 flag to change to 32 bit mode for 32 bit sections. It is not constructed to be built with a 64 bit complier..

[Mike]

What distribution are you on?

If you're on Debian or Ubuntu, you can simply install the mingw32 package. This will install all the i586-mingw32msvc-* tools (generates 32-bit Windows binaries; suitable for ReactOS too).

[EmuandCo]

After Stefan100 stopped flaming in #gcc yesterday and I tried to save our image, I had this talk:

EmuandCo> Sidenote. This was not an official ReactOS message. Flaming is NOT Supported by us. Well I have no op rights here, so I could not stop him. Sorry for the inconvenience.
<NightStrike> EmuandCo - when you guys compile, what do you use as your target? mingw?
<EmuandCo> yes
<NightStrike> then you'd be a good candidate to test out the 64-bit version
<NightStrike> join #mingw-w64 on this network
<EmuandCo> maybe yes, but not yet. Right now we try to fix some regressions between the versions. But we already planned to try mingw64 for our future 64 bit Version
<NightStrike> approximately when?
<EmuandCo> After Version 0.3.5 got released. ~3-5 weeks.
<NightStrike> k
<hp> FWIW, I have a pretty high bar, but a few more unsubstantiated rants would have had me look up how to arm the chanop thingy. As it were, the troll(y behavior) was successfully starved this time.
<EmuandCo> ok. night, guys.
NightStrike> when you do jump into 64 bit, let me know
<EmuandCo> ok

Whoever this NightStrike is, he seems to be interested in a tester for Mingw64...

[JimGunn]

oiaohm wrote: "Special version of the runtime is need to deal with that mess."

Yes and no. It appears that only one file, cpu_features.c, is causing the problem and that file was added only about a year ago. So the person adding it most probably knew it would not work for 64-bit.

I think the easiest ways to fix the problem of mingw-runtime-3.14 not compiling, are to either

(1) Rewrite cpu_features.c in 64-bit dialect, or

(2) Find the relevant Windows library and just copy it from a Windows box.

I will probably try (2) first.

In fact having mingw-runtime-3.14 not compile has made me realize that you probably don't need to compile the Windows libraries at all. You only need to copy them from a Windows box and change the .lib suffix to .a

So having this compilation problem may be a good thing.

Mike wrote: "What distribution are you on?"

I'm on Debian, SuSE and Mandriva.

EmuandCo wrote: "Whoever this NightStrike is, he seems to be interested in a tester for Mingw64..."

I would have a look at it, but I don't know enough about Windows libraries to help much.

[oiaohm]

How many times to I have to say this.
mingw-runtime-3.14 from mingw.sf.net project is a 32 bit version only.

http://mingw-w64.sourceforge.net/ Also provides a mingw-runtime different this one is build for 64 mingw compliers.

There are major changes need for the new 64 bit gcc complier. The complete configure and build system has had to be redone so the mingw 64 bit complier can have the parts build so it can build 32 and 64 bit binaries.

Reason its not compiling is simply that what you are trying to build is not meant to be built with the complier you are using without overriding the compliers default state even then its iffy. CC=your-64bit-complier-gcc -m32 ./configure So gcc is told to build 32 bit not 64 bit. That also does not always work with mingw-runtime-3.14 due to differences with the complier. Its safer to use a i386 i586 i686 cross complier if you want working mingw-runtime-3.14.

Rewriting cpu_features.c is 100 percent point less. You are also missing that everything else to build in 64 bit mode there are a whole stack of wrong structures in mingw-runtime-3.14 you are using that will not work in 64 mode. So C and ASM stops you dead. Yes the C builds but is not operational when it runs 64 bit windows. That is exactly how you are building it completely dead.

Something you should be aware of I have only build gcc from source for over 14 years and mingw from source for over 10. I don't say that what you are doing is wrong without experience.

NightStrike maintainer of the 64 bit project I keep on point you to.

[JimGunn]

oiaohm wrote: "You are also missing that everything else to build in 64 bit mode there are a whole stack of wrong structures in mingw-runtime-3.14"

Actually, 100% of w32api and about 90% of mingw-runtime compiles -- AS IS.

The (relatively minor) problems occur in the file cpu_features.c and the directories mingwex/math/ mingwex/profile/ and mingwex/stdio/.

These are all short/small files and the changes that have to be made are mostly (all?) the obvious/standard/easy changes that one makes when changing from 32-bit assembler to 64-bit assembler.

I believe the changes would be simple to any competent assembly programmer. I could make many of them myself, but would have no confidence in them.

oiaohm wrote: "Yes the C builds but is not operational when it runs 64 bit windows."

Did you mean "Yes the C builds but is not operational when it runs 32 bit windows." Remember, I do not want to compile 64 bit windows programs, just 32 bit windows programs (built on a 64 bit Linux box).

[oiaohm]

How blunt do I have to be. Ok I am going to try sledge hammer blunt. Don't take offence.

./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-mingw32 --prefix=/usr/local/x86_64-unknown-mingw32

This line both times you have used it on w32api and on mingw-runtime but sets you up to build in 100 percent pure 64 bit mode. There is nothing tell the 64 bit complier that you want 32 bit mode.

Issue w32api and mingw-runtime from www.mingw.org are not 64 bit aware will not add the needed -m32 flag automatically to force the complier to produce 32 bit code..

"Yes the C builds but is not operational when it runs 32 bit windows."

Almost right.

Yes the C builds but produced objects are completely useless for 32 bit or 64 bit windows application production. You have turned what should be 32 bit objects into 64 bit objects. mingw-runtime 1 asm file of 32 bit only is kinda kicking in as a safe guard. Smell the nuke. Its building a file in 64 bit mode when you want 32 bit programs. x86_64-unknown-mingw32-gcc -m32 -c cpu_features.c most likely builds without question now you basically have 64 bit objects everywhere. You need to start over.

Its is a little bit more fun setting up the complier to work right. Now also ros source code is not 64 bit complier aware either. Please build a pure 32 bit mingw complier it will make your live many times simpler.

[JimGunn]

Code: Select all

./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-mingw32 --prefix=/usr/local/x86_64-unknown-mingw32 

oiaohm wrote: "This line both times you have used it on w32api and on mingw-runtime but sets you up to build in 100 percent pure 64 bit mode. There is nothing tell the 64 bit complier that you want 32 bit mode."

Sorry, but for all your experience, you are wrong.

Your claim that "There is nothing tell the 64 bit complier that you want 32 bit (Windows) mode," is wrong.

The mingw32 (the 32) tells the 64-bit Linux complier that I want 32-bit Windows code.

--host=x86_64-unknown-mingw32

If I wanted the 64-bit Linux complier to produce 64-bit Windows code, I would use

--host=x86_64-unknown-mingw64

and the package from http://mingw-w64.sourceforge.net/

This is pretty standard. (Also note that I do not want a 32-bit cross compiler. I want a 64-bit cross compiler.)

That the mingw-runtime code does not (completely) compile, as is, is clear. It is also clear that it would not be that hard to change the 32-bit assembler to 64-bit assembler.

I am building on a 64-bit Linux box. It is an AMD64 box, so can run 32-bit executables without any problems. However, a 64-bit Linux box should be building a 64-bit compiler. That is the code in mingw-runtime should be fixed up. There would have to be seperate code for the 32-bit assembler and for the 64-bit assembler, just like this is usually done (using #ifdef IS-A-64-BIT-BUILD,... etc).