Re: Does gcc support compiling for windows x86-64?

Re: Does gcc support compiling for windows x86-64?

[Ali, Muhammad]

> >> Why not read the archives of more relevant lists before posting here?  I
> >> don't know what you are driving at, nor do I think anyone here cares,
I guess my initial posting was somewhat misleading. I only mentioned
MinGW because MinGW (and Cygwin) are the only ports of gcc I know of
that work on windows. But I realize that these have an older version
of gcc built into them. The reason I posted to this mailing list was
to find out if the current version supported x86-64 platforms, and if
so, then I would be interested in building the latest version.
And I did spend two days searching (and trying out possible) solutions
before posting to this list.

> >> but the preliminary gcc/gfortran for mingw 64-bit mode which FX Coudert
> >> supplied was a version of gcc-4.3.
Are you talking about the gcc supplied with the mingw-w64 project that
Tim mentioned?

> > May you can take a look at the developer project 'mingw-w64' on
> > sourceforge for more details.
Thanks for pointing me to the mingw-w64 sourceforge project. As Tim
said, there isn't much documentation available for it, so I guess I'll
just download and try it out. Although, at this point, I'm just
thinking that downloading a trial version of Visual C++ and using it
to compile my dll would be much easier :(. But even with that option,
I'm not sure if its legal to distribute that dll with our package.

> Ali didn't say if he meant g++ rather than gcc, but I guess all of this
> has missed his intended topic.
gcc. I'm working with a java application which is using JNI to call
native libraries. We want to port our software to 64-bit platforms,
and hence here I am, trying to figure out how to compile 64-bit dlls
on my amd64.

Thanks for all the comments,
Ali.

Re: Re: Does gcc support compiling for windows x86-64?

[Howard Chu]

Ali, Muhammad wrote:
>>>> but the preliminary gcc/gfortran for mingw 64-bit mode which FX Coudert
>>>> supplied was a version of gcc-4.3.

>>> May you can take a look at the developer project 'mingw-w64' on
>>> sourceforge for more details.

> Thanks for pointing me to the mingw-w64 sourceforge project. As Tim
> said, there isn't much documentation available for it, so I guess I'll
> just download and try it out. Although, at this point, I'm just
> thinking that downloading a trial version of Visual C++ and using it
> to compile my dll would be much easier :(. But even with that option,
> I'm not sure if its legal to distribute that dll with our package.

I started to download the trial Visual C++ but it says it's 32-bit only.

>> Ali didn't say if he meant g++ rather than gcc, but I guess all of this
>> has missed his intended topic.
> gcc. I'm working with a java application which is using JNI to call
> native libraries. We want to port our software to 64-bit platforms,
> and hence here I am, trying to figure out how to compile 64-bit dlls
> on my amd64.
> 
> Thanks for all the comments,
> Ali.

I've downloaded a couple of the binary tarballs from the mingw-w64 project 
page. Had a lot of trouble getting usable code out of them. I finally figured 
out that I had to compile without any optimization to get anything to run. 
It's not clear whether this is a problem specific to the win64 support, or if 
it's gcc 4.3.0's immaturity. I was also frustrated by the lack of a working 
debugger, giving up half way through building gdb. I'm thinking it may be 
quicker to write a tool that converts the gcc stabs stuff to rudimentary PDB 
format to provide function and variable names for WinDbg.

The cross-compiler runs pretty well hosted on Linux but for some reason some 
of the configure scripts I ran were accessing my Linux header files and so 
detecting features they shouldn't have. My only other choice was to run under 
Cygwin on the Windows side, but shell scripts run about 100 times slower 
there, making configure/libtool/etc unbearable. (Normally I would use MSYS but 
the last one I tried just crashes immediately on Win64.) And it looks like 
current bash on cygwin doesn't handle case/esac constructs correctly, so e.g. 
the configure script for BerkeleyDB 4.6.21 fails there.

Gotta hand it to Microsoft, they've sure made it hard to support their platform...
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

Re: Re: Does gcc support compiling for windows x86-64?

[NightStrike]

On Nov 23, 2007 6:31 PM, Howard Chu <hyc@highlandsun.com> wrote:
> I've downloaded a couple of the binary tarballs from the mingw-w64 project
> page. Had a lot of trouble getting usable code out of them. I finally figured
> out that I had to compile without any optimization to get anything to run.
> It's not clear whether this is a problem specific to the win64 support, or if
> it's gcc 4.3.0's immaturity. I was also frustrated by the lack of a working
> debugger, giving up half way through building gdb. I'm thinking it may be
> quicker to write a tool that converts the gcc stabs stuff to rudimentary PDB
> format to provide function and variable names for WinDbg.

GDB support isn't done yet.  Optimization issues will be more
difficult to debug, also.  Please remember that the project has only
two or three people on it, only one of which really understands this
stuff.  If you'd like to help out, we would be very grateful.

Also, please try a more current version of the project.  As soon as I
get through with some very pressing family emergencies, I will be
uploading new versions of everything.  Anything that you can test and
find problems with will be very helpful.

> The cross-compiler runs pretty well hosted on Linux but for some reason some
> of the configure scripts I ran were accessing my Linux header files and so
> detecting features they shouldn't have. My only other choice was to run under
> Cygwin on the Windows side, but shell scripts run about 100 times slower
> there, making configure/libtool/etc unbearable. (Normally I would use MSYS but
> the last one I tried just crashes immediately on Win64.) And it looks like
> current bash on cygwin doesn't handle case/esac constructs correctly, so e.g.
> the configure script for BerkeleyDB 4.6.21 fails there.

I made a binary release that runs on i686-pc-mingw32.  That may allow
you to step away from cygwin.  Regarding the linux release, however,
can you describe in more detail what you are seeing in terms of
accessing the linux header files?  It's entirely possible that I am
building the sysroot incorrectly (hey, we all make mistakes :) ).  If
you could provide more feedback, I'd love to try to fix it.  You can
email me directly, post to the mingw-w64 mailing list, file a bug
report on the mingw-w64 project, etc etc.

RE: Re: Does gcc support compiling for windows x86-64?

[Dave Korn]

On 23 November 2007 23:32, Howard Chu wrote:

> And it looks
> like current bash on cygwin doesn't handle case/esac constructs correctly,
> so e.g. 
> the configure script for BerkeleyDB 4.6.21 fails there.

  Could you possibly send a testcase to the cygwin mailing list?  We haven't
had any reports of this yet, but not a lot of us use win64.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Does gcc support compiling for windows x86-64?

[Howard Chu]

Dave Korn wrote:
> On 23 November 2007 23:32, Howard Chu wrote:
> 
>> And it looks
>> like current bash on cygwin doesn't handle case/esac constructs correctly,
>> so e.g.
>> the configure script for BerkeleyDB 4.6.21 fails there.
> 
>   Could you possibly send a testcase to the cygwin mailing list?  We haven't
> had any reports of this yet, but not a lot of us use win64.

I wasn't able to reproduce it in isolation; it must be something getting 
corrupted during the course of running BDB's configure script. I'll send a 
note to the cygwin folks.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/