On Mar 10, 2006, at 3:14 PM, Andrew Pinski wrote:
And it turned out I was correct in saying libstdc++ is also effected.
See PR 26633. So this is not a libfortran specific issue any more.
Actually that turned out to the TLS not be updated correctly for
threads issue with static linking problem
On Mar 7, 2006, at 6:31 PM, Andrew Pinski wrote:
I bet the same issue now will happen with libstdc++ (and in 4.1.0 in
fact).
I want to say the weak references is the wrong way of doing things for
non
shared libraries.
And it turned out I was correct in saying libstdc++ is also effected.
S
On Mar 7, 2006, at 6:12 PM, FX Coudert wrote:
The only sure-fire fix I can think of is to actually build
two static versions of libgfortran -- one threaded and one
not threaded. I'm not sure this is worth the effort, really.
I'd be more inclined to put a couple of checks in such that
the stati
On Wed, Mar 08, 2006 at 12:12:24AM +0100, FX Coudert wrote:
> Hum, there are some platforms where libgfortran (and other target
> libraries) cannot be built as shared libraries. i386-mingw32 is an
> example of that. We've been careful until now to keep static
> libgfortran working even as a stat
The only sure-fire fix I can think of is to actually build
two static versions of libgfortran -- one threaded and one
not threaded. I'm not sure this is worth the effort, really.
I'd be more inclined to put a couple of checks in such that
the static libgfortran only runs non-threaded, and force
p
On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote:
> #0 0x in ?? ()
> #1 0x0804d112 in find_unit_1 (n=6, do_create=1)
The problem here is a combination of factors: static linking
and weak symbol references via gthr.h.
The direct cause is that pthread_mutex_trylock isn't pull
On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote:
> Richard mentioned similar problems with broken libc versions that
> wouldn't initialize TLS properly, but this particular one doesn't seem
> related. Richard, any ideas?
Huh. No, this one doesn't look like the failure I had before.
On 02/28/06 18:42, FX Coudert wrote:
> Jakuk, Diego? Is this a bug or a feature? :)
>
Looks like a bug, but I'm not really sure what is causing it. I can
reproduce it with one of the tests in libgomp
(libgomp.fortran/appendix-a/a.16.1.f90), but I get a different trace:
-
Should I file a bug ?
I think it might be better to wait for the opinion of the gomp
maintainers, as I'm fairly new to that stuff and could have missed
something important.
Jakuk, Diego? Is this a bug or a feature? :)
Hum... for trunk on i686-linux, I do see the following. Dynamic
linkin
> I might be missing out on something but I get a segmentation fault when
> manualy executing omp_hello.f from libgomp testsuite
> (libgomp/testsuite/libgomp.fortran/omp_hello.f)...
>
> Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello
Hum... for trunk on i686-linux, I do see th
10 matches
Mail list logo
