Hmm, these functions should be weak and should not be visible.

As requested by the bug filing, can you attach the preprocessed source code for this hello world program?

Created attachment 11186 [details]
Hello World test preprocessed source

Hello,
here is requested preprocessed source bzip2ed.
Karel

This is interesting because:
static __typeof(pthread_once) __gthrw_pthread_once __attribute__ ((__weakref__("pthread_once")));


That should have made that decl weak which in turn should not needed to have this decl declared in the program.

Can you try this simple C program and see if it can link?
int f(void);
static __typeof(f) __gthrw_f __attribute__ ((__weakref__("f")));

int main(void)
{
  if (__gthrw_f)
  {
     __gthrw_f ();
     abort (0);
  }
  exit (0);
}


------
If this does not work, then there is something wrong with the static linker on OpenBSD.

Hello,
I don't know if it is of any use, but from the OpenBSD history I remember it used really ancient binutils version, i.e. as 0.92 or so, the linker very same. Now, at least in 3.9 it's using FSF binutils 2.15, with probably some patches applied. During my search thorough libstdc++ sources, I've found some references and specific file for free and netbsds, but nothing for OpenBSD. Does it mean this OS is completely unsupported by libstdc++?
Thanks,
Karel

After correcting abort(0) to abort() on line 9 I get:

$ /home/karel/usr/local/gcc-trunk-20060331/bin/gcc test.c  
test.c: In function 'main':
test.c:9: warning: incompatible implicit declaration of built-in function 'abort'
test.c:11: warning: incompatible implicit declaration of built-in function 'exit'
$ ./a.out                                                                                                               
$ ls -la a.out                                                                                                          
-rwxr-xr-x  1 karel  wheel  6512 Apr  2 21:20 a.out
$ ldd a.out                                                                                                             
a.out:
        Start    End      Type Open Ref GrpRef Name
        00000000 00000000 exe  1    0   0      a.out
        0149b000 214cc000 rlib 0    1   0      /usr/lib/libc.so.39.0
        0bb97000 0bb97000 rtld 0    1   0      /usr/libexec/ld.so
$ 

At least I assumed that I should compile with 4.2, since OpenBSD's 3.3.5 complained with:

$ gcc test.c                                                                                                            
test.c:2: warning: `__weakref__' attribute directive ignored
test.c: In function `main':
test.c:9: error: too many arguments to function `abort'

and GCC 4.2 complained about abort in the same way:

$ /home/karel/usr/local/gcc-trunk-20060331/bin/gcc test.c                                                               
test.c: In function 'main':
test.c:9: warning: incompatible implicit declaration of built-in function 'abort'
test.c:9: error: too many arguments to function 'abort'
test.c:11: warning: incompatible implicit declaration of built-in function 'exit'


So I hope I've not breaken your test code too much.

Thanks,
Karel

I had messed up my own testcase, this is what I get for writting the testcase in bugzilla and then trying it out.  Anyways "abort (0);" should have been "abort ();".

Now if this works, then we have a problem in libstdc++ check to enable weakref for some reason.

The testcase should not work at all in GCC before 4.1.0 because of the use of weakref.

Subject: Re:  linking of C++ app fail on OpenBSD 3.9 due
 POSIX threading unresolved symbols

> Now if this works, then we have a problem in libstdc++ check to enable weakref
> for some reason.

Could you be so kind and point me into direction where the check is made?
Anyway, greping thorough sources for "weakref" and thorough build 
directory I've found this (in build dir):

$ find . -name 'config*' -exec grep "weakref" \{} \; -print
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
         .weakref foobar, barfnot
gcc_cv_as_weakref=no
./gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
         .weakref foobar, barfnot
gcc_cv_as_weakref=no
./prev-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./prev-gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
         .weakref foobar, barfnot
gcc_cv_as_weakref=no
./stage1-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./stage1-gcc/config.cache
$

which seems to me .weakref is not supported by assembler. I've tried to 
syntetize back the test case and got this:

$ cat /tmp/weakref.s
         .weakref foobar, barfnot

$ as /tmp/weakref.s
/tmp/weakref.s: Assembler messages:
/tmp/weakref.s:1: Error: unknown pseudo-op: `.weakref'
$ as --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `i386-unknown-openbsd3.9'.
$

It's interesting it's working in gcc then...

Karel

(In reply to comment #8)
> It's interesting it's working in gcc then...
Not really as we emulate what the weakref asm op does with weak and alias.

Subject: Re:  linking of C++ app fail on OpenBSD 3.9 due
 POSIX threading unresolved symbols

Small addition to previous post. Although .weakref is not supported, .weak 
is:

$ cat /tmp/weak-conftest.s
       .weak foobar
$ as /tmp/weak-conftest.s

Wait a minute, libstdc++ is being built only as a static library looking at the error message from comment #0.  But that should not really.

Can you try an objective-C compiling for me to see if it is just libstdc++ that is messed up?
The Objective-C runtime uses the same files as libstdc++ does for threading

The simple Objective-C program would be:
#include <objc/Object.h>
int main(void)
{
  [Object new];
  return 0;
}

Subject: Re:  linking of C++ app fail on OpenBSD 3.9 due
 POSIX threading unresolved symbols

Sorry, I've enabled only c++ for this build and I would prefer not to 
rebuild if possible, since c/c++ took about 4-5 hours to built.

Anyway, I consider libstdc++ support to be quite broken on OpenBSD. You 
named it, shared library is missing and I've also found that other shared 
libs seems to be presented:

$ find . -name '*.so*'
./lib/libssp.so.0.0
./lib/libgcc-math.so.0.0
./lib/libgomp.so.1.0
$

if possible please write me what to test/check and I will do this here on 
OBSD of course. If you point me to the direction of libstdc++ hacker 
manual (to found out which autoconf is required), I'm able to also check 
some configure.ac hacks for you.

Anyway, if you consider ObjC test important, let me know and I will start 
rebuild immediatelly.

Thanks!

Subject: Re:  linking of C++ app fail on OpenBSD 3.9 due
 POSIX threading unresolved symbols

Hello,
I've rebuild todays trunk and configured it as:

$ gcc -v
Using built-in specs.
Target: i386-unknown-openbsd3.9
Configured with: /home/karel/svn/gcc/trunk/configure 
--prefix=/home/karel/usr/local/gcc-trunk-20060404 --enable-shared 
--enable-threads --enable-languages=c++,objc --disable-checking 
--disable-nls --disable-werror
Thread model: posix
gcc version 4.2.0 20060404 (experimental)
$

now I've tested your ObjC test and compilation fails with:

$ gcc test.m
/tmp//ccsP4264.o(.text+0x18): In function `main':
: undefined reference to `objc_get_class'
/tmp//ccsP4264.o(.text+0x2c): In function `main':
: undefined reference to `objc_msg_lookup'
/tmp//ccsP4264.o(.text+0x62): In function `__objc_gnu_init':
: undefined reference to `__objc_exec_class'
/tmp//ccsP4264.o(.data+0x40): undefined reference to 
`__objc_class_name_Object'
collect2: ld returned 1 exit status
$

