Bug 39618 - trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
Summary: trunk revision 145459 - The configure of libstdc++-v3 hangs while checking fo...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: pch (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.8.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 49246 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-03 02:18 UTC by Rob
Modified: 2012-09-09 12:02 UTC (History)
3 users (show)

See Also:
Host: i386-unknown-openbsd4.5
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-28 00:00:00


Attachments
PCH Supoort for OpenBSD (1.42 KB, patch)
2011-11-20 03:29 UTC, Kurt Miller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2009-04-03 02:18:31 UTC
The build is stuck in the Third Stage of configuring 'libstdc++-v3'.

I hope I selected the correct "Component", it is either 'bootstrap',
'pch' or 'c++' (still investigating). I had no such problem with the
previous stages and can build gcc 4.2.0 on this Platform using the
same ./configure options. I have an unsatisfactory workaround below.


# uname -a
OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386


# gcc/xgcc -v
Using built-in specs.
Target: i386-unknown-openbsd4.5
Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,c++,fortran,java,objc,obj-c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/man --enable-multilib --disable-stage1-checking --enable-checking=release --with-system-zlib --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: single
gcc version 4.5.0 20090402 (experimental) [trunk revision 145459] (GCC)


The KDE Process Monitor says that the hung Process is gcc/cc1plus .
I have over 900MB free and am not using any swap.

Here is where it hangs, it has been stuck here for over half an hour:

Checking multilib configuration for libstdc++-v3...
mkdir i386-unknown-openbsd4.5/libstdc++-v3
Configuring in i386-unknown-openbsd4.5/libstdc++-v3
configure: creating cache ./config.cache
checking build system type... i386-unknown-openbsd4.5
...
checking whether the  /usr/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/gcc_build/./gcc -nostdinc++ -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src -L/usr/gcc_build/i386-unknown-openbsd4.5/libstdc++-v3/src/.libs -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/bin/ -B/usr/obj/gcc_installed/i386-unknown-openbsd4.5/lib/ -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/include -isystem /usr/obj/gcc_installed/i386-unknown-openbsd4.5/sys-include linker (/usr/gcc_build/./gcc/collect-ld) supports shared libraries... yes
checking dynamic linker characteristics... cc1: warning: command line option "-nostdinc++" is valid for C++/ObjC++ but not for C
openbsd4.5 ld.so
checking how to hardcode library paths into programs... immediate
checking for exception model to use... sjlj
checking for compiler with PCH support...        
[HUNG]


I killed the process and this is the result:

checking for compiler with PCH support... no
checking for enabled PCH... no
checking for thread model used by GCC... single
checking for atomic builtins for bool... no
...


I loose PCH support but the build and configury can now continue.
I'll see if I can go back and determine why this occurs once the
build is completed and "make -i check" is running.

Thanks,
Rob
Comment 1 Andrew Pinski 2009-04-16 21:07:32 UTC
Sounds like mmap is not working.
Comment 2 Kurt Miller 2011-11-20 03:29:51 UTC
Created attachment 25864 [details]
PCH Supoort for OpenBSD

Attached is a patch against gcc-4.6.2 which uses brk/sbrk for PCH support. Since malloc uses mmap the heap is unused and at a fixed address (so long as PIE is not enabled on gcc). I originally wrote this in 2008 for 4.2 and has been in use
Comment 3 Kurt Miller 2011-11-20 03:31:22 UTC
... since then without issues.

OpenBSD uses random mmap() return addresses. malloc uses mmap and the runtime linker randomizes shared library load addresses, thus using mmap as a fixed address is rather difficult on OpenBSD.
Comment 4 Andrew Pinski 2012-01-28 05:34:14 UTC
Confirmed.
Comment 5 Andrew Pinski 2012-02-04 21:09:13 UTC
*** Bug 49246 has been marked as a duplicate of this bug. ***
Comment 6 Mark Kettenis 2012-09-09 08:44:02 UTC
This is fixed by the following commit.  

Turns out it is possible to use a carefully chosen address to get PCH working
reliably, so I did go for that approach since it has a chance to work if GCC
is compiled as a position independent executable as well.


2012-09-02  Mark Kettenis  <kettenis@openbsd.org>

        * config.gcc (x86_64-*-openbsd*): New target.
        * config.host (*-*-openbsd*): New target.
        * config/openbsd.h (TARGET_C99_FUNCTIONS): Define.
        * config/i386/openbsdelf.h: Remove some superfluous defines and
        group things together in a more logical fashion.
        (DBX_REGISTER_NUMBER): Provide a
        definition that works on both 32-bit and 64-bit targets.
        (WCHAR_TYPE_SIZE): Hardcode as 32.
        (NO_DOLLAR_IN_LABEL): Remove undef.
        (TARGET_DEFAULT): Remove.
        (SET_ASM_OP): Remove.
        (DEFAULT_PCC_STRUCT_RETURN): Undef first to prevent warning.
        (ASM_OUTPUT_MAX_SKIP_ALIGN): Synch with x86-64.h
        (DWARF2_UNWIND_INFO): Remove define.
        (HAVE_ENABLE_EXECUTE_STACK): Define.
        * config/host-openbsd.c: New file.
        * config/t-openbsd (USER_H): Add EXTRA_HEADERS.
        * config/x-openbsd: New file.
Comment 7 Jonathan Wakely 2012-09-09 12:02:53 UTC
Thanks, closing then