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 libgom
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.g
On Tue, 2008-11-04 at 16:01 -0600, Bob Friesenhahn wrote:
> For many years, I have not seen it done any other way. I thought that
> all GCC switched to using a shared libgcc years ago.
>
> Bob
When I look at a C compile on Linux (with GCC 4.1.1 or with GCC ToT) on
x86, I see a link line conta
On Tue, 4 Nov 2008, Steve Ellcey wrote:
The fix in GCC, as far as I can see would be to use -shared-libgcc when
doing links where -fopenmp is used. Or, more drastically, change GCC to
always use the shared libgcc on IA64 HP-UX. The IA64 HP-UX system ships
without an archive version of libc so
On Tue, Nov 4, 2008 at 12:56 PM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> To fix it in libtool I think we would have to stop using +nodefaultrpath
> when building shared libraries so that there is a search path to use in
> the shared libraries. This seems simple but I am not sure about all the
>
