gdb-8.2.1 build failed on macos 10.11.6

Jiri Gaisler jiri at gaisler.se
Mon Jun 17 07:48:26 UTC 2019


I don't know if it is of any help, but I managed to build gdb-8.2.1 on
MacOSX 10.10 using gcc-9. The trick was to install gcc with 'brew
install gcc', and then configure and compile with CC=gcc-9 and CXX=g++-9
. I'm doing this in a KVM virtual machine, but I don't think it matters.
The resulting gdb binary worked fine. I am now trying to build the whole
tool-chain with RSB ...


brew install gcc

export CC=gcc-9

export CXX=g++-9

../gdb-8.2.1/configure --target=sparc-rtems

make -j2

Jiri.

On 6/17/19 7:30 AM, Chris Johns wrote:
> On 17/6/19 5:31 am, Juan Rafael García Blanco wrote:
>> Hi,
>>
>> I have installed macOS 10.9.5, for which Xcode includes the following compiler:
>> Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
>> Target: x86_64-apple-darwin13.4.0
>> Thread model: posix
>>
>> Compilation of gdb 8.2 fails also with this setup, although the error seems to be caused by the compiler itself. Please find below the error log:
>>   CXX    cli/cli-script.o
>> Stack dump:
>> 0.      Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-fr\
>> ee -disable-llvm-verifier -main-file-name cli-script.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version \
>> 241.9 -gdwarf-2 -coverage-file /Users/juanrgar/Projects/rtems/src/rsb/rtems/build/sparc-rtems5-gdb-8.2.1-x86_64-apple-darwin13.4.0-1/build/gdb/cli/cli-script.o -resource-dir /Appli\
>> cations/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -dependency-file cli/.deps/cli-script.Tpo -MP -MT cli/cli-script.o -D LOCALEDIR="/\
>> Users/juanrgar/Projects/rtems/rtems/5/share/locale" -D HAVE_CONFIG_H -D TUI=1 -I /Users/juanrgar/Projects/rtems/src/rsb/rtems/build/tmp/sb-juanrgar/5/rtems-sparc/Users/juanrgar/Pro\
>> jects/rtems/rtems/5/include -I . -I ../../gdb-8.2.1/gdb -I ../../gdb-8.2.1/gdb/common -I ../../gdb-8.2.1/gdb/config -I ../../gdb-8.2.1/gdb/../include/opcode -I ../../gdb-8.2.1/gdb/\
>> ../opcodes/.. -I ../../gdb-8.2.1/gdb/../readline/.. -I ../../gdb-8.2.1/gdb/../zlib -I ../bfd -I ../../gdb-8.2.1/gdb/../bfd -I ../../gdb-8.2.1/gdb/../include -I ../libdecnumber -I .\
>> ./../gdb-8.2.1/gdb/../libdecnumber -I ../../gdb-8.2.1/gdb/gnulib/import -I build-gnulib/import -I /Users/juanrgar/Projects/rtems/src/rsb/rtems/build/tmp/sb-juanrgar/5/rtems-sparc/U\
>> sers/juanrgar/Projects/rtems/rtems/5/include -I /opt/local/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m -I /opt/local/Library/Frameworks/Python.framework/Ver\
>> sions/3.7/include/python3.7m -stdlib=libc++ -O2 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wno-sign-compare -\
>> Wno-narrowing -Wno-mismatched-tags -Wno-error=deprecated-register -Wformat-nonliteral -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir /Users/juanrgar/Projects/rtems/src/rsb\
>> /rtems/build/sparc-rtems5-gdb-8.2.1-x86_64-apple-darwin13.4.0-1/build/gdb -fbracket-depth 1024 -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc\
>> -runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o cli/cli-script.o -x c++ ../../gd\
>> b-8.2.1/gdb/cli/cli-script.c
>> 1.      <eof> parser at end of file
>> 2.      Per-module optimization passes
>> 3.      Running pass 'CallGraph Pass Manager' on module '../../gdb-8.2.1/gdb/cli/cli-script.c'.
>> 4.      Running pass 'SROA' on function '@_Z16get_command_line20command_control_typePKc'
>>   CXX    cli/cli-setshow.o
>> clang: error: unable to execute command: Segmentation fault: 11
>> clang: error: clang frontend command failed due to signal (use -v to see invocation)
> That is not nice. I have raised issues like this with Apple in the past which
> they have fixed but given the age of these tools I do not think they will fix them.
>
> I am not sure how we handle these older versions of MacOS with gdb now being
> written in C++. Any suggestions?
>
> (I think gdb being written in C++ is a good thing and I support the change)
>
> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users



More information about the users mailing list