I have a compiler, CCSC, that I haven't been able to run since upgrading to 64 bit Ubuntu. It is supposed to be compatible, but it just core dumps and crashes. So I need to reboot into my 32 bit Ubuntu to use it. CCS isn't supporting it at all.
I'm wondering if I could use chroot in the compiler call path in my IDE and just run the one program in the 32bit environment.
Or if not, any ideas of how I could accomplish this. I'm using XC8 now, but I have to support firmware that was written for CCS.
Any help at all is greatly appreciated.
Related
Did anyone manage to build Rem Objects Pascal Script for Linux 64? Currently Linux Platform seems only to be supported for FPC. That and the fact that it compiled with Kylix long ago leads me to the assumption that it should also be possible to compile it in the modern Delphi 10.4 Linux Compiler.
Out of the box the build fails in the assembler parts and many other areas using the current GitHub code.
I am only talking about the core of compiling and executing scripts, perhaps adding database stuff and no GUI functionality.
Please note: I am not asking for "please do the work for me"! I just would be grateful if anyone has managed getting it up and running with Delphi 10.4 Linux and would share his experiences and tips.
Thanks in advance.
I'm using Linux (Ubuntu) 64bit system and need to make a DLL for MetaTrader4.
I did read lots of things I found about it, but it is very chaotic and confusing. There are many DLLs which are not acceptable for MT4. So far it seems that I need: a 32bit DLL made by using C++. There might be other criteria that I don't know. What IDE/compiler (free, if possible) should I use for it on my 64bit Linux system?
I've never made any DLL, so please tell me if there are other important conditions as well that I should know.
The only way to create a dll for Linux is using .net core however this will not work for anything MT4 related.
MT4 in all its variations is hooked into specifics system level api on windows and the only way to run anything dealing with it on Linux is to build it for windows and run whatever you write from inside wine.
I have previously used the GNU FORTRAN compiler gfortran. But since the Intel FORTRAN compiler for Linux is available for personal non-commercial use I decided to give it a try. Is it possible to use it under Cygwin? I wouldn't know where to begin to get it to work, so all help is welcome.
My earlier comment turned into an answer of sorts ...
At first glance an interesting question. But what will you do with the executables that the compiler creates, if you manage to get that far ? I doubt that you will, but if you did you would have a Linux executable on a Windows platform (and cross-compiling for Windows from Linux is not supported by the Intel compiler). Don't forget that Cygwin is not Linux, it's a (DOS/Windows) program that provides Windows users with some of the facilities that Linux provides its users. To run an executable from the Cygwin command line the executable must have been built for DOS/Windows.
You might, and I have no experience either way, get further installing a Linux VM on your Windows PC and installing the compiler on the VM. You're still not going to get Windows executables out of a Linux compiler, but you would get, if success greeted you, executables running under the VM.
I've been fighting a whole day with UNIX utilities - so sorry if I appear confused! I'm describing my painful and (so far) fruitless process a little because maybe someone may correct me, or maybe describing the process might be helpful to someone later on. If you want to skip this, the question is bolded below.
So I'm trying to convert a Linux program developed using kdevelop. I'm trying to make it run on Windows 7. (This is the SHoUT Speech Took mentioned here, developed by Marijn Huijbregts).
I've wasted half a day trying to install kdevelop on Windows, only to understand that kdevelop can't run on Windows and that I've been installing KDE all that time :( (If kdevelop CAN run on Windows, information would be highly appreciated).
OK, so following the advice in SO's Best environment to port C/C++ code from Linux to Windows, I installed MinGW32 only to find out that SHoUT's makefile contains targets such as aclocal, autoheader etc. - I've come face to face with the hitherto unknown GNU Build System.
I'm now in the middle of installing GnuWin32 using GetGnuWin32. This is taking hours. And I suspect that once it finishes, I'll stumble on something else.
A day of pain - and still not one code line compiled :((.
So, I'm thinking about an alternative approach: Install Linux and run kdevelop as a cross-compiler to compile to Windows. As this is a console application, MAYBE it'll be easier.
So, finally, my question:
If I want to install Linux guest in VMWare Workstation (8, running on Windows 7 host), I understand I need a "distribution". I understand there's a ton of distributions, some free, some paid.
Which distribution should I choose which would run kdevelop and be as simple as possible? I just want to ##$$ing compile, and I can't stand one more day like this...
Avi
Edit:
I've tried compiling the code using VS - very tedious. Many differences between Linuix/GCC and windows/MSVC. Moreover, this is code deveoped by someone else, and I'm not even sure that the program sovles the business needs. So I've decided on the following process:
Configure Linux and run the software on Linux.
Validate that program solves business rule. If not - Abort.
Try cross oompiling on Linux. If running on Windows, verify by comparing outputs to those obtained on Linux. If good - Done.
Try compiling on Windows using ported Windows versions of the GNU Build tools. Use understanding and values obtained from building on the Linux target. If good - Done. Else
Abend and try another solution to the business problem, or try the MS tools (again using understanding and values obtained from building on the Linux target).
Many distributions are possible. Mandriva is KDE based.
But you can also install a Debian distribution, and install KDE in it.
I suggest to contact the ShOUT project community.
You should not cross-compile. MinGW can come handy but it is not required. What you need is to port the code and its dependencies to Windows, and there is nothing wrong if you use Visual Studio, for example.
I am using Ubuntu on VirtualBox OSE and through it use kdevelop and it runs seamlessly. Alternatively you can try kubuntu.
Why VirtualBox OSE - Free, Mature
It is easier to compile with MinGW on Windows than cross compile on Linux.
Build system... It could be quite easy to write Your own. Much easier than actual porting of C++ code. Could be even easier than using GNU Build System.
Please DON'T install Linux! It will take you another half a day and another questions asked here if you're doing it for the first time.
Just install VirtualBox and grab some VirtualBox image from some site. Kubuntu should be working fine with your KDE stuff: http://virtualboxes.org/images/kubuntu/
It will get you a running KDE Linux in just 5 minutes.
I have a ARM11 based hardware board which runs a Linux kernel ver. 2.6.21.5-cfs-v19. I have my application running on this ARM-LINUX board. To do source level debugging, of my application I used to use gdb from command prompt of the linux board, that was with some earlier version of the board linux version.
With this version 2.6.21.5-cfs-v19, I dont have a related version of gdb for the board. I tried to look around to get gdb for this version of linux and arm port of it, but without much success. Can anyone point me where I can get either an independant executable for gdb for above mentioned os and board configuration or source for the same, which I may try compiling for that target.
-AD.
Sometime ago I published an article about cross-target debugging with GDB and GDBServer. The target processor there is PPC7450, but it's rather detailed, so maybe you'll find it useful.
You might have some luck using OpenEmbedded. If there's no precompiled version you can use right away, setting up an OE-cross compile environment is not that hard.
Another option could be to install gdb-server on the board, like described in this blogpost.