C++ compilers on Linux supporting 64bit architecture?

Sam Varshavchik mrsam at courier-mta.com
Sun Sep 2 14:08:06 UTC 2007


Bo Berglund writes:

> On Sat, 01 Sep 2007 09:36:09 -0400, Sam Varshavchik
> <mrsam at courier-mta.com> wrote:
> 
>>Chris Jones writes:
>>
>>> 
>>>> 1) Is it possible to cross-compile on Linux 32 bit to produce an
>>>> executable for the 64bit architecture Linux as well as 32 bit?
>>> 
>>> No, I don't think a 32bit only processor can produce 64bit binaries. The other
>>
>>It's not the question of processor, but rather compiler support.
>>
>>This is certainly doable, you just have to build your own custom version of 
>>binutils, and gcc, that cross compile to elf_x86-64.
>>
>>But all of this is irrelevant. The stupid reasons why one has to do this -- 
>>target Win64 binaries on a Win32 box -- simply do not exist on Linux. If you 
>>intend to run 64 bit binaries, you can just build them directly on the 64 
>>bit hardware. It's not like you'll have to pay a small fortune for a native 
>>64 bit Linux compiler, like you'd have to for a 64 bit version of Visual 
>>Studio, so none of that nonsense is really needed.
> 
> Well, if you have a bunch of Windows developers all having a
> workstation running 32 bit Windows on a 32 bit CPU, then the option is
> not there simply to furnish them all with a new laptop with 64bit CPU
> and a Linux 64 bit version to compile the 64bit program.

Who said anything about furnishing them with new laptops? All they have to 
do is login into the 64 bit Linux box, and build their code directly on 
there.

I suspect that there is a misunderstanding here is that you need to have the 
64 bit Linux hardware physically sitting on your desk, in order to use it, 
and that only one person can use it at the same time, Like Windows. Nothing 
can be farther from the truth. They can continue to have their existing 
Windows desktops, and use them to do their other work, to their hearts' 
content. To compile Linux code, they would fire up Exceed (commercial), or 
Mingw (Free software) to open a terminal session to the Linux host, straight 
from their Windows desktop, and just do their work there. They'd be doing 
whatever they need to do on the Linux server, through the terminal session 
window, while running their other Windows software at the same time.

> So  my question comes from a suggestion to run a 32 bit Linux inside a
> VirtualPC virtual machine in the Windows laptops for development.
> Then we need only a single 64 bit machine running Linux to test the
> performance of the compiled binaries.

This is too complicated, for no good reason. Unless your single 64 bit 
machine is going to be performance-testing your software 24 hours a day, 
just do all of your work, compile and test, directly on the box. You do 
understand that you can have all of your people log on to their own 
individual accounts, and work on the Linux server at the same time, do you?

Or, if you do need the 64 bit Linux server running performance tests all day 
one, buy the fastest one you can afford, then buy another, less-expensive 
Linux server that everyone will build their software on, which then they 
test on the other host.

> This requires the use of a cross-compiler able to compiule 64 bit
> binaries on a 32 bit system.

I just don't understand what's do be gained from overengineering something 
that's so trivial to do. I'm sure that with some significant investment in 
time you could hack something together works the way you think you want it 
to work. But, it's going to be rather fragile, break anytime someone sneezes 
in the wrong direction, and wouldn't give you anything that you couldn't get 
using the direct, standard approach: logging into the Linux machine, and 
building and testing code directly on it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20070902/1dfef5a6/attachment-0002.bin 


More information about the users mailing list