On Mon, 2008-12-15 at 11:37 +0100, Gerald Pfeifer wrote:
> Steve et al,
>
> I don't think I have seen a response to this, and it might be the same
> issue that was causing quite many testsuite failures on i386-unknown-freebsd
>
> If so, that would be GCC Bugzilla Bug 35114, "731 unexpected libgomp
> testsuite failures due setup of test environment", or
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35114
>
> Looking at a recent i386-unknown-freebsd run at
> http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01196.html
> though, we have
>
> === libgomp Summary ===
>
> # of expected passes 2262
> # of unexpected failures 57
> # of unsupported tests 2
>
> so something seems to have been improved?
>
> Thoughts?
>
> Gerald
I don't think this is exactly the same issue, but it could be related.
These errors seem to be saying that it couldn't find a symbol, to me it
looks like the program was linked with the archive libgcc (which didn't
have the 4.0.0 symbols) and the shared libgomp was not linked against
any libgcc so the symbols were not found because the shared libgcc is
never referenced anywhere.
In my case, the shared libgomp shows the shared libgcc as a dependent
library but it doesn't know where to find it. I haven't submitted a
patch for this but my current inclination is to fix my problem in GCC
with this addition to gcc/config/ia64/hpux.h:
#define DRIVER_SELF_SPECS \
"%{fopenmp:%{!static:%{!static-libgcc:-shared-libgcc}}}"
This way any program that uses libgomp will also use the shared libgcc
and the path to libgcc will be in the executable.
Steve Ellcey
s...@cup.hp.com
