Summary: | swig-1.3.21 has infinite include loop of limits.h on amd64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rutger Hendriks <loial> |
Component: | Current packages | Assignee: | AMD64 Project <amd64> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | jpalko, ladanyi, plasmaroo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The limits.h file that gets included originally
This file (wrongly?) includes /usr/include/limits.h again This is the solution proposed in the gentoo forums entry |
Description
Rutger Hendriks
2005-01-31 01:39:15 UTC
Created attachment 51101 [details]
The limits.h file that gets included originally
This file checks whether we're doing 32bit or 64bit and loads the appropriate
limits.h
Created attachment 51102 [details]
This file (wrongly?) includes /usr/include/limits.h again
From what I understand the problem lies in this file, it is included
automatically in /usr/include/limits.h when 64bit compilation is needed, but
almost at the end of the file there is this text:
<snip first 109 lines>
# endif /* ISO C99 */
# endif /* limits.h */
#endif /* GCC 2. */
#endif /* !_LIBC_LIMITS_H_ */
/* Get the compiler's limits.h, which defines almost all the ISO constants.
We put this #include_next outside the double inclusion check because
it should be possible to include this file more than once and still get
the definitions from gcc's header. */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines. */
# include_next <limits.h>
<snip the rest of the file, about 20 lines>
As you can see, the last line has #include_next <limits.h>
This causes the recursion, so I guess it is including the wrong file.
I have simply commented the #include_next <limits.h> line, and now swig installs nicely. I will try to install glibc and gcc again now, to see if it will stay okay. Will report back later. Here's me reporting back, after re-installing glibc and gcc, the problem of swig not compiling because of the infinite loop was there again. I guess we need glibc maintainer's to fix this. I'm wondering if I am the only one experiencing this... :'( This bug is 2005.0 profile specific. I recreated it on my -march=nocona box, and blubb has proved it on his amd64 2005.0. A simple testcase is: commodore64 ~ # more test.c #include <limits.h> int main(void) { } commodore64 ~ # gcc test.c commodore64 ~ # gcc -isystem /usr/include test.c (this is what swig does, I'm not sure why, or if this is valid...) Both compile cleanly on 2004.3 (non multilib includes) On 2005.0 (multilib includes) the recursion as seen by the reporter is observed and gcc bails with include nested too deeply. So "#include <limits.h>" in "/usr/include/gentoo-multilib/amd64/limits.h" can be commented and nothing will break? What would happen if I leave it commented? I had to comment it in order for swig-1.3.21 to be emerged and my reemerging of world to continue. I am currently doing emerge -eD world with new C[XX]FLAGS, LDFLAGS, and USE FLAGS. Hi, unfortunately this problem still exists. I just stumbled on it again, hence the "kick" :P i have this problem as well. was just coming to post a bug and saw this one. i just upgraded to 2005.0 profile, and while recompiling some things, noticed this one didn't work. you mention redoing glibc and gcc, is that needed or is it simply swig that is borked? In response to #8: I tried rebuilding glibc and gcc (actually, I rebuild system and world multiple times), but that didn't help. swig still had the loop thingie. As a small kick I just wanted to say that swig-1.3.21 still dus not compile for me. It still gives the "nested too deeply" error. Is there anything I can do? plasmaroo, looks like one for you ;) DON'T comment it out, as it will probably broke something which depends on glibc behaviour. Is not good to change behaviours of system libraries this way. Main problem is #include_next should re-include the same header, to fix this simply change #include <limits.h> to #include <gentoo-multilib/amd64/limits.h> and obviously i386 for 32-bit version. This will restore the original behaviour. I'm not sure how to fix it directly on glibc, but i think some glibc hacker should know how to render this natural language problem in some code :) I tried replaceing # include_next <limits.h> with # include_next <gentoo-multilib/amd64/limits.h> And it left me with this error instead of the infinite recursive error: In file included from /usr/include/gentoo-multilib/amd64/limits.h:124, from /usr/include/limits.h:7, from /usr/include/tcl.h:379, from libtcl8.c:284: /usr/include/gentoo-multilib/amd64/limits.h:124:48: gentoo-multilib/amd64/limits.h: No such file or directory libpl.c: In function `boot_swigrun': libpl.c:842: warning: unused variable `items' libpl.c: At top level: libpl.c:798: warning: 'swig_magic_readonly' defined but not used /bin/sh ../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -mtune=k8 -pipe -Wall -o libswigpl.la -rpath /usr/lib64 -no-undefined libswigpl_la-libpl.lo -ldl x86_64-pc-linux-gnu-gcc -shared .libs/libswigpl_la-libpl.o -ldl -mtune=k8 -Wl,-soname -Wl,libswigpl.so.0 -o .libs/libswigpl.so.0.0.0 (cd .libs && rm -f libswigpl.so.0 && ln -s libswigpl.so.0.0.0 libswigpl.so.0) (cd .libs && rm -f libswigpl.so && ln -s libswigpl.so.0.0.0 libswigpl.so) /bin/sh ../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -mtune=k8 -pipe -Wall -o libswigpy.la -rpath /usr/lib64 -no-undefined libswigpy_la-libpy.lo -ldl make[1]: *** [libswigtcl8_la-libtcl8.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... creating libswigpl.la (cd .libs && rm -f libswigpl.la && ln -s ../libswigpl.la libswigpl.la) x86_64-pc-linux-gnu-gcc -shared .libs/libswigpy_la-libpy.o -ldl -mtune=k8 -Wl,-soname -Wl,libswigpy.so.0 -o .libs/libswigpy.so.0.0.0 (cd .libs && rm -f libswigpy.so.0 && ln -s libswigpy.so.0.0.0 libswigpy.so.0) (cd .libs && rm -f libswigpy.so && ln -s libswigpy.so.0.0.0 libswigpy.so) creating libswigpy.la (cd .libs && rm -f libswigpy.la && ln -s ../libswigpy.la libswigpy.la) make[1]: Leaving directory `/home/tmp/portage/swig-1.3.21/work/SWIG-1.3.21/Runtime' make: *** [runtime] Error 2 !!! ERROR: dev-lang/swig-1.3.21 failed. !!! Function src_compile, Line 63, Exitcode 2 Here's my emerge info: Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r4 x86_64) ================================================================= System uname: 2.6.11-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 23 2005, 20:10:43)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=k8 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=k8 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ ftp://gentoo.risq.qc.ca/ ftp://gentoo.agsn.ca/ http://gentoo.mirrored.ca/ ftp://gentoo.mirrored.ca/ http://gentoo.osuosl.org/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 berkdb bitmap-fonts bonobo cdr crypt cups curl dbus divx4linux doc dvd dvdr eds esd fam flac font-server foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 gtkhtml guile imlib ipv6 java jp2 jpeg lzw lzw-tiff mozilla mp3 ncurses nls nocd nptl offensive oggvorbis opengl oss pam pcre perl png python qt readline samba scanner sdl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales xml xml2 xmms xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY I ran into this problem as well, limits.h behaviour messed up hal, fam, firefox, possibly more, but I found a work around before getting any further. My first fix, to get rid of the recursive add problem was the change the #ifdef and #define in /usr/include/gentoo-multilib/amd64/limits.h from _LIBC_LIMITS_H_ to _LIBC_LIMITS_AMD64_H_ My second fix is related to a hand full of packages making use of PATH_MAX, found in <linux/limits.h>. For some reason multilib is changing something that causes this file to not be included by some of the other includes.. somehow. To work around this, I added #include <linux/limits.h> to the top of /usr/include/limits.h (this an amd64 system). Adding the #include to the bottom of that file didn't seem to do the trick.. not sure why it makes a difference. I tried the suggestions in comment 14, and it failed with this error: from /usr/include/gentoo-multilib/amd64/limits.h:124, from /usr/include/limits.h:8, from /usr/include/tcl.h:379, from libtcl8.c:284: /usr/include/bits/../gentoo-multilib/amd64/bits/posix1_lim.h:153:28: #include nested too deeply x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../Source/Include -I/usr/lib/perl5/5.8.5/x86_64-linux/CORE -Dbool=char -Dexplicit=-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -mtune=k8 -pipe -Wall -MT libswigpl_la-libpl.lo -MD -MP -MF .deps/libswigpl_la-libpl.Tpo -c libpl.c -fPIC -DPIC -o .libs/libswigpl_la-libpl.o x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../Source/Include -DHAVE_CONFIG_H -I/usr/include/python2.3 -I/usr/lib/python2.3/config -O2 -mtune=k8 -pipe -Wall -MT libswigpy_la-libpy.lo -MD -MP -MF .deps/libswigpy_la-libpy.Tpo -c libpy.c -fPIC -DPIC -o .libs/libswigpy_la-libpy.o make[1]: *** [libswigtcl8_la-libtcl8.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... libpl.c: In function `boot_swigrun': libpl.c:842: warning: unused variable `items' libpl.c: At top level: libpl.c:798: warning: 'swig_magic_readonly' defined but not used make[1]: Leaving directory `/home/tmp/portage/swig-1.3.21/work/SWIG-1.3.21/Runtime' make: *** [runtime] Error 2 !!! ERROR: dev-lang/swig-1.3.21 failed. !!! Function src_compile, Line 63, Exitcode 2 I don't know if it matters, but the #ifndef & #define in my limits.h is: #ifndef _LIBC_LIMITS_AMD64_H_ #define _LIBC_LIMITS_AMD64_H_ 1 Could this be caused by some other combination of packages? IE: could the people who have had success with the work arounds post what version of glibc, gcc, etc they are using? http://forums.gentoo.org/viewtopic-t-306555-highlight-swig.html This forum topic has clean a solution. Do the maintainers of glibc on amd64 know about this problem? I encountered this problem as well. The fix from the forums mentioned in #16 worked for me. Since this seems to be a rather serious problem (being in glibc) can we get a devel to work on this? Created attachment 56159 [details]
This is the solution proposed in the gentoo forums entry
From the forum item a previous poster referred to, presented for your
convenience. This replacement text for /usr/include/limits.h seems to fix the
problem in an appropriate way. Other things than just swig *should* be
affected adversely by the problem.
Comment 16 did it for me as well. It seems to be a valid fix. Question being what are the repercussions of this fix going to be? GLIBC devs? Comment 16 fixed my system too. Nice, comment 16 instructions got my system to compile swig as well. Though I must admit that I too felt the instruction left me to think whether this will make this work for amd64, but how about others? This isn't a linux-headers issue, rather a multilib issue; reassigning to AMD64 team. I believe that this is related to bug 87560, which was recently fixed in multilib.eclass. Please try to re-emerge glibc and see if you can still reproduce this (I cannot here). Hi, bug reporter here I have just reinstalled glibc and now swig-1.3.21 merged without problems. I did not try the other solutions mentioned because I thought they were fighting symptoms not solving the problem. So this reinstalling glibc solution seems to be the valid one. Should I mark it fixed? Thanks Thanks for confirming that Rutger. *** This bug has been marked as a duplicate of 87560 *** |