I am trying to build a project in QNX Momentics IDE (4.6) using qcc in Linux. I fail to succeed the build process with the following error:
virtual memory exhausted: Cannot allocate memory
/opt/qnx641/host/linux/x86/usr/lib/gcc/i386-pc-nto-qnx6.4.0/4.3.3/cc1plus error 1
The project has a cpp file with more than 1.3 MLOC. This one is an autogenerated code from a large Matlab/SIMULINK simulation model so it is not easy to divide and conquer.
It is hard to understand if it is LOC limit of qcc compiler or due to a programming practice in the autogenerated code.
I would like to ask:
Is there any source file size limit for qcc?
What are the bad programming practices that cause this?
Any suggestions to fix virtual memory exhausted problem of cc1plus?
Q1: Is there any source file size limit for qcc?
A1: qcc = gcc. More accurately: qcc is a lightweight wrapper that calls gcc; all the real work is done by gcc. GNU software is, as a general philosophy, designed to not impose arbitrarily limit and I presume this is especially true for gcc. Even if there exist arbitrarily limits you are not hitting those because you are running out of system memory.
Random links:
preprocessor limits: http://gcc.gnu.org/onlinedocs/cpp/Implementation-limits.html
some gcc limits benchmarking: gcc module size limits
Q2: What are the bad programming practices that cause this?
A2: E.g., dumping all source code into a single file, as you demonstrated. I'd say this question is not relevant to your case because you already stated you don't have control over the generated code.
Q3: Any suggestions to fix virtual memory exhausted problem of cc1plus?
A3: a) put more ram into your host computer (may or may not help depending on how much you have and if your OS is 32 or 64 bit); b)increase your swap-space (same applies); c) if a/b does not help then upgrade your OS to 64 bit and try a/b again. Unfortunately, this 64-bit suggestion almost surely does not apply to the gcc version that QNX shipped with 6.4.1. Maybe not even to the latest one.
As a general suggestion, since qcc is using gcc I'd recommend that you have the same code build using the host's gcc (gcc that is shipped with your Linux). Once that works you may start looking for the differences, which likely boil down to 64-bit support.
Related
note:before down vote or anything like this,this is a general question to understand more how everything is going
the question simply is:
assume I compiled a program with c++11 features (using VS2012 on windows) is there a guarantee that this program will run on older processors?(like core 2 duo;as most laptops got this)
I'm currently working with VS2010,but found libraries that needs C++11 features.
so I want to port the whole work to VS2012,but my knowledge is limited about how this gonna work
correct anything wrong in the question
edit:
another 2 questions:
1 -can I "mix" a compiled c++11 program with older one?
like calling functions which are inside the new version (.dll) from an old version(.exe) so I got 2 files:
1 is compiled with VS2010 the other 1 is compiled with VS2012,with DLL EXPORT can they work like that?
2 -suggest a better environment than VS2012 for windows
As long as the architecture for which the target is built is the same (x86 for 32 bits or amd64 for 64 bits) you shouldn't have any issue.
Of course you will need to provide the older machine with the correct runtime library to run your program (for the current architecture).
Yes, The compiler requires additional libraries to build the program. But this shouldn't affect the ability to run on older processors. The only time this changes is when your trying to run a 64 bit program on a 32 bit processor.
Porting to VS2012 is simple, open the solution in VS2012, and save it as a vs2012 solution. It should all be fine.
Edit: odds are, if your new to programming, all of your programs are compiled for 32 bit processors by default unless you code to change this, so you shouldn't worry. You can run 32 bit programs on 64 bit processors, just not the other way around. If you really want to step it up, you can make a program that can run on both processors ;)
given a compiled executable the usual requirements to run it are:
ABI
platform
libraries
and since Windows is a commercial product, depending on what are you doing, you could add another factor
environment
which means that sometimes a software house intentionally breaks the compatibility with other products to sell more stuff.
In general VS it's not that good, certainly it's not the best the compiler I have ever used and basically anything from GCC to Clang to MinGW can supersede VS easily, but VS it's the official compiler and environment for Windows so this is what you have to deal with most of the time.
If you have fulfilled the listed requirements you are good to go.
By the way a Core 2 Duo it's not that old, and the actual iCore generation it's not that different either.
I have been developing a C++ application to run on a 64 bit Ubuntu 12.04. I develop the code on my 32 bit 12.04 Ubuntu laptop, then upload it to a git repository, pull it on the server and build the pulled source natively.
Until recently things worked well and I had no problems but today g++ 4.6.3 crashed when I tried to compile on the 64 bit server and I got an output telling me to submit a crash report (g++ 4.6.3 is the same version I have on my development machine also). The identical code did not cause a crash on my dev machine.
I am not asking why it crashed, but I would like to know what the problem was if possible. Does g++ produce any file logs when it encounters problems?
As far as I can tell my code is doing nothing controversial, I am not creating templates, I simply use a couple of boost libraries, mysql++, openssl and some static libraries I have written myself.
I really need to run this application every day so I want to fix this as soon as I can. I can think of the following ways to deal with things
Try and find out what aspect of my code caused the compiler to crash and rewrite my code accordingly.
Rent another server.
Upgrade (or downgrade) g++ or create an additional g++ on the server and try that. I am reluctant to do this as I have read that you can ruin your system when upgrading g++ on Ubuntu.
I use Eclipse to build everything on my dev machine and simply build code on my server using the Eclipse generated makefile that I have made part of the git project - I could write my own makefile in case something in there is causing the crash on the 64 bit server.
I would really welcome advice on how to proceed. I am not an expert on how compilers work internally and this is the first time I have encountered this kind of error so I am not quite sure what to do next.
I would really welcome advice on how to proceed
One reason for a crash might be hardware problem (faulty disk, disk controller, memory, or something else). This is hard to detect.
Another reason might be a compiler bug, but very unlikely.
What you can do is :
check the hardware of the server (run all possible checks you can think of). Try to compile many times on a different machine
make sure your system is not running out of virtual memory
upgrade or change the compiler, and see if it happens
There are various article explaining that g++ can crash because of HW problems :
crash during compiling - Most likely there is nothing wrong with your installation, your compiler or kernel. It very likely has something to do with your hardware. There are two exceptions to this "rule". You could be running low on virtual memory, or you could be installing Red Hat 5.x, 6.x or 7.x
crash during optimization
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
Question in one sentence: How can I compile code for AIX using G++ on Ubuntu? (Assuming it is possible)
I hope that it is as simple as adding an option to the make file to specify target processor. I am a novice when it comes to most things compiler related.
Thank you in advance.
What you are looking for is a cross-compiling toolchain.
A toolchain includes a cross-compiler (a compiler that runs on the current platform but builds the binary code to run on another, on your case, AIX), the C or C++ library, and some other interesting tools.
I have successfully used buildroot in the past, which is a tool that automates the process of creating a cross-compiling toolchain. I know they support several target platforms, maybe AIX is among them.
If you want to compile your toolchain by hand, take a look at the Roll-your-own section on this page.
Another approach, probably easier on your case, would be to install a AIX system inside a virtual machine on Ubuntu. This way you would have access to a complete AIX system running inside your machine, giving the opportunity to develop and test your application under real conditions (or whatever reasons you may find interesting for doing such a thing).
You'll want to download the right version of g++ (i.e., one that generates code for POWER, or whatever you're running AIX on), and compile that to run under Ubuntu.
Try to compile with -maix32 or -maux64 (like g++ -m32 file.cxx), it it doesn't work it means that it's not supported by your compiller.
I am working on an embedded systems project and have run into an issue of the compiler being programatically embedded in the Paradigm C++ IDE. I would like to be able to automate building.
The processor is the AMD186ES. I am not working with the OS - just baremetal stuff.
I need to generate real-mode 16-bit 8086 machine code from C++.
My googling indicates that G++ can build such code.
My questions are:
Can g++ be configured to build this machine code?
Are there other C++ compilers that can do it as well?
Your best bet is probably OpenWatcom, which includes a C++ compiler. Back in the early-to-mid 90s, I believe this was the best C/C++ compiler around. It was open-sourced a few years ago.
I am currently using gnu as (part of binutils and the assembler used for gcc) and I have successfully been assembling 16bit assembly code with the following:
as <file>
ld --oformat binary -Ttext 0x0 -e start <file>
with my assembly files starting out with:
.code16
.globl start
.text
start:
since its plain binary omitting the lines,
.globl start
start:
will simply yield an warning, even though flat binaries need no entry point.
something I learned the hard way;
-Ttext 0x0
is critical, otherwise the .text segment is pushed outside of 16bit addressing range (don't ask me why)
I am personally still learning assembly, so this is just my way, not necessarily the best way.
EDIT: If you are writing boot code, you should change
-Ttext 0x0
to
-Ttext 0x7c00
this will offset your memory addresses by 0x7c00 since boot code is usually loaded at 0x7c00 by the BIOS.
Doesn't your chip vendor (AMD, I guess) have any pointers to compilers for the chip?
If not, you may be able to use some 16-bit DOS compilers - but you'll have several potential big problems:
getting a library for the compiler that is not dependent on the BIOS or MS-DOS
debugging
linkers for embedded systems usually have specific support for locating code in specific memory regions. That's not usually included in compilers for DOS, but you may be able to find some sort of linker/locator that'll do the trick for you.
A couple of compilers that are still supported and generate 16-bit code are:
Digital Mars
Open Watcom
This google search shows a series of links for setting gcc up as a cross compiler. To get it to target something other than a standard ELF binary you can frig the output. This link discusses excluding the standard libraries and customising the output format. You may have to do some fiddling to get it to work.
As an alternative openwatcom.org has an open-source version of the Watcom C compiler, which might also be able to do what you want.
There's a patch for GCC 4.3: New back end ia16: 16-bit Intel x86
And here's an update for it. Note that it probably doesn't work very well, for example, the updated post says: "Constructors and destructors are now supported, but for some reason they
only work on the elks configuration."
This Docker container has a build of it: https://registry.hub.docker.com/u/ysangkok/ia16-gcc-rask
I didn't manage to make DOS binaries yet: How do I assemble GAS assembly and link it with the Open Watcom C library?
Take a look at bcc, which is a 16-bit x86 C compiler. For example, there are also Debian packages for it.
The most recent as per 2014 is Dev86.
Not sure but I think old version of borland c++ was able to do that.
you can download version 5.5 t : here
good luck
80186 free C compiler:
http://coding.derkeiler.com/Archive/General/comp.arch.embedded/2005-09/msg01063.html
It has been a long time since I've looked at Paradigm stuff (are they still around?) -- are you sure they don't have command-line equivalents for the compiler? My recollection is that they were built on top of Borland's compiler toolchain... So maybe an old copy of Borland compilers might do the trick?
--
Ah, looking a little futher, I find that Paradigm is still around (www.devtools.com) selling X86 tools. (Must be a cash cow!)
Their professional product includes scripting... Depending on the amount of work you plan to do, it just might be worth it to bite the bullet and buy their full offering...
Good luck.