as it seems gcc does not link against libobjc automatically I also tried 
this:

$ gcc test.m -lobjc

and I finally got some POSIX threading related undefined symbols:

$ gcc test.m -lobjc
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
warning: strcpy() is almost always misused, please use strlcpy()
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
warning: sprintf() is often misused, please use snprintf()
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_cond_signal'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_attr_destroy'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_create'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_getspecific'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_attr_init'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_exit'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_key_delete'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_cond_broadcast'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_once'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_key_create'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_cond_init'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_mutex_unlock'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_self'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_mutex_destroy'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_mutex_lock'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_cond_wait'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_mutex_trylock'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_cond_destroy'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_mutex_init'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_attr_setdetachstate'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `sched_yield'
/home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: 
undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
$

Please let me know what else to test or try in order to help with fixing 
this issue.

Thanks,
Karel

Thanks for testing, now it might be easier to understand the issue is not purely a libstdc++ one but a gthr-posix.c one.

I've changed summary from "C++ app" to "C++/ObjC app" to better reflect the issue.

OpenBSD is not a primary or secondary platform.

Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.

Closing 4.1 branch.

Closing 4.2 branch.

GCC 4.3.4 is being released, adjusting target milestone.

GCC 4.3.5 is being released, adjusting target milestone.

4.3 branch is being closed, moving to 4.4.7 target.

4.4 branch is being closed, moving to 4.5.4 target.

GCC 4.6.4 has been released and the branch has been closed.

The 4.7 branch is being closed, moving target milestone to 4.8.4.

GCC 4.8.4 has been released.

The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

GCC 4.9.3 has been released.

GCC 4.9 branch is being closed

GCC 6 branch is being closed

(In reply to Mark Mitchell from comment #16)
> OpenBSD is not a primary or secondary platform.

Is the OpenBSD port even still maintained? I don't see any maintainer listed for it in MAINTAINERS, and the only mention of it at all in that file is in Marc Espie's email address, but it appears he uses different emails here on bugzilla... (not sure which one to cc)

The GCC 7 branch is being closed, re-targeting to GCC 8.4.

GCC 8.4.0 has been released, adjusting target milestone.

GCC 8 branch is being closed.

GCC 9.4 is being released, retargeting bugs to GCC 9.5.

GCC 9 branch is being closed

GCC 10.4 is being released, retargeting bugs to GCC 10.5.

GCC 10 branch is being closed.

GCC 11 branch is being closed.