Sources Bugzilla – Bug 398
elf/dl-runtime.c not resolving CFI_STARTPROC
Last modified: 2006-02-23 22:36:42 UTC
Configure command: # CFLAGS="-g -O3" ../configure --prefix=/usr --enable-add-ons=libidn,linuxthreads --without-cvs s390-slackware-linux # gcc -v Reading specs from /usr/lib/gcc-lib/s390-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=s390-slackware-linux --host=s390-slackware-linux Thread model: posix gcc version 3.3.4 # ld -v GNU ld version 2.15.90.0.3 20040415 # /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.4. Compiled on a Linux 2.4.26 system on 2004-09-09. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bugs@gnu.org>. I am trying to compile glibc-2.3.3-200408040157 on Linux/390. When I do, I get a compilation error in elf/dl-runtime.c, as follows: dl-runtime.c:222: error: parse error before "CFI_STARTPROC" I was able to get it to compile by adding #include <sysdeps.h> to the source, but I would have thought that was already being included somewhere by something or other. Examining the output from --save-temps shows that it is not. When I add in the include, I can then see all these other includes happening: # 27 "dl-runtime.c" 2 # 1 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h" 1 # 23 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h" # 1 "../sysdeps/s390/s390-32/sysdep.h" 1 # 21 "../sysdeps/s390/s390-32/sysdep.h" # 1 "../sysdeps/generic/sysdep.h" 1 # 22 "../sysdeps/s390/s390-32/sysdep.h" 2 # 24 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h" 2 and the compile completes fine. I have no idea why I would be the first one to encounter this, since the code is over 6 months old, but apparently the problem doesn't show up on Intel.
*** This bug has been marked as a duplicate of 333 ***
I just read Bug # 333. I particularly liked the comment "Reports about build issues of any kind do not belong in bugzilla." Just what the devil is bugzilla for, then? An exercise in futility? I also thought that "If you have bona fide issues and fixes for them, we welcome your direct participation in glibc development by using the public development mailing lists. Any bona fide build issue is a platform-specific problem on a platform whose maintainer has not updated the code recently, or whose build environment does not have the same problems you encountered." was particularly self-serving. Since I am the platform maintainer, where does that leave me? As a distribution maintainer, I expect people to take bug reports via their preferred bug reporting mechanism and _fix_ them, not tell the bug reporter that they were an idiot for using the bug reporting mechanism. If you don't want bug reports, why don't you just shut down the bugzilla page?
We will not fix bugs for you. Every build failure you have is your own fault. Bugzilla is for code bugs and not your inability to build binaries. *** This bug has been marked as a duplicate of 333 ***
Well, let's see. I've been building glibc for 4 years now, with few problems. The problems I had were S/390-specific CODE BUGS, not my "inability to build binaries." I know that this is also a CODE BUG because changing the BUGGY CODE allows it to build properly and work. (Sensing any kind of theme here?) You don't want to debug people's bad build environments for them. That's fine, and I can understand it. I don't want debug a developer's BUGGY CODE for them. Hopefully you can understand that. Based on your total unwillingness to admit that there could ever be a code bug, I have my doubts you ever can understand that. I don't have a bad build environment. Can we all say that together? I don't have a bad build environment. It builds all sorts of glibc binaries just fine. But not 2.3.3--200408040157 on Linux/390, unless I add one stinking #include to the BUGGY CODE.
So why are you trying to build that old snapshot? We build CVS glibc on s390 every few days, last known to work glibc on s390 is CVS snapshot from this morning. Bugs in old snapshots certainly can't be retroactively fixed, it would be fixed in current CVS. But current CVS is known to work. *** This bug has been marked as a duplicate of 333 ***
Because later versions break when including TLS support, and we want/need that. I tried a current CVS pull from 12:00 ET, and indeed, when trying to build dl-reloc, I get this error: dl-reloc.c: In function `_dl_allocate_static_tls': dl-reloc.c:66: error: invalid application of `sizeof' to an incomplete type dl-reloc.c: In function `_dl_nothread_init_static_tls': dl-reloc.c:109: error: syntax error before "__self" dl-reloc.c:109: error: `__self' undeclared (first use in this function) dl-reloc.c:109: error: (Each undeclared identifier is reported only once dl-reloc.c:109: error: for each function it appears in.) I was pleased to note that dl-runtime compiled with this version, but cannot live with the TLS breakage. (Since I made zero changes in my system between these two build attempts, I am now 100% convinced the dl-runtime problem is not in my build environment). What version of the kernel headers are you using on your build machine? Are they Red Hat modified headers, or stock from kernel.org? We're using 2.4.27 at the moment, since that is what is current from kernel.org. The README file says that 2.x is supported on Linux for S/390, so I'm hoping that isn't an issue. I know you can't retroactively fix CVS snapshots. I'm just trying to find the minimum patch necessary to get this thing to build so we can ship it. To be 100% honest, if you tell me that inserting the #include is an acceptable workaround, I'll take that as sufficient and run with it. I just cannot make that assessment by myself.
I've now got a hint as to why the difference between the two versions. On the CVS from 08/04, HAVE_TLS_SUPPORT is not being defined. On the CVS from 09/26, it is. This means that the "# include <sysdep.h>" is not being pulled in, causing the failure. Now I just need to see why isn't being defined for the 08/04 CVS. In case anyone is wondering, I'm doing this so that they next poor slob that comes along (if any do) won't have to deal with this issue.
And, the answer to that question is right here: 2004-08-27 Roland McGrath <roland@redhat.com> * configure.in (usetls): Default to yes. I'm not in the process of re-compiling the 08/04 CVS with an explicit --with-tls in the ./configure statement.
And, that brings us back to the previous problem of getting this error: dl-reloc.c: In function `_dl_allocate_static_tls': dl-reloc.c:66: error: invalid application of `sizeof' to an incomplete type dl-reloc.c: In function `_dl_nothread_init_static_tls': dl-reloc.c:109: error: syntax error before "__self" dl-reloc.c:109: error: `__self' undeclared (first use in this function) dl-reloc.c:109: error: (Each undeclared identifier is reported only once dl-reloc.c:109: error: for each function it appears in.) Looks like I'll be spending more time on debugging this.
Note that I understand why my past built on S390 was failed: http://sources.redhat.com/ml/libc-alpha/2004-07/msg00023.html I think S390 cannot be built with --without-tls, without my patch. In addition, this patch is sane, because CFI directive is defined in sysdep.h.
I agree. Using --without-tls on a 2.4.x system requires an additional #include <sysdep.h> somewhere, or have it moved outside the #ifdef HAVE_TLS_SUPPORT clause in linuxthreads/sysdeps/s390/tls.h. Trying to build glibc --with-tls on a 2.4.x system appears to be very broken, to say the least.
I think I like this patch better. It has a couple of advantages. It only hits one file instead of two, but still catches both 31 and 64 bit platforms. Both Debian and Slack/390 already have a patch against that file. If there is some reason why it is only included when __ASSEMBLER__ is not defined, then this preserves that. --- tls.h.orig 2003-01-30 13:34:11.000000000 -0500 +++ tls.h 2004-09-27 18:19:18.000000000 -0400 @@ -122,6 +122,8 @@ #else /* HAVE_TLS_SUPPORT && (FLOATING_STACKS || !IS_IN_libpthread) */ # ifndef __ASSEMBLER__ +/* Get system call information. */ +# include <sysdep.h> /* Get the thread descriptor definition. */ # include <linuxthreads/descr.h> What do you think?
Hmph. I should have done a better job with the diff headers. This is against linuxthreads/sysdeps/s390/tls.h
(In reply to comment #13) > Hmph. I should have done a better job with the diff headers. This is against > linuxthreads/sysdeps/s390/tls.h > So just for formality's sake (don't ask me why ... it's a REALLY long story, but this patch is needed elsewhere), I am reposting your patch with the proper headers on it. Thanks for the patch in the first place, Mark. --- linuxthreads/sysdeps/s390/tls.h.orig 2003-01-30 13:34:11.000000000 -0500 +++ linuxthreads/sysdeps/s390/tls.h 2004-09-27 18:19:18.000000000 -0400 @@ -122,6 +122,8 @@ #else /* HAVE_TLS_SUPPORT && (FLOATING_STACKS || !IS_IN_libpthread) */ # ifndef __ASSEMBLER__ +/* Get system call information. */ +# include <sysdep.h> /* Get the thread descriptor definition
Support for LinuxThreads is gone.
> http://sources.redhat.com/ml/libc-alpha/2004-07/msg00023.html so this is still broken on the glibc-2.3 branch ... i guess the verdict here is that it'll never be fixed in 2.3 ? i know this doesnt carry much wait with the glibc maintainers, but we've hit this bug in the Gentoo/s390 port ... glibc head does not suffer from this problem as the dl-machine.h files have been reworked since and the relevant code no longer exists ...
Subject: Bug 398 CVSROOT: /cvs/glibc Module name: libc Branch: glibc-2_3-branch Changes by: roland@sources.redhat.com 2006-02-23 22:36:51 Modified files: sysdeps/s390/s390-64: dl-machine.h sysdeps/s390/s390-32: dl-machine.h Log message: 2004-07-10 GOTO Masanori <gotom@debian.or.jp> [BZ #398] * sysdeps/s390/s390-32/dl-machine.h: Include <sysdep.h> for CFI directive. * sysdeps/s390/s390-64/dl-machine.h: Likewise. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/s390/s390-64/dl-machine.h.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.19.4.1&r2=1.19.4.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/s390/s390-32/dl-machine.h.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.20.4.1&r2=1.20.4.2