https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #20 from Greg Chandler <chandleg at wizardsworks dot org> ---
After a marathon of table-flipping and much ado, I was able to get all the
dependcies I needed for gdb to work. So that was the good news..
The bad news is that with gdb I am still staring at this process wait...
I took a very long walk and was thinking about a patch I wrote for the IRIX
kernel and supporting libraries back in '99. There were two sections of
distinct runtime. Multiprocessor and Uniproccessor.. If you ran
multiprocessor code on a uniprocessor machine say like a r4400
(Indy/Indigo/etc) you ended up with a spin lock waiting for a thread that you
would never get because the system wasn't using proper threads. As big as a
headache as that was I didn't really remember it until now.
So... I figured you know what? Lets enable threads on my cross-compiler,
because I need libgcrypt anyway....
So I did..... And a LOT of things happened all at once.. Firstly I no longer
get a not supported issue with stack-protector... Secondly the
fstack-protector messages no longer show up... Which leads me to beleive that
there is a very specific depenency on threads that may not be being checked as
well as it should at configure time.
This yields a working gcc that I was able to compile libgcrypt with (had not
been able to before because of a lack of thread local storage) and that was
really nice.
What it also yeilded was a broken g++:
For this program:
int main ()
{
}
root@constellation:/tmp# gcc 2.cpp
root@constellation:/tmp# file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, with debug_info, not stripped
root@constellation:/tmp# rm a.out
root@constellation:/tmp# alpha-linux-gnu-gcc 2.cpp
root@constellation:/tmp# file a.out
a.out: ELF 64-bit LSB pie executable, Alpha (unofficial), version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, with debug_info, not
stripped
root@constellation:/tmp# rm a.out
root@constellation:/tmp# alpha-linux-gnu-g++ 2.cpp
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/bin/ld:
a.out: hidden symbol `_Unwind_GetLanguageSpecificData' in
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/libgcc.a(unwind-dw2.o) is
referenced by DSO
/opt/tools/bin/../lib/gcc/alpha-linux-gnu/14.2.0/../../../../alpha-linux-gnu/bin/ld:
final link failed: bad value
collect2: error: ld returned 1 exit status
So, I need to go back and take a closer look at that now, I also enabled
libatomic, libgomp, libquadmath, libssp, and libvtv because I did not notice
the broken g++ right away, so I need to figure out which or which combination
of those and threads broke it.
I have a very bad hunch that once I get this sorted out, the thread support is
going to fix the problem I've been seeing with the native compiler I've been
trying to build, and I am not looking forward to troubleshooting that mess.
