Summary: | Compilation failure mono-1.1.10 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego R. Brogna <diebro> |
Component: | [OLD] Development | Assignee: | dotnet project <dotnet> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 120100 | ||
Attachments: | config.log file |
Description
Diego R. Brogna
2005-12-10 07:16:30 UTC
*** Bug 115092 has been marked as a duplicate of this bug. *** Can you please attach the config.log file from the mono sources dir in /var/tmp/portage/mono-1.1.10/work/mono-1.1.10/ for me? Also, does the just added mono-1.1.10.1 display this problem as well? (In reply to comment #2) > Can you please attach the config.log file from the mono sources dir in > /var/tmp/portage/mono-1.1.10/work/mono-1.1.10/ for me? Also, does the just added > mono-1.1.10.1 display this problem as well? same error on mono 1.1.10.1 Created attachment 75135 [details]
config.log file
this is the requested file
Hrm... this *could*, but NPTL related... Can you try re-compiling glibc with USE="nptl" and then emerging mono to see if this makes things jive? amd64 profile stuff we force nptl usage, you're running x86 profile on amd64, so we don't have that, and that *may* be the source of the problem. I'll check out the ximian bugzilla when I find time to see if anything shows up there. Please report back if the nptl stuff helps. Thanks. # equery -q -C uses glibc - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping. - - erandom : Enable erandom/frandom support in glibc for ssp - - glibc-compat20 : Enable the glibc-compat addon. - - glibc-omitfp : Configure glibc with --enable-omitfp which lets the build system determine when it is safe to use -fomit-frame-pointer - - hardened : activate default security enhancements for toolchain (gcc, glibc, binutils) - - linuxthreads-tls : Configure the linuxthreads glibc with --with-__thread if supported by your system. --with-tls is always enabled if supported and is NOT controlled by this switch. So the glibc built will always support TLS binaries. This toggle chooses whether or not glibc itself uses TLS. If you're concerned about backwards compatibility with old binaries, leave this off. - - multilib : On 64bit systems, if you want to be able to compile 32bit and 64bit binaries + + nls : Adds Native Language Support (using gettext - GNU locale utilities) - + nptl : Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually) - - nptlonly : Disables building the linuxthreads fallback in glibc ebuilds that support building both linuxthreads and nptl. - - pic : Build Position Independent Code. Do not utilize this flag unless you know what you're doing. - - profile : Adds profile support to builds of packages (will likely vary from ebuild to ebuild in support) - - selinux : !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur - - userlocales : build only the locales specified in /etc/locales.build i have recompiled glibc with USE="nptl" but the error persists. Diego (In reply to comment #5) > Hrm... this *could*, but NPTL related... Can you try re-compiling glibc with > USE="nptl" and then emerging mono to see if this makes things jive? amd64 > profile stuff we force nptl usage, you're running x86 profile on amd64, so we > don't have that, and that *may* be the source of the problem. I'll check out > the ximian bugzilla when I find time to see if anything shows up there. > > Please report back if the nptl stuff helps. Thanks. > 1) looking again, you do realize that '-O6' in your CFLAGS is meaningless, right? 2) Does this still occur with mono-1.1.12.x or mono-1.1.13.x? Please test and report back. Thanks. |