We have been asked if our C++Builder VCL program could be compiled using gcc on linux. I don't believe this is in order to run the code, but to evaluate it using HP Fortify. I can't imagine how such a thing could be done, but most of you folks are smarter than me, perhaps someone can think of a way.
Thanks!
Related
I was wondering if there is any Borland cross compiler that can make my windows code work on linux without wine.I'm using winxp with delphi 7. I was always wondering if it was possible to code same tool I coded in windows , again in Linux and how is it possible to code same tool by using pascal code in linux.Thanks
The best solution is Lazarus, the delphi-like GUI for Free Pascal. If you were using "pure" vcl, without Windows internales or any special add-ons the migration will be a pice of cake :)
Take a look here: http://lazarus.freepascal.org
BTW - Lazarus and FPC are true mulitplatform - you can compile code for Linux, Windows, MacOS and more with the same codebase :)
Your only option, if you want a Borland Delphi cross-compiler, is CrossKylix. This isn't a real cross-compiler. Instead you run the Kylix compiler for Linux under an emulated Linux environment.
Note that you'll be forced to use CLX rather than VCL and that Kylix is well and truly dead nowadays. Personally I think Wine is probably an easier and better option.
First of all, it all depends on what system functions you used in your programm. In most cases, there will be no possibility to cross-compile it under linux.
But, in some cases Borland Kylix can help, but, afaik, it's almost dead now.
Delphi 10.2 Tokyo supports Linux 64-bit Native Code Compilations.
To get some preview screenshots, click this post:
https://helloacm.com/delphi-compiles-code-to-linux-64-bit-server/
I'm pretty sure this is possible but I'm not sure how to go about it. I'm very new to building with GCC in general and I have never used FreeRTOS, but I'd like to try getting the OS up and running on a TI ARM Cortex MCU but with a slight twist: I'd like to get it up and running with Pascal. I'm curious:
Is this even possible to get work? If not, the next issues are kind of moot points.
From my Delphi days, I vaguely recall the ability to access functions in C libraries. I'm wondering if I would have access to the C routines in FreeRTOS.
If I use the GCC version (preferable) would I be able to debug using OpenOCD on the target? I'm not quite sure how debug symbols work and if it's more or less language agnostic (hopefully, in this case).
As kind of a bonus question a bit outside the scope of the original query, can I simulate FreeRTOS on an x86 processor (e.g. my development PC) for easier debugging during development? (With a Pascal program, of course..)
I haven't found any documentation on achieving this, so hopefully someone here can shed some light! Any resources would be most helpful. Like I said, I'm very new to this kind of development. I'm also open to suggestions if you think there is a better alternative.
FYI, my preferred host configuration would be something similar to:
Linux (Ubuntu/Debian)
Eclipse IDE for development, unit testing, and hopefully simulation / debugging
OpenOCD for target debugging
GNU Pascal + FreeRTOS on target
FreeRTOS is C source code, so like you say you would have to have some mechanism for linking C with your Pascal programs. Also, FreeRTOS relies on certain registers to be used for things like passing a parameter into a task (as a hypothetical example, the task might always expect the parameter to be in register R0) so you would have to ensure the ABI for the C compiler and the Pascal compiler was the same - or have your task entry in C then have it call a Pascal function (very nasty). Then there is the issue of interrupts, calling inline macros, etc. I would say this would be extremely difficult to achieve.
Both GNU Pascal and Free Pascal support linking to C (gcc) and ARM, as well as calling pascal code from C etc. Writing a header and declaring the prototypes with cdecl is all there is to it.
Macros are a bit bigger problem. Usually I just rewrite them to inline functions (what they should have been anyway). Except for the macro/header issue, the problems are more compiler specific functionality (which you also would have a problem with when porting from one C compiler to the next)
If you prefer TP/Delphi dialect, Free Pascal is the better choice.
I run my old Delphi code fine on my sheevaplug.
There is already an example for FreeRTOS/GCC/OpenOCD on a TI Cortex-M3 (was Luminary Micro Cortex-M3). Be aware though that this is a really old example and both the Eclipse and OpenOCD versions used are out of date.
Although there is an Eclipse project provided, the project is configured as a standard make (as opposed to a managed make) project, so there is a standard makefile that can be just as easily executed from the command line as from within Eclipse.
http://www.freertos.org/portLM3Sxxxx_Eclipse.html
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!
I want to start making a little window-based program that runs on both Linux and Windows flawlessly.
It must have a GUI. What are the things I should be reading about? I'm completely in the dark regarding this.
Thank you.
If you want to leverage your C#/.NET knowledge (IronPython,...), you should go with Mono. Its IDE is called MonoDevelop and works in Linux, Mac and Windows. You can keep using WinForms or switch to Gtk#, which is a nice wrapper around gtk+.
Also, make sure you read the application portability guidelines which covers different strategies and common pitfalls.
Enjoy!
You could try Java and run the same compiled bytecode in both places. Or try C++ with Qt or wxWidgets. With C++ though you will have to compile for each platform. Another possibility is Tcl/Tk
As a C# developer, I'd suggest Java with the Swing toolkit. NetBeans helps you get started easily, like Visual Studio.
Download, install, create a new prject, and there you have it; a form in front of you to drop controls and hook up to the code just like in VS + C#, except it's cross-platform (write once, run anywhere). And the language is very similar to C# (which was actually inspired by it). There are also countless books to help you get started with Java and GUI development in it too.
If you don't like Java for some reason, and you're willing to learn/use C++ (with extensions), have a go at Qt, and the Qt SDK, which includes a form designer as well, with a really nice IDE GUI. If you know C++, Qt should be a breeze. It's also cross-platform (write once, compile anywhere).
Good luck.
If you want to utilize your C# knowledge, you might want to have a look at Mono. But there are many, many other alternatives too.
I'm working on writing a kernel, and I have a few friends working with me on the project. We've been using DJGPP to compile the project for a while, but we're having some cross-platform compatibility issues with compiling this way that have left my main Partnet on the project unable to compile on Windows XP. (DJGPP's GCC is having issues with argument lists longer than 127 on windows XP, but not having issues with the same argument lists on Vista. So, for once, Vista works better than XP at something. o.O)
Anywho, rather than try to work out some dirty hack to make the darn thing compile with DJGPP, we've decided that we want to ditch DJGPP entirely and work with a different version of GCC for windows. The trouble is, MinGW (to my knowledge) doesn't let us use NASM syntax for the assembly portions of the code, and it would be a bit of a pain to convert it all to AT&T syntax at this point. Possible of course, since its fairly early in the project, but a pain.
So now you know the issue. My question is this: What GCC compiler distro for Windows will allow us to most easily port this project to itself? Ideally, we're looking for something that can do NASM assembler syntax, not have any reliance on externel dlls (this is a kernel here, it won't have access to them) and will work consistantly on multiple versions on Windows. What are your recommendations about the best way to go about doing this, and what version of GCC for windows do you recommend?
Note that if we are going to need to convert the project to AT&T syntax that's OK, I'd just like to not do that. We're actually using NASM to assemble the assembly bits of it, and that produces a valid .o file, but MinGW isn't able to link that in for some reason. I think the inline assembly bits (maybe 5 lines) are already AT&T syntax, as required by GCC.
Thanks!
You are probably passing the wrong object type to nasm with the -f option.
I'll bet you're passing -f coff.
You will need to pass -f win32.
Build a cross-compiler.
http://wiki.osdev.org/GCC_Cross-Compiler
This is what I did when transitioning from DJGPP for development on a Windows host. I recommend the Cygwin method, as it's slightly more stable than MSYS.
Once you've done that, configure NASM to build elf32 object files, and you're good to go.
Are you using NASM compiled for DOS or for Windows? I did not look, but it is possible that there is a difference. Also, if your NASM is too old, it might not be able to generate something MinGW can understand.
A quick Google search found a tutorial on compiling x264 under MinGW, where one of the steps is to compile NASM on MinGW.
Failing that, you could try (as suggested on a comment to another answer) using objcopy.