i'm trying to resurrect an old installation of Gentoo Linux that has kernel 2.6.32 and i could update #system with an exception: gcc 4.5.4 failed installation.
The last lines are here:
http://pastebin.com/8s4z0FJy
Ask me if you need more info, i'll post something more when i get home (Got that info through SSH).
Even GHC fails compiling but i'll handle that later. I need GCC in order to compile the other packages.
Thanks in advance
To respond to a link with another link from googling: https://forums.gentoo.org/viewtopic-t-896518-start-0.html. Let me summarize that thread:
{standard input}: Assembler messages:
{standard input}:87553: Warning: end of file not at end of a line; newline inserted
{standard input}:88534: Error: unknown pseudo-op: `.l38'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
xgcc: Internal error: Killed (program cc1)
Basically, the assembly errors come because gcc’s assembly output was interrupted when it was killed. The Gentoo forums thread suggests this may likely be because gcc used up too much memory. You can confirm this by checking near the end of dmesg’s output for OOM stuff. If memory is not the issue, then you might have a real bug and should follow the instructions in the text you pastebined for reporting the bug to https://bugs.gentoo.org/. But, please try seeing if memory is the issue first.
If memory is the issue, make sure that you have swap partitions on your machine and that they are enabled. You can view a summary of your enabled swap partitions by running swapon -s. If nothing shows up and you cannot repartition, you can always use a trick like # ( umask 0077 && dd if=/dev/zero of=/.swap.img bs=1M count=1024 && mkswap /.swap.img && swapon /.swap.img ) (the ‘#’ indicates a root shell prompt, so don’t actually type it). The forum thread also suggests that removing -pipe, which causes gcc to use more memory instead of writing out lots of temporary files, from CFLAGS and CXXFLAGS (by editing /etc/make.conf or /etc/portage/make.conf, whichever exists). We cannot tell what your CFLAGS are from what you posted.
Related
I'm trying to build the Contiki OS for a custom platform (based on the EZR32LG MCU) with GCC compiler.
When I make the project it runs with a few warnings about '#pragma GCC diagnostic'. (I don't know if this is relevant, but I'm just providing the information to be complete)
After a few warnings, the compilation stops and returns:
/tmp/ccY4OiVd.s: Assembler messages:
/tmp/ccY4OiVd.s:37: Error: garbage following instruction -- `dsb 0xF'
/tmp/ccY4OiVd.s:51: Error: garbage following instruction -- `dsb 0xF'
make: *** [obj_slwstk6201a/watchdog.o] Error 1
I looked at the dsb instruction, but I'm not finding much except that this ensures that all explicit data memory transfer before the DSB are complete before any instruction after the DSB is executed.
Googling the error did not return many results, the only thing I found was that maybe my binutils version is outdated. I checked with ld --version, which returns 2.24. The latest release is 2.28, but I can't find a way to update the GCC version to use binutils 2.28.
So I downloaded GCC -v6, but the ld -v command still returns 2.24.
I'm not sure if this would resolve the error, or I'm completely wrong about the origin of the error..
I have a problem linking my C application statically. All libraries exist (.a) and just a month ago I was able to static link my application without an error. But as soon as I activate the static linking option in eclipse, I can compile without an error but when I try to run it, I receive an "Segmentation Error" and it stops.
I tried to debug and that is what eclipse is showing me:
No source available for "_start() at 0x4017f7"
No source available for "__libc_start_main() at 0x522389"
No source available for "__libc_csu_init() at 0x5228f7"
No source available for "frame_dummy() at 0x4018bd"
No source available for "__register_frame_info_bases() at 0x52194b"
No source available for "0x0"
I use the following libraries: -lgcrypt -lgpg-error -lmxml -lpthread -lrt. Any ideas what the problem could be? I can also post the gdb traces, but its long.
Linker command:
Invoking: Invoking: GCC C Linker
gcc -static -o "X - Client" ./src/lib/stopwatch-0.2/stopwatch.o ./src/lib/rscode-1.3/berlekamp.o ./src/lib/rscode-1.3/crcgen.o ./src/lib/rscode-1.3/galois.o ./src/lib/rscode-1.3/rs.o ./src/lib/Salsa20/ecrypt.o ./src/lib/helper-Client.o ./src/PoR-Client.o -lgcrypt -lgpg-error -lmxml -lpthread -lrt
Finished building target: X - Client
This is probably not a problem with the linking. You probably have a problem with reading uninitialized memory, or reading and writing past the end of an array.
What happens in such cases is that on one build the memory you are reading just happens to be set to a non-crashing value ( e.g. you read past the end of an array into an area that has zeroes ), but then in another build the data structures are in a different order and now you are reading from something with unexpected values.
Or you could in one build be writing past the end into a data structure that you don't need any more, and this build, the thing past the end of the array is critical.
Also check if your program runs differently on debug vs. optimized builds. Optimization changes the layout, padding and initialization of data structures. ( e.g. debug builds will for example typically zero all memory, and stack frames are padded out with debugging data ).
I strongly suggest you run your program through a tool like valgrind. It will find these kinds of problems for you.
I am trying to compile phpcompiler from source using this configure command.
./configure --prefix=/opt/phc-0.3.0.1/ --with-php=/opt/php-5.3.17/
The configure error was,
checking for exit in -lboost_regex-mt... no
checking for exit in -lboost_regex-mt... (cached) no
checking for exit in -lboost_regex... no
checking for exit in -lboost_regex... (cached) no
checking for exit in -lboost_regex... (cached) no
configure: error: Could not link against boost_regex
Thats completely wrong as I have both boost and boost_regex packages installed. Both libs and header files. Then I dug this in the config.log file
configure:17053: g++ -o conftest -g -O2 -L/lib/php5 -L/usr/lib/php5 conftest.cpp /usr/lib/libCrun.so.1 -lphp5 -L/opt/php-5.3.17//lib -R/opt/php-5.3.17//lib -ldl >&5
g++-4.6.real: error: /usr/lib/libCrun.so.1: No such file or directory
g++-4.6.real: error: unrecognized option '-R'
So, for this unrecognized option '-R' error, many -lboost_regex checks were failed!
How can I fix this? is there any file that I can edit to fix it? And why -R is used? I think it would be -L flag.
As your comment indicates that this -R option comes from configure, the following line in m4/php-embed.m4 appears to be the most likely source:
LIBS="-lphp5 -L${PHP_INSTALL_PATH}/lib -R${PHP_INSTALL_PATH}/lib $LIBS"
If you look at configure, all other occurrences of -R will write that as ${wl}-R, where ${wl} will most likely expand to -Wl,. So one way to fix this would be adding the ${wl} before -R in the above line and running autogen.sh to recreate configure.
You may whish to file a bug for this, after checking existing ones.
You can see a similar error (and resolution) in Git 2.23 (Q2 2019) where -R has been removed.
The way of specifying the path to find dynamic libraries at runtime
has been simplified.
The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses.
See commit 0f50c8e (17 May 2019) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 51d6c0f, 13 Jun 2019)
Makefile: remove the NO_R_TO_GCC_LINKER flag
Change our default CC_LD_DYNPATH invocation to something GCC likes
these days.
Since the GCC 4.6 release unknown flags haven't been passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set.
Our use of "-R" dates back to 455a7f3 ("More portability.",
2005-09-30, Git v0.99.8a).
Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27, Git v1.5.0-rc1) the NO_R_TO_GCC flag was added, allowing optional use of "-Wl,-rpath=".
Then in f5b904d ("Makefile: Allow CC_LD_DYNPATH to be overriden",
2008-08-16, Git v1.6.1-rc1) the ability to override this flag to something else
entirely was added, as some linkers use neither "-Wl,-rpath," nor "-R".
From what I can tell we should, with the benefit of hindsight, have
made this change back in 2006.
GCC & ld supported this type of invocation back then, or since at least binutils-gdb.git's.
a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20).
Further reading and prior art can be found at:
tsuna/boost.m4 issue 15
Gnome issue 641416
Building cURL passing the -R option to linker
Making a plain "-R" an error seems from reading those reports to have been
introduced in GCC 4.6 released on March 25, 2011, but I couldn't
confirm this with absolute certainty, its release notes are ambiguous
on the subject, and I couldn't be bothered to try to build & bisect it
against GCC 4.5.
I'm having some problems with a program causing a segmentation fault when run on a Mac. I'm putting together an entry for the IOCCC, which means the following things are true about my program:
It's a very small C program in a single file called prog.c
I won't post it here, because it won't help (and would probably render the contest entry invalid)
It compiles cleanly under gcc using "cc -o prog prog.c -Wall"
Despite (or, more accurately, because of) the fact it contains a bunch of really bizarre uses of C, it has been constructed extremely carefully. I don't know of any part of it which is careless with memory (which is not to say that there can't possibly be bugs, just that if there are they're not likely to be obvious ones)
I'm primarily a Windows user, but several years ago I successfully compiled and ran it on several windows machines, a couple of Macs and a Linux box, with no problems. The code hasn't changed since then, but I no longer have access to those machines.
I don't have a Linux machine to re-test on, but as one final test, I tried compiling and running it on a MacBook Pro - Mac OSX 10.6.7, Xcode 4.2 (i.e. GCC 4.2.1). Again, it compiles cleanly from the command line. It seems that on a Mac typing "prog" won't make the compiled program run, but "open prog" seems to. Nothing happens for about 10 seconds (my program takes about a minute to run when it's successful), but then it just says "Segmentation fault", and ends.
Here is what I've tried, to track down the problem, using answers mostly gleaned from this useful StackOverflow thread:
On Windows, peppered the code with _ASSERTE(_CrtCheckMemory()); - The code ran dog-slow, but ran successfully. None of the asserts fired (they do when I deliberately add horrible code to ensure that _CrtCheckMemory and _ASSERTE are working as expected, but not otherwise)
On the Mac, I tried Mudflap. I tried to build the code using variations of "g++ -fmudflap -fstack-protector-all -lmudflap -Wall -o prog prog.c", which just produces the error "cc1plus: error: mf-runtime.h: No such file or directory". Googling the matter didn't bring up anything conclusive, but there does seem to be a feeling that Mudflap just doesn't work on Macs.
Also on the Mac, I tried Valgrind. I installed and built it, and built my code using "cc -o prog -g -O0 prog.c". Running Valgrind with the command "valgrind --leak-check=yes prog" produces the error "valgrind: prog: command not found". Remembering you have you "open" an exectable on a Mac I tried "valgrind --leak-check=yes open prog", which appears to run the program, and also runs Valgrind, which finds no problems. However, Valgrind is failing to find problems for me even when I run it with programs which are designed specifically to make it trigger error messages. I this also broken on Macs?
I tried running the program in Xcode, with all the Diagnostics checkboxes ticked in the Product->Edit Scheme... menu, and with a symbolic breakpoint set in malloc_error_break. The breakpoint doesn't get hit, the code stops with a callstack containing one thing ("dlopen"), and the only thing of note that shows up in the output window is the following:
Warning: Unable to restore previously selected frame.
No memory available to program now: unsafe to call malloc
I'm out of ideas. I'm trying to get Cygwin set up (it's taking hours though) to see if any of the tools will work that way, but if that fails then I'm at a loss. Surely there must be SOME tools which are capable of tracking down the causes of Segmentation faults on a Mac?
For the more modern lldb flavor
$ lldb --file /path/to/program
...
(lldb) r
Process 89510 launched
...
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x726f00)
* frame #0: 0x00007fff73856e52 libsystem_platform.dylib`_platform_strlen + 18
...
Have you compiled with -g and run it inside gdb? Once the app crashes, you can get a backtrace with bt that should show you where the crash occurs
In many cases, macOS stores the recent program crash logs under ~/Library/Logs/DiagnosticReports/ folder.
Usually I will try the following steps when doing troubleshooting on macOS:
Clean the existing crash logs under the ~/Library/Logs/DiagnosticReports/
Run the program again to reproduce the issue
Wait for a few seconds, the crash log will appear under the folder. The crash log is named like {your_program}_{crashing_date}_{id}_{your_host}.crash
Open the crash log with your text editor, search for the keyword Crashed to locate the thread causing the crash. It will show you the stack trace during crash, and in many cases, the exact line of source code causing the crash will be recorded as well.
Some links:
[1] https://mac-optimization.bestreviews.net/analyze-mac-crash-reports/
I am using Eclipse to develop and remotely debug some software for an ARM Processor. Unfortunately the software I am writing is multi-threaded and I am unable to debug it. If I place a break-point in the thread code, i get the following message:
Child terminated with signal = 5
Child terminated with signal = 0x5
GDBserver exiting
After doing quite a bit of Googling, I found a "solution" that proposed using this:
strip --strip-debug libpthread.so.0
Unfortunately, I still get the termination errors.
I would really appreciate your help in getting this figured out!
Thanks!
First, this (and subsequent) error(s):
cc1.exe: error: unrecognized command line option "-fstrip-debug"
is caused by adding strip --strip-debug etc. to the GCC command line. That is obviously bogus thing to do, and not at all what your googling suggested. (You might want to clean up your question to remove references to these errors; they have nothing to do with your problem.)
What it did (or should have) suggested, is using strip --strip-debug libpthread.so.0 instead of using strip libpthread.so.0.
This is because GDB can not work with threads if your libpthread.so.0 is fully stripped.
It can be stripped of debug symbols (which is what strip --strip-debug libpthread.so.0 does), but stripping it of all symbols (which is what strip libpthread.so.0 does) is a bad idea(TM).
Since you are (apparently) not yourself building libpthread.so.0, you shouldn't need to strip it either.
You should however verify that the provider of your toolchain did not screw it up. The following command should not report no symbols, and should in fact print a matching nptl_version (as a defined symbol):
nm /path/to/target/libpthread.so.0 | grep nptl_version
Assuming all is well so far, we can now diagnose your problem, except ... you didn't provide sufficient info ;-( In particular, when you run GDB, it should print something like using /path/to/libthread_db.so.0. You might have to hunt for GDB console in Eclipse, or you might want to run GDB from command line, so you see exactly what it prints.
It is crucial that the version of libthread_db.so.0 (for host) matches the version of lipthread.so.0 (for target). They should both be provided by your toolchain vendor.
Your problem is most likely that either GDB can't find libthread_db.so.0 at all, or that it finds the wrong one.