I have a structure defined in h files and some elements of that structure are in compile time flag. The file is compiled using arm-gcc with -Otime flag. When I run it , it is giving Segmentation Fault. But when I remove -Otime flag from the makefile the code runs perfectly.
I am befuddled at this observation. Can someone share some insight on this issue ?
Unfortunately there is never one easy answer for these scenarios. Certainly in the past, whenevr I have encountered such problems, its been down to the code, the compiler or even a combination of both. It would help if you could mention the version of the compiler you are using. It could simply be a Otime bug in the compiler, which is not unheard of.
Related
I have been trying to go through this tutorial and I always get stuck in the second build of GCC when making the cross-toolchain. It errors out saying that I am attempting to call a poisoned calloc. I have gone through several patches and what they all seem to do is just #include the offending system header (in this case pthread.h) earlier in the source code. Since there are no patches for my particular problem, I have gone ahead and emulated their solutions in my case. While this works (compilation now fails because I don't have some ISL files) it feels like a hack, and I suspect that the root problem is further back in the build.
Thus, I wanted to ask:
Why are symbols poisoned? Why would the GCC maintainers want some symbols not to be used?
What are the general causes for this problem? Is it really just a bug or is this a problem that arises in more general situations?
I am more interested in the generalities of this issue, but if it helps, I am using the latest release of Alpine Linux (with gcc 12.2.1) trying to compile gcc 11.2
.0 for the same target architecture as the host (x86-64).
While working for just one month with the MPLABX5.5 + XC32 3.01 I've already had 3 separate instances where code compiled incorrectly, causing my program to fail after either the stack or frame pointer began using an incorrect address. I would like to dump these tools and try something else as tracking down compiler errors is sucking up too much of my time. Is there anything else available that I can use to work with a PIC32MM? Even access to a different compiler than XC32 might help.
I would like to do the same thing. Maybe we can collect the best options for how to get there, as after many many tries, I haven't yet been successful. As one starting point, I'd also like to be able to recompile xc32-gcc from source to understand exactly what it's doing, and to be able to compile xc32 binaries for other architectures (like, as insane as it may sound, I'd like to compile some code for the pic32mm platform with clang or gcc running on a raspberry pi.)
I would love to be able to even just compile xc32-gcc from source. I know this is possible, but I've not been successful. Some links and starts:
https://github.com/zeha/xc32
This seems to be the most recent grouping of source I've found, but I haven't yet figured out how to compile it.
ChipKit is cited a lot, but, I haven't gotten to the bottom of getting that to build for me either. There are numerous projects here, and I'm not sure how they all fit together yet:
https://github.com/chipKIT32
I suspect somebody (maybe someone who will see this post) knows the formula or script or docker file, or whatever to make this simple.
https://gitlab.com/spicastack/pic32-parts-free
This project seems close to what we're talking about, but, the
recommended way to install is with podman and gentoo. I'm not a
gentoo person (yet?), and the docker version failed for me. It's
probably a simple fix to the dockerfile for a gentoo person, but.. I
didn't get there yet. (I did try installing gentoo and started down
the path but holy cow, talk about being down a rabbit hole when what
I'm trying to do is get a pic cross-compiler working.. when emerge on my new gentoo install failed with a python error, I gave up.)
https://github.com/andeha/Twinbeam
This project also says some of the "right things" about building pic32 code using llvm, and has references to llvm2pic32 in this project: https://github.com/andeha/Sprinkle
I've also not yet managed to get this to make viable intel hex files that I can use on a pic just yet, but there's promise.
Use clang/llvm to generate code. I think it will compile C and generate mips out of the box and I've gotten that far, but I can't get it to link and produce a valid hex file yet. The linker scripts from microchip seem sort of ok, but the hex files end up putting the code in the wrong place, I think. I should probably put together a blinky-light example and try to push it farther, and share it with others to figure out what the deal is, but even stepping one step further back and just trying to get a super simple mips assembly program to get linked and be uploadable to a PIC32MM part would be a great success to me.
Maybe others have better references and links?
There is a bug in RHEL5's gcc-4.3.2 with which we are stuck. As a work-around we have extracted the missing object and put it in an object file. Adding this object file to every link makes the problem go away.
While adding it directly to LDFLAGS seems like a good solution, this doesn't work since e.g. libtool cannot cope with non-la files in there.
A slightly more portable solution seems to be to directly patch the gcc spec to add this to every link. I came up with
*startfile:
+ %{shared-libgcc:%{O*:%{!O0:/PATH/TO/ostream-inst.o}}}
where ostream-inst.o is added to the list of startfiles used in the link when compiling a shared library with optimizations.
Trying to compile boost with this spec gives some errors though since its build directly sets some objects with ld's --startgroup/--endgroup.
How should I update that spec to cover that case as well, or even better, all cases?
Go through this URL Specifying subprocesses and the switches to pass to them and GCC Command Options
If this help you, thats great.
I know this is not the answer you want to hear (since you specified otherwise in your question), but you are running into trouble here and are likely to run into more since your compiler is buggy. You should find a way of replacing it, since you'll find yourself writing even more work-around code the next time some obscure build system comes along. There's not only bjam out there.
Sorry I can't help you more. You might try simply writing a .lo file by hand (it's a two-liner, after all) and insert it into your LDFLAGS.
If it is a bug of GCC 4.3, did you try to build (by compiling from sources) and use a newer GCC. GCC 4.6.2 is coming right now. Did you consider using it?
I recently compiled GotoBLAS2 (MacOSX 10.6) and linked it to my code, leading to all kind of wrong results. I ran everything through valgrind noticing some illegal reads from the GotoBLAS. When looking at it more carefully I found that the GotoBLAS is compiled with the -m128bit-long-double alignment option. As soon as I did compile my code with this flag as well (although I don't use any long doubles at all) everything works, giving correct results without any valgrind obscurities.
Now my question ist:
Do I have to compile all other library dependencies using the same alignment flag?
I have a 32 bit machine and I am running Ubuntu 9.10 on it. I have the latest gcc compiler. The problem that I am facing is that I have a library developed in 2002. The code is correct for sure but when I try to built it, it gives me errors like iostream.h cannot be found, error: fstream.h: No such file or directory etc etc. There are lots of files hence I cannot change them.
Can these errors be solved if solved I install gcc 3.0 ? If yes how to install it over my existing gcc compiler.
You're dealing with a pre-standard C++ library, and you've seen it won't compile with a standard compiler. You can always try the quick work-around by creating, say, iostream.h with the two lines #include <iostream> and using namespace std;, and that may work. It isn't reliable, and may cause hard-to-find bugs that will appear at an inconvenient time.
If this is a library from somewhere else, you could see if it's been updated.
The thing to realize is that the code isn't correct anymore. It may have been correct for some implementation at some time, but it isn't now. (Are you sure it was originally for gcc 3.0? Pre-standard compilers were, well, not standard, and had a lot of oddities. Avoiding that is what standards are for.) If you do install the original system, you may be unable to interface with the library properly, and new code isn't going to work. A library that doesn't interface with modern code is of limited use.
Otherwise, you're going to have to abandon the attitude that you can't change the library, and convert it to standard C++. There will likely be quite a few bugs that are fairly easy to fix (like the scope in for (int i = 0;...)), and may be some subtler problems. The code may have been correct for a certain compiler, but it isn't now.
The fstream.h and similar files are pre-standard versions of the fstream and similar files specified by the C++ Standard that come with modern compilers. The two are not typically compatible. Frankly, if no-one has updated the library to comply with the standard in the last 8 years, it is unlikely to be worth using.
Why couldn't you write a script to search and replace all instances of
#include <iostream.h>
with
#include <iostream>
And the same for the others?
Update:
I agree with the other answer, and the comments below... I'll leave this answer though because I don't think the statement
There are lots of files hence I cannot
change them
is valid :)