83770 2005-03-01 21:23 0000 Mono-1.1.4 fails without USE="nptl" on amd64 2005-05-08 06:54:34 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified AMD64 Linux RESOLVED FIXED P2 normal --- 1 travitc@gmail.com dotnet@gentoo.org battousai@gentoo.org bcs26@cornell.edu matt@use.net travitc@gmail.com 2005-03-01 21:23:43 0000 Without USE="nptl" the build fails most of the way through as follows: make[8]: Entering directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs/class/System' MONO_PATH="../../class/lib/basic:$MONO_PATH" /var/tmp/portage/mono-1.1.4/work/mono-1.1.4/runtime/mono-wrapper ../../class/lib/basic/mcs.exe -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig /r:mscorlib.dll /define:XML_DEP /r:System.Xml.dll /target:library /out:System.dll @System.dll.sources System.Net.Configuration/DefaultProxyHandler.cs(60) warning CS0219: The variable 'deflt' is assigned but its value is never used System.Net/IPEndPoint.cs(122) warning CS0219: The variable 'unknown' is assigned but its value is never used System.Net.Sockets/Socket.cs(1171) warning CS0219: The variable 'opt_value_len' is assigned but its value is never used Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in <0x0000f> (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) in <0x0031d> Mono.CSharp.Block:ResolveMeta (Mono.CSharp.ToplevelBlock,Mono.CSharp.EmitContext,Mono.CSharp.InternalParameters) in <0x00acc> Mono.CSharp.Block:ResolveMeta (Mono.CSharp.ToplevelBlock,Mono.CSharp.EmitContext,Mono.CSharp.InternalParameters) [About 20 of the same] in <0x00acc> Mono.CSharp.Block:ResolveMeta (Mono.CSharp.ToplevelBlock,Mono.CSharp.EmitContext,Mono.CSharp.InternalParameters) in <0x00acc> Mono.CSharp.Block:ResolveMeta (Mono.CSharp.ToplevelBlock,Mono.CSharp.EmitContext,Mono.CSharp.InternalParameters) in <0x000db> Mono.CSharp.EmitContext:ResolveTopBlock (Mono.CSharp.EmitContext,Mono.CSharp.ToplevelBlock,Mono.CSharp.InternalParameters,Mono.CSharp.Location,bool&) in <0x00051> Mono.CSharp.EmitContext:EmitTopBlock (Mono.CSharp.ToplevelBlock,Mono.CSharp.InternalParameters,Mono.CSharp.Location) in <0x004ee> Mono.CSharp.MethodData:Emit (Mono.CSharp.TypeContainer,Mono.CSharp.Attributable) in <0x0003f> Mono.CSharp.Method:Emit () in <0x006df> Mono.CSharp.TypeContainer:EmitType () in <0x0056c> Mono.CSharp.RootContext:EmitCode () in <0x01230> Mono.CSharp.Driver:MainDriver (string[]) in <0x0001d> Mono.CSharp.Driver:Main (string[]) make[8]: *** [../../class/lib/basic/System.dll] Error 1 make[8]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs/class/System' make[7]: *** [all.real] Error 2 make[7]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs/class/System' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/mono-1.1.4/work/mono-1.1.4' make: *** [all] Error 2 Reproducible: Always Steps to Reproduce: 1. USE="-nptl" emerge '=dev-dotnet/mono-1.1.4' 2. Wait 3. Fails Actual Results: The build fails with an unhandled exception Expected Results: Build should probably finish. Corroborated by at least one other on #gentoo-amd64 I tested the same build on x86 and it worked fine (Even with USE="-nptl"). Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r6 x86_64) ================================================================= System uname: 2.6.10-gentoo-r6 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, Feb 9 2005, 09:46:15)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6, 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-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=k8 -fweb -ftracer" 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/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=k8 -fweb -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.ccccom.com http://ftp.heanet.ie/pub/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://mir.zyrianes.net/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.osuosl.org/ http://194.117.143.72" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aalib acl acpi alsa berkdb bindist bitmap-fonts crypt cups curl f77 fam flac font-server fortran gif gpm gstreamer gtk imagemagick imlib ipv6 jp2 jpeg kde libwww lzw lzw-tiff mad motif multilib ncurses nls nptl oggvorbis opengl perl png python qt readline samba sdl ssl tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales xml2 xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS latexer@gentoo.org 2005-03-02 07:52:25 0000 Thanks for the report. This looks to be the same error from comment #15 on bug #61293. I'll suggest that use try with USE="nptl" as a temporary fix. Any chance you can get a backtrace of the mono process after this barfs? (I know, easier said than done) latexer@gentoo.org 2005-04-08 11:47:11 0000 *** Bug 88390 has been marked as a duplicate of this bug. *** latexer@gentoo.org 2005-04-14 17:04:44 0000 Does 1.1.6-r1 solve this issue for you with USE="-nptl"? Any chance of a gdb backtrace? bcs26@cornell.edu 2005-04-26 20:20:31 0000 I also see this issue (the build error is identical) on amd64, trying to emerge mono-1.1.6-r1, but it fails for me both with USE="nptl" and with USE="-nptl". I _am_ able to build mono successfully from SVN. My emerge info follows: Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.3.4, glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r1 x86_64) ================================================================= System uname: 2.6.9-gentoo-r1 x86_64 AMD Opteron(tm) Processor 244 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 5 2005, 22:05:53)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-fPIC -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-fPIC -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo" LANG="en_US" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi alsa amd64 apache2 avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cscope cups curl dbus dvd dvdr eds encode esd fam flac font-server foomaticdb fortran gd gdbm gif gimpprint gnome gphoto2 gpm gtk gtk2 gtkhtml hal howl imagemagick imlib ipv6 java jp2 jpeg junit libwww lzw lzw-tiff mad mikmod motif mozilla mp3 mpeg mysql ncurses nls nvidia ogg oggvorbis opengl oss pam pda pdflib perl png postgres ppds python qt quicktime readline ruby ruby18 sdl slang speex sqlite ssl tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis xinerama xml xml2 xmms xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS latexer@gentoo.org 2005-05-05 11:58:46 0000 Any change with USE="-nptl" with the new mono-1.1.7? travitc@gmail.com 2005-05-05 12:46:59 0000 Mostly the same results with 1.1.7 - the error looks like it is farther into the build process than it did in 1.1.4 (it fails at class/corlib which is built after class/System). make[8]: Entering directory `/var/tmp/portage/mono-1.1.7/work/mono-1.1.7/mcs/class/corlib' MONO_PATH="../../class/lib/basic:$MONO_PATH" /var/tmp/portage/mono-1.1.7/work/mono-1.1.7/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /nowarn:649 /nowarn:169 -d:INSIDE_CORLIB -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig /unsafe /nostdlib /target:library /out:mscorlib.dll @corlib.dll.sources Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) in <0x002f3> Mono.CSharp.Block:ResolveMeta (Mono.CSharp.ToplevelBlock toplevel, Mono.CSharp.EmitContext ec, Mono.CSharp.InternalParameters ip) bcs26@cornell.edu 2005-05-05 17:34:26 0000 1.1.7 fails in the same way for me as well, but I think I've narrowed down the issue. The mono ebuild passes --with-tls=pthread to configure, unless USE=nptl and have_NPTL is true. If I hack the ebuild to use --with-tls=__thread regardless, it compiles fine. Running configure from svn uses --with-tls=__thread by default, which I assume is why I'm able to build from svn as well. See also: http://www.mail-archive.com/debian-amd64@lists.debian.org/msg08507.html for what looks like the same issue. latexer@gentoo.org 2005-05-05 18:02:58 0000 Interesting... You definitely don't have a glibc compiled with NPTL, and yet forcing that option works for you? bcs26@cornell.edu 2005-05-05 19:47:19 0000 Fairly certain that I'm not using nptl, yeah. No /lib64/tls, no nptl USE flag set, and the output of /lib64/libc.so.6 is: GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 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 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). Compiled on a Linux 2.6.8 system on 2005-04-18. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. GNU Libidn by Simon Josefsson BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. And forcing the option definitely does allow mono-1.1.7 to compile and run. latexer@gentoo.org 2005-05-06 07:29:40 0000 Ok, i've just commited this, forcing __thread *only* on amd64. Can everyone on this bug please test if possible and report back if this works for them now? (I've only modified 1.1.7 for now). Thanks. travitc@gmail.com 2005-05-06 08:35:02 0000 That change worked here with USE="-nptl" Built with gcc4 no less. latexer@gentoo.org 2005-05-08 06:54:34 0000 Ok, tenatively marking this FIXED. If anyone is still having problems on amd64 after this fix in 1.1.7, please feel free to re-open. Thanks.