[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-20 19:15 --- ok, I'm closing. Please reopen if it is still a problem. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #7 from sgilbertson at gcc dot gnu dot org 2006-09-20 18:45 --- I checked out revision 117082 (trunk) and successfully built a few static binaries with it. So unless Thomas saw a different problem than I did, I'd say it's fixed. Configured with: ../gcc/configure --prefix=/var/local/gcc/tip_20060920 --mandir=/var/local/gcc/man --infodir=/var/local/gcc/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --enable-java-awt=xlib --enable-libgcj --enable-languages=c,c++,java --with-system-zlib --enable-__cxa_atexit Thread model: posix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-14 23:19 --- I think the PR 13212 fix probably fixed this on svn trunk. Can one of you try that? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-14 23:19:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #5 from sgilbertson at gcc dot gnu dot org 2006-08-18 15:33 --- The "ugly workaround" (which works great for my static builds!) patches a previous workaround: http://gcc.gnu.org/ml/java-patches/2006-q1/msg00181.html So this issue is related to #13212,which is assigned to Bryce: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Maybe we want to note that 13212 blocks 28760, but in any event the longer term solution for 28760 seems to be making sure that the non-workaround solution to 13212 works for static builds. For a shorter-term solution, I wonder if a configure option could turn off GC_PTHREAD_SYM_VERSION. -- sgilbertson at gcc dot gnu dot org changed: What|Removed |Added CC||sgilbertson at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #4 from aeby at graeff dot com 2006-08-17 19:43 --- A bug tracker is not the right place to discuss philosophy questions, so if you'd like to continue the discussion, we should move over to e-mail or the gcj mailing list (lookout for subject: "GCJ 4.1.1 and static linking - SEGV"). However, my answer to your (Andrew) question is: - for portability: The binary I am building statically is supposed to work out-of-the-box on as many machines as ever possible - for stability: Some systems out there are known to have deficiencies, i.e. Debian/woody came with a not completely thread-safe glibc, so linking glibc statically solves these issues, too - for reproducibility: ask users that complain about issues in your software to try out the statically built version and if the problem stops you know you've found another combination of library versions your software does not work well with (or you can confirm that your software, not the runtime environment has a bug in the other case) > It will almost not work for other cases. I cannot confirm this. The project I'm trying to build statically with 4.1.1 is built statically for years with earlier gcc versions with less problems than the dynamic builds had ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #3 from daney at gcc dot gnu dot org 2006-08-17 16:18 --- (In reply to comment #2) > Why are you trying to static link java code? It will almost not work for > other > cases. > We have 7.5X10^6 lines of code in about 800 classes that run fine statically linked. So it does in fact work. As to why, the answer is startup time and code size. We probably should fix this at some point, but until we do, I guess either do not statically link libc or use your work around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-17 15:12 --- Why are you trying to static link java code? It will almost not work for other cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #1 from aeby at graeff dot com 2006-08-17 11:50 --- Created an attachment (id=12087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12087&action=view) Ugly workaround GC_PTHREAD_CREATE_NAME segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
