On 18 Apr 2007, at 15:38, Paul Brook wrote:

On Wednesday 18 April 2007 00:19, FX Coudert wrote:
Someone reported on bug on a trivial statically-linked Fortran progam
with OpenMP and a I/O operation. I can reproduce the segfault, which
happens at:
...
Andrew suggested on bugzilla that this might be a GLIBC issue (I use
glibc-2.4 from redhat), with "pthreads not linking in correctly".
Does this ring a bell? Can someone confirm that it's not a GCC issue
(or that it is)? Details can be found in PR 31604.

The answer to any question involving glibc and static linking is
generally "don't do that".

I've seen pthread related problems with static linking, though that was
related to nss dlopening a shared library from a static application.

Is this only advised with parallel programs, or is it a general rule?
In my research, I statically link all my benchmarks because that I measure stuff about them using instrumentation on a bunch of computer (which might have various OSs, OS versions, libc versions, ...). Because we want to analyze the same dynamic executed code over and over again (no matter on which machine the analysis is donne), I use static linking.

I've heard to warnings about static linking before from other people too: using a libc version which is not intented for the system you are running on might lead to weird behavior.

Concerning this, I have some questions:

- What are the possible issues with static linking? Are they listed above (pthread problems, libc vs kernel conflicts), or are there more?

- How can I easily dynamically link against libc, but statically link with everything else? Currently, making everything statically linked is easy: in the various makefiles I set CC="gcc -static". Is there a similar 'trick' to link libc dynamically but everything else statically? (I'm using GCC 4.1.2 if it matters)

greetings,

Kenneth

--

Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste


Reply via email to