Vincent Forbes <vwfst55@xxxxxxxxx> writes: > I am trying to finalize a cross compiler build for the ARM > preprocessor. When doing the test suites, pthread_cancel() causes a > SIBABRT and the error describes that pthread_cancel requires > libgcc_s.so.1 to work. The libgcc_eh.a and libgcc_s.so.1 libraries > are not included in the target system to allow more room for storage > in an embedded system. Note that you certainly don't need libgcc_eh.a on the target system, unless you expect to be able to run the compiler itself on the system. > In order to allow for additional programs when > needed, the C++ compiler is being included. The unwind library that > the C++ compiler needs for exception handling is causing the thread > cancel function to abort. Would passing --disable-threads prevent the > unwind library from causing the SIGABRT and would threads still work > in the target? > > One thing that does concern me is that even if --disable-threads is > the solution, there would still unwind issues. Configuring gcc with --disable-threads will cause the runtime libraries to handle exceptions in a way which is unsafe if threads are in fact used. So if you use --disable-thread, and you write programs which use threads, you had better make sure that those programs do not throw exceptions. An alternative approach which you should consider is configuring with --disable-shared, or perhaps simply --disable-shared=libgcc. Then libgcc will not be built shared, and will instead be statically linked into programs as needed. This should work correctly if your programs don't use shared libraries. It should work correctly even with shared libraries if you are using a sufficiently new version of the GNU linker and you are using a libc which implements dl_iterate_phdr. Ian
