I am new to Linux, but I am invsetigating a performance issue in a big tomography program developed for Windows. We have made a command line version of this and compiled for 64 bit architecture on Win X64 to evaluate performance improvements. The compilation was done in WinXP (32 bit) using MS VisualStudio 2005 but targeting X64.
The questions now are:
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?
2) Can we expect an improvement in performance of such a command line (no GUI) program in Linux compared to Windows? The program performs massive math calculations and has been optimized to use the available resources well.
3) The program is written in C++, would there be big porting issues moving it from Windows to Linux, code-wise?
I understand that this is not a Fedora question per se, but since Fedora is such a popular distribution I thought that the comparison and development questions may fit here anyway. Sorry if you all disagree...
Grateful for any comment though.
Bo Berglund
Bo Berglund wrote:
I am new to Linux, but I am invsetigating a performance issue in a big tomography program developed for Windows. We have made a command line version of this and compiled for 64 bit architecture on Win X64 to evaluate performance improvements. The compilation was done in WinXP (32 bit) using MS VisualStudio 2005 but targeting X64.
The questions now are:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
Yes. You'd use g++ (gcc.gnu.org)
- The program is written in C++, would there be big porting issues
moving it from Windows to Linux, code-wise?
It's not a question of language. It's a question of libraries. What does the program depend on?
Matt Flaschen
- 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 way around is possible, if you run a 64bit version of Linux, you can produce 32bit binaries. With gcc you simply use the command line flag -m32.
- Can we expect an improvement in performance of such a command line
(no GUI) program in Linux compared to Windows? The program performs massive math calculations and has been optimized to use the available resources well.
I work on a similar sort of math intensive project, that does support windows and linux, and only linux we use both 32 and 64 bit builds. The 64 bit builds run ~30% faster than the 32bit builds on the same machine. Note though, a lot of this improvement doesn't come from the 32-64 bit change, but likely other things the compiler does in 64 bit mode. I.e., the compiler knows that *all* 64 bit machines have SSE2 instructions, and so by default enables this (-mfpmath=sse). Not all 32 bit nodes have SSE instructions so the compiler does not enable this there. However, if you know your 32 bit nodes do have SSE you can enable this by hand, and get 32 speeds much closer to the 64 bit ones.
- The program is written in C++, would there be big porting issues
moving it from Windows to Linux, code-wise?
Depends. My experience is yes, there are lots of little gotchas that can come. Depends exactly what external packages (STL, boost, etc.) you use and how deeply etc.
Chris
I understand that this is not a Fedora question per se, but since Fedora is such a popular distribution I thought that the comparison and development questions may fit here anyway. Sorry if you all disagree...
Grateful for any comment though.
Bo Berglund
Chris Jones writes:
- 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.
On Sat, 01 Sep 2007 09:36:09 -0400, Sam Varshavchik mrsam@courier-mta.com wrote:
Chris Jones writes:
- 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. Their main job will still remain to work on windows software (which one can actually sell).
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 requires the use of a cross-compiler able to compiule 64 bit binaries on a 32 bit system. Notice also that VPC2007 does not support running anything but a 32 bit virtual machine emulation.
Bo Berglund
Bo Berglund writes:
On Sat, 01 Sep 2007 09:36:09 -0400, Sam Varshavchik mrsam@courier-mta.com wrote:
Chris Jones writes:
- 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.
O
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. Their main job will still remain to work on windows software (which one can actually sell).
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 requires the use of a cross-compiler able to compiule 64 bit binaries on a 32 bit system.
I am still not getting why you want to be able to generate 64 bit binaries from a 32 bit OS ?
I can understand the logic behind giving your devs a 32 bit linux virtual machine on their windows notebooks, to work with. Here though, they are going to have to work in 32 bit mode, as these are the only binaries then can run.
Note I'm not sure how easy it is, or even if it is possible, to generate 64 bit binaries from a pure 32 bit OS. For sure if it is possible you are going to have to do a lot of custom setting up.
So, once your devs have some software, tested on 32 bit windows and 32 bit linux, you want test it on your single 64 bit linux machine. At this point just install the source code for you project on this machine, build it from source in 64 bit mode and test.
I'm just not getting where you need to generate 64 bit binaries on your 32 bit nodes ? ( But obviously I don't know the full details of your software dev process... )
Notice also that VPC2007 does not support running anything but a 32 bit virtual machine emulation.
VPC isn't the only virtualisation software around - Are you tied to VPC, or could you consider say VMWare instead, which does support 64 bit guests ?
Chris
Bo Berglund
On Sun, 2 Sep 2007 15:10:28 +0100, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
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 requires the use of a cross-compiler able to compiule 64 bit binaries on a 32 bit system.
I am still not getting why you want to be able to generate 64 bit binaries from a 32 bit OS ?
Because the idea was that anyone of the developers should be able to do it and they do not have 64 bit PC:s... So if the compiler could be set to generate 64 bit code as well as 32bit it would be possible. But I know too little about the Linux system to really know. That's why I am asking here.
I can understand the logic behind giving your devs a 32 bit linux virtual machine on their windows notebooks, to work with. Here though, they are going to have to work in 32 bit mode, as these are the only binaries then can run.
Note I'm not sure how easy it is, or even if it is possible, to generate 64 bit binaries from a pure 32 bit OS. For sure if it is possible you are going to have to do a lot of custom setting up.
So, once your devs have some software, tested on 32 bit windows and 32 bit linux, you want test it on your single 64 bit linux machine. At this point just install the source code for you project on this machine, build it from source in 64 bit mode and test.
I'm just not getting where you need to generate 64 bit binaries on your 32 bit nodes ? ( But obviously I don't know the full details of your software dev process... )
As described above.... But from another poster I have nbow realized that as long as the developers are on the local network and we have one 64bit Linux machine running each of them can use an X terminal and log on to the Linux machine and do their work from their own PC:s. So that is probably the final solution.
Notice also that VPC2007 does not support running anything but a 32 bit virtual machine emulation.
VPC isn't the only virtualisation software around - Are you tied to VPC, or could you consider say VMWare instead, which does support 64 bit guests ?
But that is $200 per developer and it does not work anyweay since the developer CPU is 32 bit, VMWare does not emulate the CPU either, what you have on your PC is what you can have in your virtual machine.
Bo Berglund
Hi,
But from another poster I have nbow realized that as long as the developers are on the local network and we have one 64bit Linux machine running each of them can use an X terminal and log on to the Linux machine and do their work from their own PC:s. So that is probably the final solution.
yes, I suggested this myself in an earlier email. I guess you missed it ;)
I agree, this sounds a much easier to maintain solution.
Notice also that VPC2007 does not support running anything but a 32 bit virtual machine emulation.
VPC isn't the only virtualisation software around - Are you tied to VPC, or could you consider say VMWare instead, which does support 64 bit guests ?
But that is $200 per developer and it does not work anyweay since the developer CPU is 32 bit, VMWare does not emulate the CPU either, what you have on your PC is what you can have in your virtual machine.
Actually, VMWare now release their "Server" product for free. I've used it myself on linux to run an XP guest quite successfully. See
http://www.vmware.com/products/server/
That said, I don't think virtualisation is the answer for you here, as no solution is going to allow you to run a 64 but guest on a 32 bit host, in a sane way...
Chris
Bo Berglund
Bo Berglund wrote:
On Sun, 2 Sep 2007 15:10:28 +0100, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
As described above.... But from another poster I have nbow realized that as long as the developers are on the local network and we have one 64bit Linux machine running each of them can use an X terminal and log on to the Linux machine and do their work from their own PC:s. So that is probably the final solution.
Yes Bo. I was going to suggest just that solution. All developers can ssh to the one 64 bit Linux computer and run their work from a Terminal which will have GCC G++ and make. Do recall that there are many basic types of C++ and you need to let them know which to use.
u have on your PC is what you can have in your virtual machine.
Bo Berglund
Yes Bo. I was going to suggest just that solution. All developerscan ssh to the one 64 bit Linux computer and run their work from a Terminal which will have GCC G++ and make. Do recall that there are many basic types of C++ and you need to let them know which to use.
Not sure what you mean....
There are not "many basic types of c++", there is in fact only one standard
http://en.wikipedia.org/wiki/C++
Maybe what you mean is there are various different C++ compilers around ?
In an ideal world, all compilers would implement the standard in exactly the same way, so C++ that compiles and runs with one compiler would do so with all others.
Life isn't anywhere near as simple.
In fact, code that compiles withone version of gcc (http://gcc.gnu.org/), the default compiler that comes with basically any linux platform, may not work with another version out the box.
Chris
Bo Berglund wrote:
I am new to Linux, but I am invsetigating a performance issue in a big tomography program developed for Windows. We have made a command line version of this and compiled for 64 bit architecture on Win X64 to evaluate performance improvements. The compilation was done in WinXP (32 bit) using MS VisualStudio 2005 but targeting X64.
The questions now are:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
- Can we expect an improvement in performance of such a command line
(no GUI) program in Linux compared to Windows? The program performs massive math calculations and has been optimized to use the available resources well.
- The program is written in C++, would there be big porting issues
moving it from Windows to Linux, code-wise?
I understand that this is not a Fedora question per se, but since Fedora is such a popular distribution I thought that the comparison and development questions may fit here anyway. Sorry if you all disagree...
Grateful for any comment though.
Bo Berglund
In Linux Bo, if you want to write in 64 bit you load the version of Fedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
On Sat, 01 Sep 2007 05:23:18 -0600, Karl Larsen k5di@zianet.com wrote:
Bo Berglund wrote:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
In Linux Bo, if you want to write in 64 bit you load the version of Fedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Yes, I understand that in 64bit Linux you would be able to compile for the 64bit platform.... But our development machines are mostly (95%) Windows 32bit systems and I had in mind to use VirtualPC in order to have the developers running Linux on their own Windows machines for compiles etc. Then we would use a single hardware Linux machine for actual testing.
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
Bo Berglund
On Sat, 2007-09-01 at 13:49 +0200, Bo Berglund wrote:
On Sat, 01 Sep 2007 05:23:18 -0600, Karl Larsen k5di@zianet.com wrote:
Bo Berglund wrote:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
In Linux Bo, if you want to write in 64 bit you load the version of Fedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Yes, I understand that in 64bit Linux you would be able to compile for the 64bit platform.... But our development machines are mostly (95%) Windows 32bit systems and I had in mind to use VirtualPC in order to have the developers running Linux on their own Windows machines for compiles etc. Then we would use a single hardware Linux machine for actual testing.
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
On 32-bit F7:
$ gcc -m64 foo.c foo.c:1: sorry, unimplemented: 64-bit mode not compiled in
So the distribution compilers can't do it. It may (should) be possible, but you'll probably have to build your own gcc from source.
Bo Berglund
Bo Berglund wrote:
On Sat, 01 Sep 2007 05:23:18 -0600, Karl Larsen k5di@zianet.com wrote:
Bo Berglund wrote:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
In Linux Bo, if you want to write in 64 bit you load the version of Fedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Yes, I understand that in 64bit Linux you would be able to compile for the 64bit platform.... But our development machines are mostly (95%) Windows 32bit systems and I had in mind to use VirtualPC in order to have the developers running Linux on their own Windows machines for compiles etc. Then we would use a single hardware Linux machine for actual testing.
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
Bo Berglund
Hi Bo, sorry but I am ignorant about Windows. I have been just Linux for many years. Each year Linux seems to get better. That doesn't seem to hold for Windows. I think WindowsXP with all the updates is a pretty good operating system. Vista seems to have been an error.
On Saturday 1 September 2007 12:49:37 pm Bo Berglund wrote:
On Sat, 01 Sep 2007 05:23:18 -0600, Karl Larsen k5di@zianet.com
wrote:
Bo Berglund wrote:
- Is it possible to cross-compile on Linux 32 bit to produce an
executable for the 64bit architecture Linux as well as 32 bit?
In Linux Bo, if you want to write in 64 bit you load the version of Fedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Yes, I understand that in 64bit Linux you would be able to compile for the 64bit platform.... But our development machines are mostly (95%) Windows 32bit systems and I had in mind to use VirtualPC in order to have the developers running Linux on their own Windows machines for compiles etc. Then we would use a single hardware Linux machine for actual testing.
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
You could take a different approach, and not use virtual machines at all !
Why not install the linux distro of your choice on some decent sized server or group of servers. Something with a decent cpu power and ram.
Then, on your developer machines install an X windows system. Something like the commercial exceed package or the free cygwin/X package. This will allow your developers to start full remote X sessions on your linux servers and use them directly for the compilation tests etc.
Bo Berglund
On Sat, 1 Sep 2007 15:09:23 +0100, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
You could take a different approach, and not use virtual machines at all !
Why not install the linux distro of your choice on some decent sized server or group of servers. Something with a decent cpu power and ram.
Then, on your developer machines install an X windows system. Something like the commercial exceed package or the free cygwin/X package. This will allow your developers to start full remote X sessions on your linux servers and use them directly for the compilation tests etc.
Very inteersting idea, didn't think about that for some reason. I will investigate this approach for sure!
Bo Berglund
On Sat, 2007-09-01 at 13:49 +0200, Bo Berglund wrote:
Yes, I understand that in 64bit Linux you would be able to compile for the 64bit platform.... But our development machines are mostly (95%) Windows 32bit systems and I had in mind to use VirtualPC in order to have the developers running Linux on their own Windows machines for compiles etc. Then we would use a single hardware Linux machine for actual testing.
Unfortunately VirtualPC2007 does not support loading anything else than 32 bit operating systems into a virtual machine, so we are left with that. We use VPC2007 a lot for testing purposes, so we are comfortable with that system except for the 64bit support (or lack thereof).
Have you looked at qemu at all? Check out: http://www.h7.dion.ne.jp/~qemu-win/
It should be able to run a 64-bit virtual system under Windows... and it's completely free (in all ways).
Jonathan
Jonathan Dieter <jdieter <at> gmail.com> writes:
Have you looked at qemu at all? Check out: http://www.h7.dion.ne.jp/~qemu-win/
It should be able to run a 64-bit virtual system under Windows... and it's completely free (in all ways).
Yes, QEMU can run x86_64 VMs on a 32-bit host. That's how the x86_64 RPMs at http://repo.calcforge.org/fedora/ are built. (I use a 32-bit Fedora as the host though, not Window$.) However, this isn't anywhere near fast, it's about 50 times slower than the native hardware! Running 32-bit on 32-bit or 64-bit on 64-bit can be accelerated with kqemu, but running 64-bit on 32-bit is only possible in software, which is really slow.
Kevin Kofler
On Sun, 2 Sep 2007 05:28:45 +0000 (UTC), Kevin Kofler kevin.kofler@chello.at wrote:
Jonathan Dieter <jdieter <at> gmail.com> writes:
Have you looked at qemu at all? Check out: http://www.h7.dion.ne.jp/~qemu-win/
It should be able to run a 64-bit virtual system under Windows... and it's completely free (in all ways).
Yes, QEMU can run x86_64 VMs on a 32-bit host. That's how the x86_64 RPMs at http://repo.calcforge.org/fedora/ are built. (I use a 32-bit Fedora as the host though, not Window$.) However, this isn't anywhere near fast, it's about 50 times slower than the native hardware! Running 32-bit on 32-bit or 64-bit on 64-bit can be accelerated with kqemu, but running 64-bit on 32-bit is only possible in software, which is really slow.
With VirtualPC2007 on Windows the CPU is not emulated, it is virtualized, so the real host hardware is actually used concerning RAM and CPU. All other hardware is emulated. But this makes VPC2007 very fast, you barely notice that you are running in a virtual machine.
Of course it also means that the CPU is given, if you have a 32 bit CPU, that's all you are ever going to be using in a virtual machine as well...
Bo Berglund
On Sat, 2007-09-01 at 05:23 -0600, Karl Larsen wrote:
In Linux Bo, if you want to write in 64 bit you load the version ofFedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Just to be contrary, what would you suggest if Bo only has access to 32-bit hardware, but wants to create 64-bit binaries to run on another machine?
Matthew Saltzman writes:
On Sat, 2007-09-01 at 05:23 -0600, Karl Larsen wrote:
In Linux Bo, if you want to write in 64 bit you load the version ofFedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Just to be contrary, what would you suggest if Bo only has access to 32-bit hardware, but wants to create 64-bit binaries to run on another machine?
Unless he wants to build his own version of binutils and gcc, that targets 64 bit ELF, he should simply build the software on the other 64 bit machine.
On Sat, 2007-09-01 at 21:20 -0400, Sam Varshavchik wrote:
Matthew Saltzman writes:
On Sat, 2007-09-01 at 05:23 -0600, Karl Larsen wrote:
In Linux Bo, if you want to write in 64 bit you load the version ofFedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Just to be contrary, what would you suggest if Bo only has access to 32-bit hardware, but wants to create 64-bit binaries to run on another machine?
Unless he wants to build his own version of binutils and gcc, that targets 64 bit ELF, he should simply build the software on the other 64 bit machine.
Yes, I actually suggested building one's own early in the thread. Should have made it clearer that I was just trying to yank Karl's chain a bit...
Matthew Saltzman wrote:
On Sat, 2007-09-01 at 21:20 -0400, Sam Varshavchik wrote:
Matthew Saltzman writes:
On Sat, 2007-09-01 at 05:23 -0600, Karl Larsen wrote:
In Linux Bo, if you want to write in 64 bit you load the version ofFedora 7 that is totally 64 bit. This is the f7 x86-64 distribution and different than Microsoft, you can download this free. Then you can compile in C or C++ with 64 bit. No need to cross/compile.
Just to be contrary, what would you suggest if Bo only has access to 32-bit hardware, but wants to create 64-bit binaries to run on another machine?
Unless he wants to build his own version of binutils and gcc, that targets 64 bit ELF, he should simply build the software on the other 64 bit machine.
Yes, I actually suggested building one's own early in the thread. Should have made it clearer that I was just trying to yank Karl's chain a bit...
I felt the chain pull. You can pre-set a lot of things in GCC, too many I think but the bit size is not settable. Too bad but it is that way because it isn't easy to do ;-)
Bo Berglund writes:
- The program is written in C++, would there be big porting issues
moving it from Windows to Linux, code-wise?
That depends upon what libraries your C++ code uses. If it uses Windows-specific libraries, any GUI libraries, they are obviously not available on Linux.
If your C++ code uses only the standard C library and only the C++ STL, it should compile and run on Linux with minimum fuss, unless, without your knowledge or awareness, you are using any Microsoft-specific perversions of standard C library calls or C++ STL, in your code.
On Saturday 1 September 2007 2:27:41 pm Sam Varshavchik wrote:
Bo Berglund writes:
- The program is written in C++, would there be big porting issues
moving it from Windows to Linux, code-wise?
That depends upon what libraries your C++ code uses. If it uses Windows-specific libraries, any GUI libraries, they are obviously not available on Linux.
If your C++ code uses only the standard C library and only the C++ STL, it should compile and run on Linux with minimum fuss, unless, without your knowledge or awareness, you are using any Microsoft-specific perversions of standard C library calls or C++ STL, in your code.
Even once you have worked through the slight oddities that mean C++ on windows isn't quite the same as C++ on linux, you can find cases where at run time you don't get the same results. If this is important to you it can be a right pain to trace problems. A couple examples found recently in a project I work on that supports both windows and linux,
float x = pow( 10, -6 );
on linux this gives you 1e-6. On windows you get 0 !!
std::sort( .... ); The STL standard states that for elements that are "equal" (whatever that means for the predicate) the final order is not defined. Anything which is not defined in the standard you can read as possibly platform dependant. IN this case the fix is easily, as std::stable_sort(...) is for exactly this case, as in preserve the original order of 'equal' elements.
These are just two examples, I'm sure there are many other ways in which you could find linux and windows don't give identical results. If you care about this, you might have a lot of debugging on your ands.
On the plus side, testing your code on two quite different platforms is quite enlightening and useful in a testing sense. Both linux and windows can have oddities and things which diverge from the standard, and this is a great way to find them....
Chris
On Sat, 2007-09-01 at 14:59 +0100, Chris Jones wrote:
Even once you have worked through the slight oddities that mean C++ on windows isn't quite the same as C++ on linux, you can find cases where at run time you don't get the same results. If this is important to you it can be a right pain to trace problems. A couple examples found recently in a project I work on that supports both windows and linux,
float x = pow( 10, -6 );
on linux this gives you 1e-6. On windows you get 0 !!
You do? I don't. Not with VC++-2005 and not with gcc in Cygwin. I get 1e-6 on every platform I've tried so far. How did you do that experiment?
std::sort( .... ); The STL standard states that for elements that are "equal" (whatever that means for the predicate) the final order is not defined. Anything which is not defined in the standard you can read as possibly platform dependant. IN this case the fix is easily, as std::stable_sort(...) is for exactly this case, as in preserve the original order of 'equal' elements.
That's true anywhere. "Undefined" means t's not even guaranteed that you get the same output for two successive runs of the same program on the same machine.
These are just two examples, I'm sure there are many other ways in which you could find linux and windows don't give identical results. If you care about this, you might have a lot of debugging on your ands.
On the plus side, testing your code on two quite different platforms is quite enlightening and useful in a testing sense. Both linux and windows can have oddities and things which diverge from the standard, and this is a great way to find them....
Absolutely. Different hardware with the same software can also make a difference. Note that divergence from the standard is a compiler bug (and should be reported as such to the vendor). Relying on behavior that is not specified by the standard is dangerous, at best, especially for code that is to be run cross-platform.
Chris
float x = pow( 10, -6 );
on linux this gives you 1e-6. On windows you get 0 !!
You do? I don't. Not with VC++-2005 and not with gcc in Cygwin. I get 1e-6 on every platform I've tried so far. How did you do that experiment?
I didn't do it myself, I must confess. It was reported be a work colleague recently who was trying to iron out differences in an application between linux (gcc3.4.6 on SLC4) and windows (vc++ 7.1, so the '2003' one).
I guess the problem must have been fixed between VC 2003 and 2005 ?
std::sort( .... ); The STL standard states that for elements that are "equal" (whatever that means for the predicate) the final order is not defined. Anything which is not defined in the standard you can read as possibly platform dependant. IN this case the fix is easily, as std::stable_sort(...) is for exactly this case, as in preserve the original order of 'equal' elements.
That's true anywhere. "Undefined" means t's not even guaranteed that you get the same output for two successive runs of the same program on the same machine.
Agreed. Although in this case we hadn't noticed any repeatability problems, but that must likely just luck. In general don't rely on any undefined behavior. My point was its easy to not realize you are using some undefined behavior, until you compare two different compilers etc.
Chris
BB = Bo Berglund BB>> 3) The program is written in C++, would there be big BB> porting issues moving it from Windows to Linux, code-wise?
SV = Sam Varshavchik SV> That depends upon what libraries your C++ code uses. SV> If it uses Windows-specific libraries, any GUI libraries, SV> they are obviously not available on Linux.
Sam,
I work at a company where we use wxWidgets (http://www.wxwidgets.org/) for all of our GUI development in C++. All of our apps our built to run on 32-bit Windows using Visual Studio .NET 2003 and both 32-bit and 64-bit versions of Fedora using GCC. Fedora, via yum, provides a packaged version of wxWidgets, but we usually build it from the wxWidgets SVN repository.
No code modifications are required to build the apps on Windows vs. Fedora, so I guess I would disagree with your statement "any GUI libraries, they are obviously not available on Linux", but I would agree that most projects do not consider cross-platform GUI development when they are initially developed, so they are not using a library like wxWidgets.
Hope that helps with any cross-platform GUI development anyone out there is considering.
Pete
On Mon, 2007-09-03 at 10:02 -0700, Peter J. Stieber wrote:
BB = Bo Berglund BB>> 3) The program is written in C++, would there be big BB> porting issues moving it from Windows to Linux, code-wise?
SV = Sam Varshavchik SV> That depends upon what libraries your C++ code uses. SV> If it uses Windows-specific libraries, any GUI libraries, SV> they are obviously not available on Linux.
Sam,
I work at a company where we use wxWidgets (http://www.wxwidgets.org/) for all of our GUI development in C++. All of our apps our built to run on 32-bit Windows using Visual Studio .NET 2003 and both 32-bit and 64-bit versions of Fedora using GCC. Fedora, via yum, provides a packaged version of wxWidgets, but we usually build it from the wxWidgets SVN repository.
No code modifications are required to build the apps on Windows vs. Fedora, so I guess I would disagree with your statement "any GUI libraries, they are obviously not available on Linux", but I would agree that most projects do not consider cross-platform GUI development when they are initially developed, so they are not using a library like wxWidgets.
Hope that helps with any cross-platform GUI development anyone out there is considering.
Qt is also cross-platform, and there are GTK+ and Glade ports for Windows as well. The standard Win32 GUI is not available for Linux, though, AFAIK, other than via Wine.
Pete
-
Bo Berglund -
Chris Jones -
Jonathan Dieter -
Karl Larsen -
Kevin Kofler -
Matthew Flaschen -
Matthew Saltzman -
Peter J. Stieber -
Sam Varshavchik