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@rtems.org > http://lists.rtems.org/mailman/listinfo/users _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
